Re: [PATCH] Fix dependence on computed configure variables.

[Joel E. Denny]

On Sun, 27 Jul 2008, Eric Blake wrote:

> The better way to handle this is to replace any previous dependence on
> configure.ac with a dependence on .version rather than configure; this is
> already documented in git-version-gen.  For an example, that is how
> autoconf does it in man/Makefile.am.  The idea here is that gnulib's
> git-version-gen/GNUmakefile combo guarantees that .version is deleted
> prior to any build where you care about accurate version information,

Bison's test suite, for example, depends on several configure variables, 
so it needs to declare configure.ac or configure as a dependency anyway.

In general, declaring a dependence on .version could allow two version 
strings to exist in the same working copy.  For example, the bison 
executable reports its version as VERSION.  If the test suite were to 
depend on .version, then it would be possible to write test cases that 
could incorrectly fail or pass when the two versions are out of sync.  
There's already a test case for Bison's %require directive (which checks 
the Bison version) that has this potential.

Should we always use .version instead of VERSION or PACKAGE_VERSION 
everywhere in order to avoid situations like this?

> and
> for all other development builds, the cost of recompiling various files
> just to pick up a version change outweighs the speed of building with
> stale version information.

Doesn't a change to configure usually entail a lot of rebuilding anyway? 
Does depending on .version instead really improve the situation much?

Maybe the top-level Makefile.am should declare .version to depend on 
configure so they don't get out of sync.

Thanks.