[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
RE: [Gnu-arch-users] Managing changes to projects that use autoco nf/automake with tla
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.
- RE: [Gnu-arch-users] Managing changes to projects that use autoco nf/automake with tla,
Parker, Ron <=