[Top][All Lists]

[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: Mon, 5 Apr 2004 12:30:26 -0500

> From: Tom Lord [mailto:address@hidden

> I still want to say "don't use auto*" but, of course, that's not
> always an option.   

As shown by libneon in tla.  :-)

By the way, having worked a little bit with package-framework, I like it.
In some respects it is much simpler than auto*, of course it also lacks some
of the features, but those can easily be added as needed.  For example, I
tweaked my local build-tools/Makefiles/ to allow prefixing an
executable file name.  It wasn't something I absolutely had to do, but IMO
it was better than editing that project's rules to do the
prefixing in all the various rules.  Plus it was a good exercise in testing
package-framework's extensibility.  I wouldn't want to try to add that to
auto*, if it didn't already exist.  "Your trapped in a twisty series of m4
p4ss4ages, all alike.... A giant Perl attacks you from the darkness.... You
have died.... Reloading...".  Yuck.

> The next idea is to not generate those files in the source tree ---
> always use a separate build tree.

I build in src/=build, but it still modifies the files in the source
directory due to the way automake works, creating Makefile rules that update
the "source", etc. to match one's version of automake.

> 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. 
> *are* considered source.

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

reply via email to

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