more comfortable approach for exporting dbus functions on windows
ralf.habacker at freenet.de
Wed Mar 17 03:39:21 PDT 2010
Romain Pokrzywka schrieb:
> 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
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.
More information about the dbus