Re: [Gnu-arch-users] Managing changes to projects that use autoconf/automake with tla

[Tom Lord]

    > From: "Parker, Ron" <address@hidden>

    > I was wondering how Tom and others handled their local commits to projects
    > that utilize automake and autoconf.

For reasons quite independent of arch, I handle my projects that use
automake and autoconf by not using automake or autoconf :-)

But, really, you're talking about the general problem of "generated at
development time" files in a source tree (and committed along with the
source).

The GNU project has a coding standard that says you should distribute
projects with such files already there so that, for example, users
don't need to have autoconf/automake in order to build a package.
(Which is a nice theory that doesn't work out in practice all that
well, but that's anothe story.)   Consequently, projects like GCC keep
generated files under revision control and even advise contributors to
expect pointless merge-conflicts when updating their trees after
rebuilding the generated files.

Yours is a variation on that problem:

    > My situation is related to using diffutils in a nested project-framework
    > hierarchy.  It seems that when I "configure && make" the master project 
that
    > diffutils' aclocal.m4, config.hin, configure and Makefile.in get modified.
    > This isn't a problem, per se.  But it does result in about 13,000 lines of
    > "unnecessary" diff to diffutils.  These are diffs that I assume would 
differ
    > based upon the version of the auto tools on the machine where "configure"
    > was run.  My method to this point has been to revert these specific 
changes
    > before committing my quite minor changes to diffutils.

    > My question is this, am I just being pedantic by not checking in the 
changes
    > to these files?  Or should I not check in changes to them since others are
    > likely to be running a different version of autoconf/automake?  Is there a
    > better way to avoid committing changes to these files, while allowing them
    > to remain in their original form in the archive?

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

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

The next idea is to exclude these files from source using
=tagging-method and .arch-inventory rules.

Otherwise, you're stuck with them.

-t