Eric Blake wrote on Friday:
> 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
Err. Sometimes packages can be tested by running without doing "make install".
But in other situations - say, m4, when you have a program called 'autoconf'
or 'automake' which invokes /opt/gnu/bin/m4 (hardcoded) - the "make install"
is part of the modify-compile-test cycle.
> 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.
Now, here, you are getting closer to the heart of the problem.
The problem is that for decades, a version number changed sufficiently rarely
that it was ok to assume a fixed version number for all the compilation. So,
autoconf has added macros VERSION and PACKAGE_VERSION, respectively, and made
them available to all substituted files, Makefiles, etc.
And now, with git-version-gen, you are putting yourself in a situation where
the simplest correction of a typo in a source comment causes the version number
to change - by adding a suffix. And doing a "git commit" also causes the version
number to change.
I can see two ways out:
A) Reduce your expectations, and accept that modified programs show the same
version number as the unmodified programs. Like it was for the last 20
years. When users want to test a modification in a "modify-compile-install-
test" cycle, they are not interested in the output of the --version option.
B) Change the build process of your package so that a change in the version
number results in less recompilations. That means, in particular:
*Don't* use VERSION and PACKAGE_VERSION any more.
In practice, there are at least three ways of reducing the dependencies of
the version:
1) Create a source file that defines only one thing: namely, a variable
containing the version number. Then, when the version number changes,
"make" needs only to compile this small file and to relink all
executables.
2) Likewise, but put this object file into a shared library. Unless the
user has configured the package with --disable-shared, when the
version number changes, "make" will only rebuild this shared library.
3) Store the version number in a data file. This means, the --version
option will need to open a data file to fetch it. The upside is that
after a version change, "make" recreates only one single tiny file
and is very quick.
More variants certainly exist; these are just the first three ones that
came to my mind.
Bruno
