[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] non static libs on windows (dll)

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-03-21 02:41:57 CET

Russell Yanofsky wrote:

>Another place you might consider diverting from apr is in the use of
>function call macros. Why not use
>
> SVNAPI svn_error_t *
> svn_ra_init_ra_libs (void **ra_baton,
> apr_pool_t *pool)
>
>instead of
>
> SVN_DECLARE(svn_error_t *)
> svn_ra_init_ra_libs (void **ra_baton,
> apr_pool_t *pool)
>

Because the __declspec has to come before the type, and the __stdcall
after the type. And yes, we really do want to use __stdcall; most other
languages expect to use that by default when linking to DLLs. Only
variadic functions have to be declared __cdecl, and we have very few of
those.

Of course, we could just define STDCALL and CDECL, too.The real trouble
with all these macros is that they tend to get into the Doxygen docs;
that's why APR adds a @deffunc for every public function -- it can't
trust Doxygen to do the right thing in the presence of _DECLARE macros.

Regarding the generation and use of :DEF files:

    * We don't want to export all funcitons with external linkage, only
      the ones that are declared in headers in subversion/include. That
      makes creating such a generator even harder.
    * Dynamic loading with .DEFs is actually slower than with __declspec.
    * Keeping the ordinals stable is possible, but you need the names
      anyway if you want to do any dynamic loading (for mod_dav_svn, the
      RA plugins, the future FS plugins, etc.)

Just adding some spice to the discussion... :-)

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 21 02:42:41 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.