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

[Parker, Ron]

> 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/programs.mk 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 Makefile.in 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" Makefile.in, 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. 
> 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.