more comfortable approach for exporting dbus functions on windows

[Ralf Habacker]

Romain Pokrzywka schrieb:
> On Wednesday 17 March 2010 03:39:21 Ralf Habacker wrote:
>   
>> Romain Pokrzywka schrieb:
>>     
>>> Hi,
>>>
>>> Sorry for the late reply on this one. Since it's been committed upstream
>>> in the meantime, I've had some time to try it out and it worked fine with
>>> msvc and mingw.
>>> But I think in its current form the change is of limited benefit, as it
>>> only applies to the public API functions: the real advantage of using the
>>> export macros is that it would finally allow getting rid of the .def
>>> files, which have been causing so much trouble lately and still are a
>>> nightmare for portability (see my patch on the next mail...). But for
>>> that we need to use the export macros on all the functions, including the
>>> non-public ones used for the tools and the internal library, basically
>>> every one that we have in the .def.in files currently. The principle is
>>> exactly the same, the same macro can be used, and nothing would change
>>> ABI-wise, it's just a lot more files and lines to edit :) I think it's
>>> worth the effort though.
>>>       
>> just a few notes:
>> 1. on unix the dbus-1 library contains only the public symbols, on
>> windows dbus-1 library contains public and some internal symbols yet
>> 2. on unix dbus-internal library is static and contains all public and
>> internal symbols, on windows dbus-internal currently only contains all
>> symbols not listed in topic 1.
>> 3. on unix dbus-daemon, helper tools and tests apps depends on
>> dbus-internal only, on windows these apps depends on dbus-1 and
>> dbus-internal
>> 4. it may be required to export the same set of symbols on unix and
>> windows in dbus-1 and dbus-internal library before decoration for
>> internal functions could be added
>> 5. dbus-internal library is a separate build target and functions in
>> this library could not use  DBUS_EXPORT as export decoration, it should
>> have a different name for example DBUS_INTERNAL_EXPORT.
>>
>>     
>>> I take care of that tomorrow, unless somebody objects.
>>>       
>> feel free - if you need some assistance let me know.
>>
>> Ralf
>>     
>
> Ah, thanks for that ! That's very valuable info, and indeed the first step would be to make the windows binaries and 
> build match the linux one. This is very easy as well, it's just about including the files from the client lib in the 
> internal one, and removing the linking to dbus-1 afterwards, that should take me less than an hour to do.
>
> As an added benefit, then we don't even need the second set of exports for internal symbols, since dbus-internal is 
> static. It would only be needed if we wanted to make it dynamic, which isn't really a necessity atm.
>   
The only drawback with having a static internal library is that it is 
included in every helper tool and will blow up the binary package 
compressed and binary package installed size.

Ralf