Re: glib-tml-980819-0.patch

[Tor Lillqvist <tml hemuli tte vtt fi>]

Tim Janik writes:
 > out of curiosity, what will this cause without MS DevStudio? are you
 > sure this is not a reboot-hook? ;))

Nah...

 > yep, i was curious to look at it, but then forgot that i missed reading it ;)

I'll send it when I get home in a few hours.

 > ok, so "WIN32" is always defined for windows compilations, and
 > "NATIVE_WIN32" is defined for what then (watcom, GNU, MSC)?

NATIVE_WIN32 when compiling without the GNU-Win32 (a.k.a. Cygwin)
POSIX emulation stuff. Ie MSVC, Watcom, Borland, mingw32 ("minimalist"
gcc without the cygwin dll) and, I suppose, lcc-win32.

BTW, for GDK, I use the X_DISPLAY_MISSING feature test macro that was
already in config.h, and added the macro WINDOWS_DISPLAY to indicate
the Win32 GUI. This is maybe a bit funny as the sense of the test is
reversed, but, OTOH, this doesn't look so bad, does it?:

#if !defined(X_DISPLAY_MISSING)
...
#elif defined(WINDOWS_DISPLAY)
...
#elif defined(MACINTOSH)  /* or whatever, someday maybe */
...
#endif

Or would perhaps WIN32_DISPLAY be a better name? Or even:

#if GUI_API == GUI_TYPE_X11

#elif GUI_API == GUI_TYPE_WIN32

etc?

Note that X11 vs. Win32 is an orthogonal issue to POSIX vs. Win32.
I.e. there might be cases where you compile with, say, MSVC, but for
X11 display. (The X11R6 client libraries compile AFAIK without
problems on Win32.) Or you could be compiling with gcc and the
GNU-Win32 POSIX emulation, but use Win32 GUI.

 > that would be nice. i'm certainly willing to apply your patch,
 > but i'd like to get the GLIBAPI thing sorted out. if there is a way around
 > that (even if it requires some complicated header parsing and magic), imho,
 > we should go for that.

OK, if you say so. I'll submit another patch version then when I have
ready a script to generate FOOAPI-decorated headers, and have fixed
the other stuff you have mentioned.

 > hm, now you mention it, i still have a bug report in my queue that
 > reports similar problems on a unix machine. i'll fiddle around with the
 > va_list stuff again. we need to get this thing seperated out.

Might this have been a PowerPC (i.e. AIX, I guess)? At least the gcc
va-ppc.h file uses an array type as va_list.

--tml