more comfortable approach for exporting dbus functions on windows

[Tor Lillqvist]

> 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?

>  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

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.

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.

--tml