-----BEGIN PGP SIGNED MESSAGE-----
Erik Huelsmann wrote:
> 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?
Yes. You cannot use APR_DECLARE_DATA, because that will expand to
__declspec(dllimport). It only expands to __declspec(dllexport) when
inside the compilation of APR itself.
If you wanted to go down this route, you would need to define a
SVN_DECLARE_DATA, which varied depending on whether you were compiling
_Subversion_, not APR.
However, I thought the whole point of extractors and .def files was to
If it turns out that .def files cannot adequately support data exports,
I think we would be better off just to use decoration everywhere - using
one system for function exports and a different system for data exports
would be too confusing.
> 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?
AFAIK, the only other cause to use a declaration macro is if you need to
decorate to force calling convention (i.e. APR_DECLARE_NONSTD).
I'm not aware of us forcing any calling conventions at present.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Dec 5 17:34:57 2005