more comfortable approach for exporting dbus functions on windows
Ralf Habacker
ralf.habacker at freenet.de
Mon Mar 22 03:21:03 PDT 2010
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>
More information about the dbus
mailing list