On 08/24/2012 11:43 AM, Stefano Lattarini wrote:
Reference:
http://lists.gnu.org/archive/html/automake/2012-08/msg00025.html
On 08/15/2012 12:16 AM, Stefano Lattarini wrote:
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?
Since we've not managed to find a proper workaround yet, nor a consensus on
how this should be fixed in Autoconf, I want to revert the removal of support
for two-args (and three-args) AM_INIT_AUTOMAKE invocation in Automake 1.13.
Below is the proposed patch, that I'll push in a couple of days. Reviews
welcome.
Regards,
Stefano
-8-8-8-8-8-8-8-8-8-8-
From 2abe18335cffce365cbe09bdc1d0315f5ed8f24d Mon Sep 17 00:00:00 2001
Message-Id:
2abe18335cffce365cbe09bdc1d0315f5ed8f24d.1345801379.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 24 Aug 2012 10:47:17 +0200
Subject: [PATCH] AM_INIT_AUTOMAKE: allow obsolescent two-args invocation once
again
This partially reverts commit 'v1.12-67-ge186355' of 2012-05-25,
init: obsolete usages of AM_INIT_AUTOMAKE not supported anymore
Some users still need to be able to define the version number for
their package dynamically, at configure runtime.
Their user case is that, for development snapshots, they want to be
able to base the complete version of the package on the VCS revision
ID (mostly Git or Mercurial). They could of course do so by
specifying such version dynamically in their call to AC_INIT, as is
done by several GNU packages. But then they would need to regenerate
and re-run the configure script before each snapshot, which might be
very time-consuming for complex packages, to the point of slowing
down and even somewhat impeding development.
The situation should truly be solved in Autoconf, by allowing a way
to specify the version dynamically in a way that doesn't force the
configure script to be regenerated and re-run every time the package
version changes. But until Autoconf has been improved to allow
this, Automake will have to support the obsolescent two-arguments
invocation for AM_INIT_AUTOMAKE, to avoid regressing the suboptimal
but working solution for the use case described above.
See also:
http://lists.gnu.org/archive/html/automake/2012-08/msg00025.html
* NEWS: Update.
* m4/init.m4 (AM_INIT_AUTOMAKE): Support once again invocation with
two or three arguments.
* t/aminit-moreargs-no-more.sh: Renamed ...
* t/aminit-moreargs-deprecated.sh: ... like this, and updated.
* t/nodef.sh: Recovered test, with minor adjustments.
* t/backcompat.sh: Likewise.
* t/backcompat2.sh: Likewise.
* t/backcompat3.sh: Likewise.
* t/backcompat6.sh: Likewise.
* t/list-of-tests.mk: Adjust.
Suggested-by: Bob Friesenhahn nbfrie...@simple.dallas.tx.us
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Pushed now.
Regards,
Stefano
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
