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

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Bruno Haible on 7/21/2008 5:05 PM:
> 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.

In this case, both autoconf and automake have a way to avoid the hardcoded
m4 dependency.  I frequently avoid the 'make install' step in the
modify-compile-test cycle of m4 by setting M4=path/to/m4/devel/tests/m4 in
the environment, so that the autotools pick up the uninstalled m4.  But
yes, I agree that not all packages are like the autotools with handy
overrides in place, nor are all packages like m4 to allow running with
uninstalled binaries.

> 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.

Which is exactly what GNUmakefile currently does - the version string is
stale during development, and only updated at interesting moments (and
with recent changes, you can use cfg.mk to define which moments are
interesting in your development cycle).

> 
> 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.

Yes, that is the direction that I think we should eventually reach, but it
takes coordination between the autotools, as well as a design that
everyone is happy with.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki2mRUACgkQ84KuGfSFAYCKjgCcDmUmGPpXlt7SMAjg7nQLxlFt
KZwAn1HAF9D0X59zPVlWLWT7bCWMOYVG
=6qGb
-----END PGP SIGNATURE-----