Re: gnomes gtk+/glib fails VPATH install

[Gary V Vaughan <garyv aethos co uk>]

On Tue, Feb 17, 1998 at 11:36:53AM -0000, I <Gary> wrote:
Gary> I have started doing my gnome builds in a separate subdirectory so
Gary> that cvs update creates less noise... when running make install
Gary> from this directory after a successful build, the Makefile tries
Gary> to install $(srcdir)/glibconfig.h (which doesn't exist) instead of
Gary> ./glibconfig.h.
Gary> 
Gary> Two solutions (both require patching automake) come to mind:
Gary> 
Gary>  i) amend the loop in header.am to check for each file in the build
Gary>     directory first, and fall back on the srcdir if that fails:
Gary> [snip] 	
Gary> ii) check whether each file is listed in BUILT_SOURCES to decide if a
Gary>     build directory version exists:
Gary> [snip]
Gary> I prefer the former, as the other solution requires changes to
Gary> Makefile.am (listing offending headers in BUILT_SOURCES) -- and the
Gary> latter seems a bit hackish (I didn't test this one either!)
Gary>
Gary> Tom, can you ajudicate and include a patch for 1.2f? I expect other
Gary> install targets may require a parallel patch too?

On Tue, Feb 17, 1998 at 11:36:53AM -0600, Raja R Harinath <Hari> wrote:
Hari> Both solutions are wrong for `glibconfig.h'.  `glibconfig.h' is the
Hari> output of the `configure' process, and will pretty surely be system
Hari> specific.  It is not right to install it under $(includedir).  In its
Hari> current form, it has to be installed under $(exec_prefix).

That is a bug in Makefile.am, using the shipped Makefile.am glibconfig.h
will be installed to $(includedir) whether or not one of my patches has been
applied to automake.  

Part of a patch to fix this would be:

--- gtk+/glib/Makefile.am~	Wed Feb 18 09:39:25 1998
+++ gtk+/glib/Makefile.am	Wed Feb 18 09:51:36 1998
@@ -1,5 +1,7 @@
 ## Process this file with automake to produce Makefile.in
 
+archincludedir = $(exec_prefix)/include
+
 lib_LTLIBRARIES = libglib.la
 
 libglib_la_SOURCES = \
@@ -18,7 +20,9 @@ libglib_la_SOURCES = \
 		gutils.c
 
 include_HEADERS = \
-		glib.h \
+		glib.h
+		
+archinclude_HEADERS = \		
 		glibconfig.h
 
 libglib_la_LDFLAGS = -version-info 1:0:0

But I think this would cause problems when $(exec_prefix) != $(prefix)
because nobody will have (eg) /usr/local/i586/include in their include
search path when using #include <glib.h> in thier own projects (which is
the point of installing the headers after all).

Each of my patches will cause the generated Makefile to look for
glibconfig.h in the build directory (gtk+/i586 for me), because for a VPATH
build (ie $(srcdir) != .) glibconfig.h -- being a make-time generated file --
is not in $(srcdir).

Excerpts from gtk+/i586/glib/Makefile generated using automake-1.2e and
autoconf-1.12:

include_HEADERS = \
                glib.h \
                glibconfig.h

[...]

install-includeHEADERS: $(include_HEADERS)
        @$(NORMAL_INSTALL)
        $(mkinstalldirs) $(includedir)
        @list='$(include_HEADERS)'; for p in $$list; do \
          echo " $(INSTALL_DATA) $(srcdir)/$$p $(includedir)/$$p"; \
          $(INSTALL_DATA) $(srcdir)/$$p $(includedir)/$$p; \
        done
		  
Notice both glib.h and glibconfig.h are copied from _$(srcdir)_ to
$(includedir).

Now, regenerating Makefile using automake-1.2e-gv-patch-i (and autoconf-1.12),
the same targets read:

include_HEADERS = \
                glib.h \
                glibconfig.h

[...]

install-includeHEADERS: $(include_HEADERS)
        @$(NORMAL_INSTALL)
        $(mkinstalldirs) $(includedir)
        @list='$(include_HEADERS)'; for p in $$list; do \
	  test -f ./$$p || p=$(srcdir)/$$p; \
          echo " $(INSTALL_DATA) $$p $(includedir)/$$p"; \
          $(INSTALL_DATA) $$p $(includedir)/$$p; \
        done

Notice that here the target does not prepend $(srcdir) to glibconfig.h
because the file exists in . (the build directory), so glibconfig.h is
copied from the _build_ directory which is correct.

Hari> However, patch `ii' (headers in BUILT_SOURCES) may be useful in other
Hari> contexts. 

I am beginning to think that patch `ii' is perhaps the better solution too,
but it changes the semantics of automake rules which is probably undesirable.

Cheers,
	Gary V Vaughan.
-- 
{#include #.signature#}
WARNING:  Cannot find '.signature' template file

PGP signature