[Top][All Lists]
[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/