Re: glib.h: defining functions in header file

[Tim Janik <timj gtk org>]

On Tue, 29 Jun 1999, Matthew Ahrens wrote:

> 
> On Wed, 30 Jun 1999, Tim Janik wrote:
> 
> > if you just want to use the macros, you are probably better off simply
> > copying them.
> 
>:-( to me that seems more kludgy than putting "#define g_logv(a,b,c,d)"
> before including glib.h.
> 
> > the function implementations are not there because we wanted to practice
> > bad programming, but because there is no way to slide in a library-specifc
> > preprocessor symbol (G_LOG_DOMAIN) into a normal function call, or to
> > write macros with variable argument lists in ANSI C (i.e. with non-gcc
> > compilers).
> 
> ah. I see. by "library-specific" you mean machine/architecture dependent?
> are "library-specific" preprocessor symbols always kept out of the library
> code?

nope, the G_LOG_DOMAIN is a very special one, that is used to prefix
warnings and errors with the name of the library that the message
originated from.
so gdk defines G_LOG_DOMAIN=\"Gdk"
so gtk defines G_LOG_DOMAIN=\"Gtk"
so glib defines G_LOG_DOMAIN=\"GLib"
(and the same is done for e.g. libgnome and libgnomeui)

as a result we can have the code g_warning ("ignore me!"); output warnings ala
Gdk-CRITICAL **: ignore me!
Gtk-CRITICAL **: ignore me!
GLib-CRITICAL **: ignore me!

depending on what library actually called g_warning ("ignore me!");
if G_LOG_DOMAIN is undefined (e.g. within applications) you simply get:
CRITICAL **: ignore me!

but to get this to work, we actually need to pass the current value
of G_LOG_DOMAIN into g_logv() plus the printf() style variable argment list,
which only works within function definitions or macros with variable argument
lists (which is a gcc-only extension).

> Is it a goal of Glib to have it function properly even if you use a
> different compiler to configure and build glib than you do to compile a
> program using it? I have noticed for at least one case this does not work:
> if glib is configured with gcc, it will have G_HAVE_INLINE defined even if
> __cplusplus is not defined. however, if you then try to compile a program
> which uses glib with SUNWspro4.2 cc, glib.h will break because it will
> declare functions as "inline".

> If this is not one of glib's goals, what is the reasoning for keeping
> library-specific macros out of the library code?

nope, glibconfig.h is only suitable for the machine+compiler+installation
combination that glib has been configured for. e.g. i need to reconfigure
glib (which implies rm -f config.cache) if i want to compile code with
lcc, use another threads implementation or downgrade my kernel/libc.

it has been suggested at some point to make glib's configure.in and
glibconfig.h support multiple compiler setups, but so far no one
has really implemented a solution for that.

(this could for instance be possible with a setup like:

glib.h:
#ifdef     GLIB_CC
#  define GLIBCONFIG_H <glibconfig-GLIB_CC.h>
#else  /* !GLIB_CC */
#  define GLIBCONFIG_H <glibconfig.h>
#endif /* !GLIB_CC */
#include GLIBCONFIG_H

and configure glib with:
glib$ CC=lcc ./configue --with-glib-cc=lcc

make install would then install glibconfig-lcc.h instead of glibconfig.h
and one could compile code with

$ lcc -DGLIB_CC=lcc foo.c

)

> 
> thanks,
> --matt
> 

---
ciaoTJ