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

Re: Building Subversion DLLs

From: Branko ─îibej <brane_at_xbc.nu>
Date: 2005-12-06 00:08:57 CET

Erik Huelsmann wrote:
> Hi!
> Yesterday, Zhakov started working on building Subversion DLLs. We
> fixed up extractor.py to return exported variables as well as public
> functions from our headers.
> Most tests complete successfully, but some don't. It looks like that's
> because svn_ctype_table isn't declared __declspec(dllexport). To make
> that declaration platform independent, we could include
> APR_DECLARE_DATA into the definition of svn_ctype_table. I think this
> is the right way to go, but Ivan said it's for internal use by APR (to
> declare APR data, but not for use by applacations-using-apr..).
> Can someone comment on this issue?
We can _not_ use APR_DECLARE_DATA.

> Also, in APR, all functions are declared using APR_DECLARE(type).
> We'll be using extractor.py and accompanying .def file to export our
> functions (in order to export with index-numbers). Strictly speaking,
> in this situation it's not necessary anymore to use APR_DECLARE. Will
> we need to start using APR_DECLARE for other reasons?
We can and will not use APR_DECLARE.

Both APR_DECLARE(_NONSTD) and APR_DECLARE_DATA are totally APR-specific,
and aren't applicable to non-APR code. (For one thing, using them would
mean that we'd have to link the static APR libs with static Subversion

We could define our own macros that mimic the APR_DECLARE ones, but if
we use extractor.py to generate DEF files, we don't need them (at least
for functions), and I personally prefer not to use them because they
clutter up the code (and confuse Emacs' i-menu :).

I'm not sure why exporting a data symbol via a DEF file wouldn't work.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 6 00:10:32 2005

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.