more comfortable approach for exporting dbus functions on windows

[Romain Pokrzywka]

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.

Patch coming up soon.

-- 
Romain Pokrzywka | romain at kdab.com | Certified Qt Software Engineer & Trainer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20100317/df34ff2b/attachment.pgp>