Re: git-version-gen and 'make install'

[Bruno Haible]

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