more comfortable approach for exporting dbus functions on windows

[Ralf Habacker]

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