more comfortable approach for exporting dbus functions on windows

[Ralf Habacker]

Ralf Habacker schrieb:
> 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.
... which could be fixed later, if really required.

Appended are the related patches for the cmake buildsystem - I tested it 
with msvc and mingw on windows without any problems.
If there are no objections I will commit them tomorrow. 

The required patches for the autotools build system should cover the 
following topics:
1. remove def file usage and installation in buildsystem (including the 
.def.* files from dbus/ source dir)
2. add -DDBUS_STATIC_BUILD to the compile flags for building the 
dbus-internal target.
3. add -DDBUS_STATIC_BUILD to the compile flags for building all targets 
which depends on the internal lib (or dbus-convenience as it is called 
on unix)

Ralf
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-Removed-def-file-support-for-cmake-build-system.patch
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20100322/c88247d5/attachment.ksh>