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
