more comfortable approach for exporting dbus functions on windows
thiago at kde.org
Fri Mar 5 00:00:11 PST 2010
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
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.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the dbus