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

[Owen Taylor <otaylor redhat com>]

Michael Poole <poole@graviton.res.cmu.edu> writes:

> 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?

Reason 1: 

If the include files are normally, but not always in $prefix/include,
then 99% of packages will not compile correctly with split 
$prefix and $exec_prefix without manual tweaking. [ this is 
the main argument against $exec_prefix/include/ ]

Reason 2:

When I looked at existing packages, there was no standard location,
($pgklibdir/include/ was as common as anything), and without a
standard location, I figured it was better to keep things in
a directory that was closely associated with the package,
rather than some random directory.

Regards,
                                        Owen

> 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.