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
bfriesen@xxxxxxxxxxxxxxxxxxx, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
