[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 10:47:03 CET

Ivan Zhakov wrote:
> On 12/5/05, Max Bowsher <maxb1@ukf.net> wrote:
>> 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
Yes. This kind of clutter is one of the reasons for my -1 to such
decorations unless they're absolutely necessary.

>> 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
> files.
So what? If we do have platform-specific public APIs (which, IMHO, we
shouldn't have), then extractor.py can jolly well learn about #ifdef.

>> 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.

    svn_ctype_table DATA

No source-level decoration is necessary.

>>> 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.
On Windows, the default calling convention for DLL-exported functions is
well defined. I couldn't care less about compilers that don't follow
even the (admittedly spottily) documented standards of the OS they're
supposed to generate code for.

-- 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 10:48:14 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.