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.lattarini@xxxxxxxxx> > From: Stefano Lattarini <stefano.lattarini@xxxxxxxxx> > 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 n<bfriesen@xxxxxxxxxxxxxxxxxxx> > Signed-off-by: Stefano Lattarini <stefano.lattarini@xxxxxxxxx> > Pushed now. Regards, Stefano _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
