more comfortable approach for exporting dbus functions on windows

[Thiago Macieira]

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.

-- 
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
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20100305/22229f44/attachment-0001.pgp>