Re: [gtk-list] Re: includedir -vs- glib.h

[Owen Taylor <owt1 cornell edu>]

Tom Tromey <tromey@creche.cygnus.com> writes:

> Raja> I guess part of the problem is that there is no standard place
> Raja> under $(exec_prefix) to put include files.
> 
> Another way to solve the problem is to make glib.h platform
> independent.
> 
> This is the approach taken by Tcl, Tk, Guile, etc.  It seems to work
> well.  I don't know if it is possible for glib.

The problem with this is that glib.h is meant to cover up some
system dependencies. So unless we filled it with system-specific
#ifdef's there is no way to have it not include a config.h file.
(The system dependencies have been separated out into glibconfig.h
again, but that doesn't change the problem)

autoconf information glib.h depends on:

 HAVE_FLOAT_H
 HAVE_VALUES_H
 HAVE_LIMITS_H
 SIZEOF_CHAR
 SIZEOF_SHORT
 SIZEOF_INT
 SIZEOF_LONG
 HAVE_MEMMOVE

gdki18n.h also depends on some things in glibconfig.h, but we
could get away with not installing gdki18n.h.
 
Perl does have architecture dependent headers; they go in

  ${libdir}/perl5/${arch}/${version}/CORE

But I don't think we have to get that fancy here.

> Raja> The problem with all three is that there are cases where is one
> Raja> more directory has to be put in INCLUDES.  This can be solved by
> Raja> a autoconf macro that figures out GTK_INCS and GTK_LIBS.
> 
> If you're going to require an autoconf macro, you might as well just
> have the macro run the tests you care about, and then glib.h can
> easily be platform independent.

That would make it impossible to quickly write small GTK programs
_without_ using autoconf. I don't think that would be very popular.
If just the include dir is autoconf'ed then it can just be put
in by hand for "hello_world" type programs. 

Regards,
                                        Owen