autoconf
[Top][All Lists]
Advanced

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

Re: Autoconf/Automake is not using version from AC_INIT


From: Peter Johansson
Subject: Re: Autoconf/Automake is not using version from AC_INIT
Date: Tue, 12 Jan 2021 20:23:44 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Hi Bob,

On 12/1/21 10:35 am, Bob Friesenhahn wrote:
I recently updated GraphicsMagick to use the 5 argument form of AC_INIT and the one argument form of AM_INIT_AUTOMAKE.  I also used m4_esyscmd to get version info from an external script.  The invokation looks like this:

AC_INIT(m4_esyscmd([./version.sh packagename]),
        m4_esyscmd([./version.sh packageversion]),
        m4_esyscmd([./version.sh packagebugreport]),
        m4_esyscmd([./version.sh packagetarname]),
        m4_esyscmd([./version.sh packageurl]))

Today I noticed that 'make dist' is producing the wrong tarball package version.  Instead of producing the expected version, the tarball version matches the date of the configure.ac file.

This is what comes out of the version.sh script:

./version.sh packageversion
1.4.020210110%

The version.sh script bases the package version on the most recent entry in the ChangeLog file.

This is what is claimed to be the tarball version several times already:

  GraphicsMagick-1.4.020210106.tar.gz


The problem is that there is no dependency in the Makefile telling that autoconf need to be rerun when the version has changed. Automake has the variable 'CONFIGURE_DEPENDENCIES' for this purpose, so adding

CONFIGURE_DEPENDENCIES = ChangeLog

would solve the issue but will cause a rerun of autoconf every time you touch ChangeLog. Rather you want a stamp file, whose timestamp only changes when the output of 'version.sh packageversion' changes. Something along the lines:

$(srcdir)/.version: ChangeLog
    cd $(srcdir) && ./version packageversion > .version-tmp && move-if-change .version-tmp .version

EXTRA_DIST = $(srcdir)/.version

I don't see any way without a specific file holding the timestamp on when the version was last updated.


Cheers,

Peter
||



reply via email to

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