Re: [gtk-list] Re: /usr/lib/glib/include and /usr/lib/Gtk--/include

[Raja R Harinath <harinath cs umn edu>]

Michael Babcock <mbabcock@la.creatureshop.henson.com> writes:
> Owen Taylor wrote:
> > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> > > I'm curious as to motivatio behind the decision to put glibconfig.h
> > > and gtk--config.h in /usr/lib/{glib,Gtk--}/include instead of
> > > /usr/include.  AFAIK, these are the only packages in all of Linux to
> > > handle files that must be included for compilation in this way, and
> > > make trying to build Makefiles using automake/autoconf unnecessarily
> > > unpleasant.  Why was it done?
> > 
> > See question 2.6 of the FAQ on http://www.gtk.org.
> 
> But the answer is wrong. /usr/include already has architecture dependent
> stuff, so the motivation to move glibconfig.h is bogus.

(Sorry to join this discussion so late.)

This is one case where the reality/FHS is at odds with the GNU coding
standards.  

According to the GNU directory structure, $includedir = $prefix/include.
Note specifically that it is not in $exec_prefix, which is what is
reserved for architecture/system specific stuff.  Unfortunately, it
doesn't specify an arch specific include directory.

However /usr is a special case, and /usr/include can and does include
arch specific stuff.  Packages like `libc' have been known special case
for /usr (not for include files, but for other things).  So, someone may
want to special case GLIB for --prefix=/usr to put glibconfig.h in
/usr/include.  Patches for this, if clean, should be accepted.

Interested people may also want to search for `FHS_COMPLIANCE' in the
`gnome-list' archive, though that talks about a related issue, special
casing for /opt.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash