Re: xxxConf.sh files (Re: Patch for gnome-libs)

[Raja R Harinath <harinath cs umn edu>]

Elliot Lee <sopwith@redhat.com> writes:
> On 14 Mar 2000, Raja R Harinath wrote:
> > Dan Winship <danw@helixcode.com> writes:
> > > > A fixit item for 2.0.
> > > 
> > > If we're moving things around, it would be nice to put gnome-config
> > > scripts into $(libexecdir) ["The directory for installing executables
> > > that other programs run."] rather than $(libdir) ["The directory for
> > > installing object code libraries."]. (Because they're not the same
> > > everywhere.)
> > 
> > Yep.  Actually, I think the current HEAD gnome-libs installs them into
> > $(datadir)/gnome/conf/2, which is even worse than $(libdir).
> 
> The set of libraries needed to use a specific package depends on which
> gnome-libs version you are using, hence the change.

I have no problem with the gnome/conf/2 part, it's the $(datadir) part
that I am not too happy about.
 
> > > gnomesupport.h and glibconfig.h don't belong in subdirs of $(libdir)
> > > either, but unfortunately the GNU standards say you shouldn't have
> > > architecture-dependent config files, so autoconf doesn't provide any
> >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > better place to put them.
> >
> > I know.  We did quite a bit of soul-searching ;-) when we put those
> > files into $(libdir).  IIRC Owen Taylor suggested, and Tom Tromey
> > seconded, that $(pkglibdir)/include was as sane a place as any.
> >
> > BTW, ITYM "architecture-dependent header files".  I don't know if they
> > are explicitly forbidden, or just not supported. 
> 
> Whatever the GNU standards say, the reality is that header files are very
> system- and architecture-dependant, so putting new header files under
> $(libdir) is unnecessary.

Say, I install gnome-libs on Linux and Solaris and compare any random
gnome-libs header file on these two systems, it would be textually the
same: except for gnomesupport.h, which is why it is in $(exec_prefix).

Yes, header files are architecture dependent, but you can capture much
of the dependence in a couple of headers, and the rest can (portably)
be used in different systems without altering their text.  We can get
away with putting those "highly"-architecture-dependednt files in
$(libdir)/... and sharing the rest of the stuff in $(includedir).

Also, the GNU notion if $(includedir) == $(prefix)/include is probably
different from the FHS notion of /usr/include (I think FHS considers
/usr/include as architecture dependent).  So, on FHS systems, it may
be OK to put gnomesupport.h into /usr/include, but that logic doesn't
carry over to the GNU layout.

- 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