Re: [gtk-list] Re: Red Hat's gtk+-devel-1.0.4-1

[Michael Poole <poole graviton res cmu edu>]

johannes@nada.kth.se (Johannes Keukelaar) writes:

> See the FAQ, question 2.6:
> 
> 2.6 When compiling programs with GTK+, I get compiler error messages about not 
> being able to find "glibconfig.h".
> 
> The header file "glibconfig.h" was moved to the directory 
> $exec_prefix/lib/glib/include/. $exec_prefix is the directory that was 
> specified by giving
> the --exec-prefix flags to ./configure when compiling GTK+. It defaults to 
> $prefix, (specified with --prefix), which in turn defaults to /usr/local/.
> 
> This was done because "glibconfig.h" includes architecture dependent 
> information, and the rest of the include files are put in $prefix/include, which
> can be shared between different architectures. 

Okay, I feel obliged to point out that this is a pretty stupid place to put
architecture-dependent header files.  What is wrong with putting glibconfig.h
in $exec_prefix/include, which is conceptually the right place for
architecture-dependent header files?

The program I use to maintain separate spaces for architecture-independent
and architecture-specific files allows both $prefix/include and
$exec_prefix/include to both map to /usr/local/include once the package is
stowed in place, and DTRT for multiple architectures.  This doesn't require
funny hacks like "gcc -c `gtk-config --cflags` mysimpletest.c".  Are there
really package management programs that are so broken as to not allow that?

For example, consider scripts installed by automake-enabled makefiles --
they go to $prefix/bin, since the interpreter is the only thing that varies
from one platform to another.  This precludes using a symlink to top-level
directories as a packaging scheme.  Any package management program that
doesn't allow both $prefix/bin and $exec_prefix/bin to go to the same
place is broken.  This is all that is necessary to put header files in the
right place whether or not they're architecture-dependent, so I don't see
any reason not to do so.

-- Michael