Re: gnomes gtk+/glib fails VPATH install

[Gary V Vaughan <garyv aethos co uk>]

...but do either of the patches I proposed at the start of this thread
qualify as desirable for inclusion in the automake, as a fix for generated
header installation in a VPATH build?

I still think that it is a bug for automake to generate an install rule
which looks for a built header in $(srcdir) when it will always be located
in the build directory.


On Wed, Feb 18, 1998 at 10:38:45 +0000, I <Gary> wrote:
Gary> It occurs to me that headers are implicitly architecture
Gary> dependent anyway, rendering this a non-issue.

On Mon, Feb 23, 1998 at 12:10:01AM -0700, Tom Tromey <Tom> wrote:
Tom> Most headers are not implicitly architecture dependent.  Many headers
Tom> are perfectly architecture independent.  That is why includedir is
Tom> under prefix and not exec-prefix.
Tom> 
Tom> For instance, nearly every Gtk header is architecture independent.  I
Tom> can provide many, many examples if this isn't convincing enough (e.g.,
Tom> <tcl.h>, <tk.h>, ...).

In isolation (having just had a look) it seems that they are, but if you
track the dependencies it seems that the critical file is glibconfig.h which
says (for example) `#define HAVE_VFPRINTF 1', which is not necessarily true
if I use these exact same headers on another architecture.  I guess that the
#def wrappers for existence of headers are fine, but in reality it is rare
(in these days of automake and autoconf) to find a package which does not
ultimately rely on #defs for the existence (or otherwise) of library
functions and other things which are not known when the header is used at
link time (except by inclusion of an architecture dependant file -- probably
config.h).

By your argument, you imply that glibconfig.h (and perhaps others) should be
installed below $(exec_prefix).  I would not disagree, but this is a bug in
the Makefile.am in the gtk distribution, and I am not trying to address this
with my fixes.

Tcl (and I suspect any other packages you may provide as examples) hinges on
tclConfig.sh which is admittedly not a header, but the tcl headers do
require compilation with the pre-processor defines listed in the config file
to work correctly on the host which generated that config file.  I am
rambling, this is a different problem...

Tom> gcc headers (if I understand your meaning -- the ones made by
Tom> fixincludes?) are a special case, and they are stored in exec-prefix
Tom> anyway.

Yes, you are right.  Citing gcc headers was a poor example.

Tom> Putting architecture dependent headers into includedir is losing for
Tom> anybody who actually shares $prefix.

One of the (very few) aspects I dislike about the automake/autoconf
packaging mechanism is that one is always left with a dependency on many
compile time defines in the installed headers.  I had begun to think that
the solution was to do some kind of selective pre-processing which would
remove or include blocks of a header file depending on whether the autoconf
had #defined pertinent macros.  I think I see now that the problem lies not
in the #def values themselves, but in separating architecture dependent and
independent header files... something which is not addressed by
autoconf/automake, but I imagine could be done.

To start the ball rolling here is my proposal to allow autoconf/automake
built packages to cooperate in maintaining architecture independance (there
are forward references, so you probably need to read this twice to follow
it):

  i) At configure-time, before running any tests autoconf will load a
     global-cache from $(exec_prefix)/share/autoconf/config.cache
     
     (this file holds architecture-dependent details, hence exec_prefix)
     
 ii) ./configure runs as normal, taking cache values if available
     or else running appropriate tests.
     
iii) Makefiles and config.h (or equivalent) are generated as normal.

 iv) Objects, libraries and executables are generated as normal by targets
     in the generated Makefile, but -I$(exec_prefix)/share/autoconf must be
     added to CPPFLAGS.
     
     This allows the preprocessor to find any architecture dependant include
     files referenced by other installed package headers, for example
     $(exec_prefix)/share/autoconf/glib/config.h
     
     Automake will need to insert target dependencies on any architecture
     dependant config files into the generated Makefiles so that a matching
     $(prefix)/share/autoconf/glib/configure (for example) can be used to 
     build a missing config.h (when I am using these headers on a different
     host to that for which the headers were installed, for example).

  v) At install-time, libraries, executables etc. install below
     $(exec_prefix) as normal;  non-generated headers install below
     $(prefix) as normal; generated headers are installed below either
     $(prefix) or $(exec_prefix) as determined by the package maintainer and
     whether the header file makes decisions based on the build environment
     (e.g. is vfprintf() in libc); config.h is installed to
     $(exec_prefix)/share/autoconf/$(PACKAGE)/config.h, and the configure
     script is installed to $(prefix)/share/autoconf/$(PACKAGE)/configure; 

There are problems with this (when multiple prefix directories are used for
example), but it is a start.

Cheers,
	Gary.
-- 
  ___              _   ___   __              _             
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___ 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/                      /___/               
http://www.cl.cam.ac.uk/PGP/pks-commands.html#extract      
http://pgp.ai.mit.edu/~bal/pks-commands.html#extract

PGP signature