[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] {master} AM_INIT_AUTOMAKE: allow obsolescent two-args invoca

From: Stefano Lattarini
Subject: Re: [PATCH] {master} AM_INIT_AUTOMAKE: allow obsolescent two-args invocation once again
Date: Sun, 26 Aug 2012 13:26:32 +0200

On 08/24/2012 11:43 AM, Stefano Lattarini wrote:
> Reference:
> <>
> 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
>>>  ' ')
>>> The reason is because it avoids needing to edit (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:
> <>
> * NEWS: Update.
> * m4/init.m4 (AM_INIT_AUTOMAKE): Support once again invocation with
> two or three arguments.
> * t/ Renamed ...
> * t/ ... like this, and updated.
> * t/ Recovered test, with minor adjustments.
> * t/ Likewise.
> * t/ Likewise.
> * t/ Likewise.
> * t/ Likewise.
> * t/ Adjust.
> Suggested-by: Bob Friesenhahn n<address@hidden>
> Signed-off-by: Stefano Lattarini <address@hidden>
Pushed now.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]