Re: should any build system legitimately change any tracked files?

From: Theodore Ts'o <tytso@mit.edu>
Date: Jan 19, 2018, 18:41 UTC
Message-ID: <20180119184128.GA643@thunk.org>
In-Reply-To: <alpine.LFD.2.21.1801191247250.10222@localhost.localdomain>

On Fri, Jan 19, 2018 at 12:51:52PM -0500, Robert P. J. Day wrote:

Show 7 quoted lines

> that's all the info i was given, but it *seems* clear that the build
> process itself was making changes to one or more tracked files.
> 
>   technically, i guess one can design a build system to do pretty
> much anything, but is it fair to say that this is a really poor design
> decision? admittedly, this isn't specifically a git question, but i'm
> open to opinions on something that strikes me as a bad idea.

I agree that in general it's a bad idea. I can see how it happens, though, which is because two things come into tension:

1) The general desire not to check in generated files into the git
repository --- including configure files generated by autoconf,
Makefiles generated by automake, libtool files, etc.

2) Wanting not to give users trying to build from source a non-hostile
experience.  Unfortunately autoconf/automake/libtool systems are
notorious for not having a stable interface, such that if you have the
wrong or outdated version of the tools, the results of generating the
configure, Makefile, etc., using a different version than what the
developer used.... well, your results may vary.

What I do is use "Maintainer mode" which means that the generated files are *not* automatically rebuilt by the build system unless you configure with --enable-maintainer-mode, and then I *do* check in the generated files into git. That way I can run with --enable-maintainer-mode, and check in updates to Makefile, configure, etc., as necessary when the input files change, but that way, end users don't have to worry getting ambushed by version skew caused by using an old (or unexpectedly newer) version of the autoconf/autoconf/libtool tools.

Heck, I even have had config.guess/config.sub change on me in incompatible ways(*), so I ship my own version and don't enable a blind update of those files from the upstream FSF sources --- mainly because I don't trust them to preserve a stable interface. Better that I manually pull them into the repo, and test them before I do a public release.

					- Ted

(*) Although to be fair it's been years since I've been screwed in this fashion. But once bitten, twice shy....