Re: glib-tml-980819-0.patch

[Tor Lillqvist <tml hemuli tte vtt fi>]

Tim Janik writes:
 > you have basically just commented out the code that is performed
 > by g_debug and g_stack_trace, and let them just call abort() if
 > NATIVE_WIN32 is defined.

Maybe g_debug should even simply do ' *((int *)NULL) = 0 ' which will
cause at least MS DevStudio, if installed, to offer debugging the
program? (abort() just prints "Abnormal program termination" and
stops)

 > GLIBAPI stuff:
 > i'm hesitating a bit to apply this, since it would be nice if we could
 > keep glib.h in its current manner. the automatic Window header file
 > generation i suggested in the "Re: Gtk port to Win32 "progress report""
 > thread might be a solution to this.

Oh well, I could try to write that perl or awk script that
automatically generates a Win32-specific glib.h (and gmodule.h). The
makefiles for Win32 would then copy it over glib.h. (They also should
automatically copy glibconfig.h.win32 and gmoduleconf.h.win32 to
glibconfig.h and gmoduleconf.h.)

Btw, I noticed I forgot to include the gmodule-win32.c file in the
patch, sorry.

 > ./gmessages.c:
 > - what do you define GMESSAGES_C for?

Look at the beginning of my patch for glib.h, where GLIBVAR1 and
GLIBVAR2 are defined... The special handling of exported variables is
needed with the Watcom compiler.

 > - you are making definitions for a newline string and its length,
 >   i'd say we should better make those global, so other programs
 >   can take advantage of this in their output as well (plus
 >   a directory seperator):

Sure, that's OK with me. (OTOH, this isn't needed for output going
through stdio (the C library takes care of inserting CRs), just if you
use the Win32 API directly.)

(About the gmessage.c stuff, I'm not sure what's the Right Thing to do
on Win32. Outputting the stuff to a console window as now (which will
ignore redirections for a program started from a console window), or a
MessageBox, or what?)

 > - does the AllocConsole() and WriteConsole() stuff properly deal with
 >   out of memory conditions?

It's hard to say, but as they are Win32 API functions and not from the
C library, they're the best you can do, I think.

 > gmodule.h:
 > - there is a reason for extern const char *g_log_domain_gmodule; to be
 >   defined prior to the inclusion of glib.h (though a bad one). the
 >   g_wanring, g_message and g_error inline functions (#ifndef __GNUC__)
 >   use this variable within their function body, so it needs to be defined
 >   when glib.h is included.

Oops, I'll have to check this more carefully.

 > - why do you prefix the function typedefs for GModuleCheckInit and
 >   GModuleDeInit with GMODULEAPI? so far my understanding was, that GMODULEAPI
 >   is only required for actuall symbols that need to be exported...

This is just a misedit, sorry.

 >   so your change to just #ifdef WIN32 for changing
 >   the plugin names is probably justified ;) but we should really supply an
 >   extra function for this, something like
 > gchar*
 > g_module_make_file_name (const gchar *module_name)
 > {
 >   g_return_val_if_fail (module_name != NULL, NULL);
 > #ifdef WIN32
 >   return g_strconcat ("lib", module_name, ".dll", NULL);
 > #else /* !WIN32 */
 >   return g_strconcat ("lib", module_name, ".so", NULL);
 > #endif /* !WIN32 */

IMHO it's questionable if the "lib" prefix should be used on Win32.

 >   btw, why are you checking for "WIN32" here, and not for "NATIVE_WIN32" as
 >   in the above?

Hmm. The GNU-Win32 tools don't support creating and dynamically
loading shared libs very well yet (correct me if I'm wrong), so in a
way this is a moot question. I don't know whether the GNU-Win32 tools
eventually will prefer calling them .so or .dll .

 > miscellaneous:
 > - we probably need to make adaptions to a few else functions,
 >   e.g. g_dirname, g_basename come to mind.

Yup.

 > for one i'd really like to thank you very much for going through
 > this, making glib more portable is actually a *very* worthwhile
 > goal.

Thanks. I guess I'll modify my changes according to your comments and
submit a new patch in a few days?

One thing about gtk: the Watcom compiler (argh, maybe I should switch
to using only MSVC and forget Watcom) defines va_list as "typedef char
*va_list[1]". As you might imagine, va_list being an array type causes
all kinds of strange effects in gtk in the functions where va_lists
are passed by reference....

I think I'll take care of with a few macros, something like
VA_LIST_REFERENCE(va) that expands to "&va" on normal systems or just
"va" on Watcom. Etc.

What does the C standard say, what should you be allowed to do with a
va_list? Are there other compilers that define va_list as an array? Is
the Watcom compiler non-compliant in this way?

--tml