Dynamic package version numbers with Autoconf and Automake (was: Re: Automake 1.12.0b test release)

[Stefano Lattarini]

Hi Bob, I managed to find your old message about "dynamically computing
package versions for Automake and Autoconf".  Some initial comments
follows.  I'm adding the Autoconf list in CC:, because I believe this
is an Autoconf issue more than an Automake one.

On 05/20/2012 12:59 AM, Bob Friesenhahn wrote:
> Stefano,
> 
> This change will cause significant issues for GraphicsMagick unless there is 
> a workaround:
> 
>   - Support for the two- and three-arguments invocation forms of the
>     AM_INIT_AUTOMAKE macro will be deprecated in the next minor version
>     of Automake (1.12.1) and removed in the next major version (1.13).
> 
> GraphicsMagick invokes it like
> 
> AM_INIT_AUTOMAKE($PACKAGE_NAME,"${PACKAGE_VERSION}${PACKAGE_VERSION_ADDENDUM}",
>  ' ')
> 
> The reason is because it avoids needing to edit configure.ac (a really stupid
> practice)
>
I agree with this; with today's DVCS, it's very tempting (and IMHO useful)
to base a package's version number on the current revision number/SHA-1; so
that the version is bound to change with every commit, and forcing a full
re-autotooling + reconfiguration + rebuild of the package for every commit
sounds just crazy.

But then, I believe this is something that should to be fixed at the Autoconf
level.  I.e., the version number shouldn't be hard-coded in the generated
configure and config.status scripts, nor put in 'config.h' or other generated
headers -- or at least, we should be able to tell Autoconf not do that, and
how to fetch/define/compute the version number at runtime instead.

> every time a new release tarball will be cut. Instead the version information
> to apply is computed by a script which is sourced by configure.
> 
> What is the workaround for this?
>
Actually, it depends.  Where and why do you use such dynamically-computed
version number in exactly?

Thanks,
  Stefano