automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic package version numbers with Autoconf and Automake (was: Re:


From: Bob Friesenhahn
Subject: Re: Dynamic package version numbers with Autoconf and Automake (was: Re: Automake 1.12.0b test release)
Date: Tue, 14 Aug 2012 17:26:17 -0500 (CDT)
User-agent: Alpine 2.01 (GSO 1266 2009-07-14)

On Wed, 15 Aug 2012, Stefano Lattarini wrote:
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.

Yes, and in your suggested scenario, it is not possible to edit a file without adding a new changeset (Catch-22).

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.

Agreed.

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?

A script ("version.sh") is executed in order to obtain the package and version information. In the most common case, the version is a development "snapshot" and the version is based on the latest specified date in the ChangeLog file. For formal releases, the version is hard-coded in the script.

Any time that 'make' is executed is a candidate time for the package version to be changed. In the GraphicsMagick project, editing the top ChangeLog file causes configure to be re-executed (due to added rules). This assures that the version is always correct (at the expense of more compilation time).

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]