Ivan Zhakov wrote:
> On 12/5/05, Max Bowsher <maxb1@ukf.net> 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.
>
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.
>
libsvn_subr.def:
...
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