Ivan Zhakov wrote:
> On 12/6/05, Branko Čibej <brane@xbc.nu> wrote:
>
>> Ivan Zhakov wrote:
>>
>>> On 12/6/05, Branko Čibej <brane@xbc.nu> wrote:
>>>
>>>
>>>> libsvn_subr.def:
>>>>
>>>> ...
>>>> EXPORTS
>>>> ...
>>>> svn_ctype_table DATA
>>>> ...
>>>>
>>>> No source-level decoration is necessary.
>>>>
>>>>
>>> Yes, but in this case *some* test fails! I can't figure why. But if
>>> declare svn_ctype_table with __declspec(dllexport) everything works
>>> OK.
>>>
>>>
>> Now, that _is_ funny. I wonder what's going on...
>>
> I have discovered problems:
> http://msdn2.microsoft.com/en-us/library/619w14ds.aspx
> In a few words: On Windows exporting variable means exporting
> *pointer* to this variable and importing must dereference it.
> __declspec(dllexport)/__declspec(dllimport) makes this automatically.
> So I see several ways:
> 1. Use __declspec(dllimport) for variables only. Causes special define
> for *each* dll to separate dll building dll from importing.
> 2. Use __declspec(dllimport) everywhere on windows -- anyway causes
> usage special define per library and change signature of all API.
>
Not really... only when you link with a DLL, and since we don't provide
DLLs yet, it's not actually a signature change. :)
> 3. Never export/import data between libraries. I don't sure that this
> can be done.
>
I'd go with 3. Sure it can be done; in the few cases where we do have
public data items, we can deprecate those and create accessor functions
instead. It'll slow down a fiew things (notably the svn_ctype macros),
but I don't think the difference will be significant.
I really hate the idea of per-library decorations because that would a)
complicate the build (we'd have to emit a different define when building
each library), b) it would reduce the readability of the public headers,
and c) it would mean that each library has to be built twice -- once as
a static lib, and once as a DLL -- instead of building just the static
lib, then simply relinking it as a DLL.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 8 11:32:20 2005