more comfortable approach for exporting dbus functions on windows

[Romain Pokrzywka]

Ok, I was about to point out that the __declspec(dllexport) syntax was msvc ony, and thus would break for mingw, but you 
found that out in the meantime.

I would rather use the macros defined by Qt (Q_DECL_EXPORT) as reference, as I'm not sure the KDE macros are correct for 
all cases : for example I'm pretty sure that'll fail for static builds, as dllexport must not be used then. Also looks 
like the case of building with mingw but without the visibility option will revert to the msvc path, which will also 
fail.

Other than that, THANKS for taking the time to work on that. I've been thinking about it but the task seemed too big, 
apparently not :) This will solve a lot of issues that the .def.in files still failed to address fully.

So are we sure the .def files aren't needed at all then ? I seem to remember that you need them to create a msvc .lib 
from a mingw dll, but I think pexports can do that as well, and that's not really an important feature anymore since 
dbus can be build from msvc directly as well.

Thanks and cheers,
Romain

On Thursday 04 March 2010 14:32:59 Ralf Habacker wrote:
> Am 04.03.2010 22:51, schrieb Colin Walters:
> > On Thu, Mar 4, 2010 at 4:33 PM, Ralf Habacker<ralf.habacker at freenet.de>  wrote:
> >> On windows the macro DBUS_EXPORT contains the required compiler
> >> directive to export/import symbols, on non windows os this macro is a
> >> noop.
> >
> > I haven't looked at the patch, but I'm relatively OK with this.  I'd
> > suggest this text for the comment:
> >
> > /*
> >   * Declare the following symbol as public.  This is currently a noop on
> >   * platforms other than Windows.
> >   */
>
> thanks for this hint
>
> > Related to this, one thing we should actually really investigate is
> > the trick used in GLib to avoid going through the PLT for internal
> > functions.  See: http://git.gnome.org/browse/glib/tree/glib/makegalias.pl
>
> I'm not sure if the reason why there is a also visibility attribute in
> KDE is the same as described above.
> If it is symbol visibility on non windows os  we can do the following
> similar to what is implemented in KDE for example in
>
> http://websvn.kde.org/trunk/KDE/kdelibs/kdemacros.h.cmake?view=markup
> and
> http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/kdecore_export.h?view=marku
>p
>
> #ifdef DBUS_HAVE_GCC_VISIBILITY
> #define DBUS_NO_EXPORT __attribute__ ((visibility("hidden")))
> #define _DBUS_EXPORT __attribute__ ((visibility("default")))
> #define _DBUS_IMPORT __attribute__ ((visibility("default")))
> #elif defined(_WIN32) || defined(_WIN64)
> #define DBUS_NO_EXPORT
> #define _DBUS_EXPORT __declspec(dllexport)
> #define _DBUS_IMPORT __declspec(dllimport)
> #else
> #define DBUS_NO_EXPORT
> #define _DBUS_EXPORT
> #define _DBUS_IMPORT
> #endif
>
> #ifndef DBUS_EXPORT
> # if defined(dbus_1_EXPORTS)
> /* We are building this library */
> # define DBUS_EXPORT _DBUS_EXPORT
> # else
> /* We are using this library */
> # define DBUS_EXPORT _DBUS_IMPORT
> # endif
> #endif
>
> > But that's probably a different patch.
>
> yes, because it may require to use the DBUS_NO_EXPORT macro, see also
> below.
>
> >> The appended patch adds such support for the public dbus api functions.
> >> The internal symbols could be adressed in further patches.
> >
> > What change would need to be made to the internal symbols?
>
> to be clear - i used the term internal for dbus internal functions
> indicated by the _dbus prefix, which are also exported from dbus-1
> shared library.
>
> Symbols which are not exported do not need any decoration on windows,
> because this is the default. if gcc on unix has a switch to set the
> default symbol visibility to 'hidden', than there is also no decoration
> required for this case. Otherwise the above mentioned DBUS_NO_EXPORT
> could be used for this case.
>
> To export the dbus internal functions the following steps are required:
>
> 1. add DBUS_EXPORT to  _dbus_... function
> 2. remove related symbolnames from xxx.def.in
>
> When all symbols are decorated the .def file creation and usage could be
> removed in the autotools and cmake build system.
>
> Regards



-- 
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/20100304/e27d3465/attachment.pgp>