Re: [PATCH] {master} AM_INIT_AUTOMAKE: allow obsolescent two-args invocation once again

[Stefano Lattarini]

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: <address@hidden>
> From: Stefano Lattarini <address@hidden>
> 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<address@hidden>
> Signed-off-by: Stefano Lattarini <address@hidden>
>
Pushed now.

Regards,
  Stefano