On 12/5/05, Max Bowsher <email@example.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 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?
> 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.
To be accurate: we should define macro for each dll, so it would be
SVN_LIBSVNCLIENT_DATA, SVN_LIBSVN_DELTA_DATA for example.
> However, I thought the whole point of extractors and .def files was to
> avoid decoration?
There is another problems with extractors not counting data exports:
there are functions that not applicable for windows, keychain auth
provider for example, so we need some way to exclude it from .def
> 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.
I'll continue investigation of this problem today, but I can belive
that we will be must use decoration for data exports.
> > 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.
For me it is good practice to specify calling conventions when
declaring dll exports. Because it could be imported by different
compiler, with different default calling convetion settings.
Received on Tue Dec 6 08:10:10 2005