more comfortable approach for exporting dbus functions on windows

[Romain Pokrzywka]

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.

I take care of that tomorrow, unless somebody objects.

Romain

On Friday 05 March 2010 00:00:11 Thiago Macieira wrote:
> Em Sexta-feira 5. Março 2010, às 02.45.22, Tor Lillqvist escreveu:
> > > Ok, I was about to point out that the __declspec(dllexport) syntax was
> > > msvc ony, and thus would break for mingw,
> >
> > As far as I know that syntax is fine in mingw, too?
>
> Yes, it is.
>
> > >  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.
> >
> > Yeah, that is the problem when going down the path of adding
> > export/import decorations to header files: you need an ifdef mess to
> > take care of all the possibilities:
> >
> > 0) are we not on windows? then don't need any of this, let macros
> > expand to empty
>
> Unless you're building with -fvisibility=hidden
>
> Depending on the platform, a library or an application built against
> libdbus-1 that also uses -fvisibility=hidden needs D-Bus headers to have
> them too.
>
> Qt dlopens libdbus-1, so this problem doesn't appear for us.
>
> > otherwise 1) are we building a static library, or are we compiling
> > client code that will link to such sa static library? then don't need
> > any decorations either, have macros expand to empty.
>
> Static should expand to empty. Which poses an interesting question: if you
> build with --enable-static --enable-shared, you can't have the same set of
> headers (on Windows).
>
> On Unix, it doesn't hurt to export even in static libraries. But this is
> solved by the fact that on Windows you simply can't do both builds because
> a shared build produces .a files anyway. (import libraries)
>
> > otherwise, 2) is the header being read when compiling the library
> > itself? then use dllexport. otherwise (when compiling client code),
> > then use dllimport.
> >
> > Did I miss something? Probably.
> >
> > That's why I personally favour either 1) supporting just mingw, and
> > have just a functional API (no variables), and let mingw auto-export
> > and auto-import functions, or 2) use explicit .def files, possibly
> > generated from some more generic list-of-API files that can be used
> > for automatic tests, binding generation or whatever on Unix, too, and
> > 3) if there are variables in the API (which is ugly), their
> > declarations must be decorated for dllimport. so avoid that if
> > possible.
>
> I am not sure, but at least I agree with having a functional API only. And
> I would prefer that any solution we come up with is used in all platforms,
> thus avoiding breaking one specific platform by changes in another.



-- 
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/20100316/89a71494/attachment.pgp>