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

[Elliot Lee <sopwith redhat com>]

On 14 Mar 2000, Raja R Harinath wrote:

> I have no problem with the gnome/conf/2 part, it's the $(datadir) part
> that I am not too happy about.

Sorry 'bout the confusion. I disagree with putting them in $(libdir) or
$(libexecdir) because they are architecture-independant (AFAIK). If they
are indeed arch-dependent, then they probably still go under libdir and
not libexecdir - they're data files internally read by gnome-config, not
really programs that get run (if you want technicalities, they get sourced
not run :)

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

Are there any systems at all where $(exec_prefix)/include cannot be
arch-dependant? Maybe if we just set execincludedir=$(exec_prefix)/include
(which by default == $(includedir)), then we can install all these funky
header files there.

-- Elliot
"Moron of the week" for four years running