Re: GNUmakefile and 'make install'

[Eric Blake]

Paul Eggert <eggert <at> CS.UCLA.EDU> writes:

> 
> Eric Blake <ebb9 <at> byu.net> writes:
> 
> > Would anyone object to modifying GNUmakefile to also cause 
> > recompilation for new version info prior to any 'make install' of a VCS 
> > snapshot development build, when .tarball-version is lacking?
> 
> Why not also cause "make all" to recompile new version info as needed?

Avoiding recompilation during 'make all' due to a version change was the very 
reason that git-version-gen was invented.  Recompiling the version string is 
EXPENSIVE - it costs a LOT of time to recompile the world because config.h was 
touched because autoconf reran to pick up a new version string.

In the developer's sandbox, you should not care what the version is, therefore, 
development and incremental compiles should NOT be penalized by always keeping 
the version string up-to-date.  But once you type 'make install' 
without .tarball-version, you are letting a development build leave the 
sandbox, and it is nicer to have the version to be reasonable, particularly 
since it does not (or at least should not) match the version string of any 
release tarball.

> That would conform to the GNU coding standards for developers and
> installers both.

But at too high a cost for my liking.

One other possibility I've thought about.  We could have 'make install' check 
git-version-gen, and abort rather than install if it is out-of-date with 
reality (of course, if .tarball-version exists, it will never be out-of-date).  
Since it avoids recompilation during 'make install' for developers, it obeys 
the letter of the law; but it seems to break the spirit of the law for failing 
to install at all.  If we go this route, then the failure output from make must 
be explicit that 'make install' was aborted due to version mismatch and 
that 'autoreconf' or 'make dist' will fix it.

-- 
Eric Blake