Re: Making ORBit work with MS VS compilers

["Tor Lillqvist" <tml iki fi>]

>  The problem with people calling those functions is
>  that they have to be exported in the library.

You mean that upper level code in other libraries *do* call the
functions commented as "internal"? (And presumably have done so, then,
for several GNOME release cycles?)

In that case then, they clearly aren't actually internal, but part of
the de facto API.

> Hmmm, that's one of the issues, .def files by themselves do not work.
>  They work for functions (ignoring the fact that it's a pain to keep
>  the .def files synced with the code

Yes, I know. Back when I used hand-maintained .def files in GLib and
GTK+ it was a pain. Nowadays, luckily, .symbols files are used for
GLib and GTK+ on Linux, too (and thus get maintained by others, too),
and the .def files are generated from the .symbols files.

>, they don't work for data. For
>  data, you need the entry in the .def file *and* a
>  "__declspec(dllimport)" annotation in the header,

Ah yes, that is a pain. There are a couple of variables in the API of
GLib and GTK+, and they require an ugly ifdef mess in the header.

> That's a point that I forgot to mention in my original message... do
>  you know of any good autoconf/automake tutorials I could read?

There is a book called "GNU Autoconf, Automake and Libtool.

>  (I've generally relied on _WIN32, which is set by MS's compiler,

and by gcc, too

>  and I see libIDL uses
>  G_PLATFORM_WIN32. Would one of those be OK?

G_PLATFORM_WIN32 covers Cygwin, too. G_OS_WIN32 means "native" Win32
and should be equivalent (but more "GLib style") to _WIN32.

I think we want to make the style of API/ABI used a configuration
option, at least initially.

>  Are gcc for [cygwin/] mingw
>  compatible with MS's extensions like the __declspec stuff?)

Yes.

--tml