more comfortable approach for exporting dbus functions on windows

[Romain Pokrzywka]

Hi,

I've tested the patch and it works fine.
Thanks a lot for this, and for the additional cleanup, this was really a big step for getting a cleaner code base on 
windows !
(just one thing: you could have checked with me with the status for that task before, as I said that I intended to work 
on it. That was luck that I didn't have time yet, otherwise we would have effectively been doing the same thing twice 
:-/)

Otherwise, this is unrelated to your patch, but after the latest dbus-1.2 merge an obsolete test was removed from the 
source so the CMakeLists.txt needs to be adjusted. The fix is attached, can be committed safely.

Cheers
Romain

On Monday 22 March 2010 03:21:03 Ralf Habacker wrote:
> 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



-- 
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: 0001-remove-name-test2-from-cmake.patch
Type: text/x-patch
Size: 1143 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20100322/d0665826/attachment.bin>
-------------- 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/20100322/d0665826/attachment.pgp>