gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Gnu-arch-users] Managing changes to projects that use autoco nf/aut


From: Parker, Ron
Subject: RE: [Gnu-arch-users] Managing changes to projects that use autoco nf/automake with tla
Date: Tue, 6 Apr 2004 15:20:02 -0500

> From: Parker, Ron [mailto:address@hidden

> > The next idea is to exclude these files from source using
> > =tagging-method and .arch-inventory rules.
> 
> That's what I thought and Aaron Bentley suggested, off list, 
> what I was already contemplating, making them precious.

> > We use automake and autoconf.  We have all the generated 
> > files marked "precious", since local configuration 
> > differences aren't relevent to the project.  The files 
> > from which other files are generated (e.g. Makefile.am)
> > *are* considered source.

> So, unless someone gives me a good reason not to do this, 
> that is how I will
> handle it for now.

The problem with making auto* generated "source" files like configure,
Makefile.in, config.h.in or config.hin precious, is the very act of making
them precious effectively does a "tla rm" on them.  They are not preserved
in the archive in their original form, they are removed from the archive.  

This then results in a circular dependency.  It is the subtree's Makefile
that regenerates these files and the subtree's Makefile is generated by
doing a ./configure of the master package-framework project, which in turn
requires the existence of the subtree's configure and related files.

A possible solution is to edit the subtree's PLUGIN/AUTOCONF to autoreconf
the project, but this makes the assumption that any developer getting the
archive has a version of auto* that fairly well matches what the subtree was
expecting.  This is not necessarily the case.  

I had to update the configure.in and Makefile.ac of a GNU project to get it
to autoreconf and work with package-framework on my machine.  The package
was setup to use an oldish version of auto*, one which did not define
AUTOMAKE.  This resulted in package-framework's configure trying to
configure the subtree using "/bin/sh --gnits ...", where "/bin/sh
/.../automake --gnits ..." was desired.

So, for the time being, I have un-precioused these files so that Golum is no
longer interested in them and restored them to their original form.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]