[PATCH] {master} AM_INIT_AUTOMAKE: allow obsolescent two-args invocation once again (was: Re: Dynamic package version numbers with Autoconf and Automake)
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
---
NEWS | 15 ++-
m4/init.m4 | 26 +++-
...s-no-more.sh = aminit-moreargs-deprecation.sh} | 18 ++-
t/backcompat.sh| 64 +
t/backcompat2.sh | 73 ++
t/backcompat3.sh | 147 +
t/backcompat6.sh
Re: Dynamic package version numbers with Autoconf and Automake (was: Re: Automake 1.12.0b test release)
On Tue, Aug 14, 2012 at 06:57:02PM -0500, Bob Friesenhahn wrote:
AC_INIT(m4_esyscmd([scripts/pkginfo.sh package_name]),
m4_esyscmd([scripts/pkginfo.sh package_version]),
m4_esyscmd([scripts/pkginfo.sh package_bugreport]))
Unfortunately, the values passed to AC_INIT are cached so even if
the configure script is run again, it uses the cached values rather
than the new values.
I've been doing a similar thing, though I do it directly in configure.ac
rather than using an external script:
AC_INIT(sbuild_m4_esyscmd_s([sed -ne
'/^Package:/{s/Package:[[:space:]][[:space:]]*//p;q}' VERSION]),
[sbuild_m4_esyscmd_s([sed -ne
'/^Version:/{s/Version:[[:space:]][[:space:]]*//p;q}' VERSION])],
[buildd-tools-de...@lists.alioth.debian.org])
In this case, the information is taken from a static file with the format:
Package: schroot
Version: 1.6.3
Release-Date: 23 Jul 2012
Released-By: Roger Leigh rle...@debian.org
Git-Tag: release/schroot-1.6.3
This is generated by the bootstrap script.
Package and Version are derived from NEWS (since this must be updated
for a release, we require the version here to be the definitive source
of the version.
The other date is taken from the release tag in git; if it's not a
release, i.e. isn't tagged, it's just left as Unreleased.
Your version is better, because it permits vanilla autoreconf to be
used. Providing that we have a stable interface for autoconf to
call an external script, packages could do whatever they wish to
provide the information. Maybe a single-argument AC_INIT which
just has a script file as its argument? However it's done, having
this standardised would be beneficial to all.
In addition to it invoking the script with arguments for
package, version and bugreport address, it might also be nice to
provide the ability to supply information for arbitrary other
stuff such as
- public git URI
- public website
- public bug tracker
- git release and distribution tags
- git branch
And perhaps also allow this to be extended by the builder/distributor,
for example with
- build date
- builder
- distribution
- distribution bug tracker etc.
These are all examples of things which are currently done by some
packages on an ad-hoc basis, but which would benefit from more
generalised support in autoconf. Maybe add a command-line option
to run additional script(s) to source supplementary/overriding
information?
On the automake side, I'm still using custom targets for git integration
with make dist which inject $(distdir) into a separate git branch and
tag that as a distribution; a separate step tags the release, which
is then distributed. If it's not possible to support directly in
automake, being able to disable tarball generation in the dist target
and do completely custom stuff there would be useful. In particular,
having a logical separation of releasing and distributing would be
good.
One thing which is currently done wrong is that some stuf, e.g.
gettext, tries to regenerate stuff at make dist time. This is
rather annoying, as it's creating updated versions of files /after/
you've tagged the release. This means you need to run make dist, then
tag, then run make dist again. While workable, it's easy to forget and
mess up the release process. When you're using a DVCS, this is the wrong
point. We only want to tag the release /after/ all sources changes have
been made and *committed*. Thus there are three steps:
1) release preparation
- updates any files e.g. gettext po files etc.
- commit any changes resulting from this step
2) release
- tags the repo with a signed release tag
3) distribution
- makes the distdir and injects it onto a distribution branch
- branch is tagged
- release tarball is obtained (if required) using git archive
to export the tagged distribution. Not needed for an all-git
workflow (e.g. future Debian git source package format).
The existing make dist does of course do everything in a single
step; but it would be nice if these were split into separate,
overridable/hookable targets, and tools like gettext updated to
run in the release prep stage.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Dynamic package version numbers with Autoconf and Automake
On Wed, 15 Aug 2012, Miles Bader wrote: (3) The final version info is updated (using VCS info and/or autoconf version info) at make time using a script, and when it changes, only causes a source file (e.g., version.c) to change. This means that although some things are rebuilt after a commit (version.o, and relinking of any binaries that use it), the amount of rebuilding is relatively minor while still yielding accurate info. Likewise, GraphicsMagick configures a version.h as well as a version file used for non-autotools builds under Windows. With the currently used mechanism, only the few files depending on version.h need to be rebuilt but the whole project relinks. If the project config.h was to be re-generated (seems to be necessary with new AC_INIT), then all of the source modules would need to be recompiled and relinked since everything depends on the configuration header. Bpb -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Dynamic package version numbers with Autoconf and Automake
On 08/15/12 08:45, Bob Friesenhahn wrote: On Wed, 15 Aug 2012, Miles Bader wrote: (3) The final version info is updated (using VCS info and/or autoconf version info) at make time using a script, and when it changes, only causes a source file (e.g., version.c) to change. This means that although some things are rebuilt after a commit (version.o, and relinking of any binaries that use it), the amount of rebuilding is relatively minor while still yielding accurate info. Likewise, GraphicsMagick configures a version.h as well as a version file used for non-autotools builds under Windows. With the currently used mechanism, only the few files depending on version.h need to be rebuilt but the whole project relinks. If the project config.h was to be re-generated (seems to be necessary with new AC_INIT), then all of the source modules would need to be recompiled and relinked since everything depends on the configuration header. Bpb I've had a similar complaint when using Autotest. In my project, the test suite depends on an M4 input file that has the project version encoded in it. cat test_suite/package.m4 # Signature of the current package. m4_define([AT_PACKAGE_NAME], [my_server]) m4_define([AT_PACKAGE_TARNAME], [my_server]) m4_define([AT_PACKAGE_MINOR_VERSION], 4.18) m4_define([AT_PACKAGE_VERSION], [4.18.5]) m4_define([AT_PACKAGE_STRING], [my_server 4.18.5]) Which is created by a makefile rule as suggested in the autoconf documentation: http://www.gnu.org/software/autoconf/manual/autoconf.html#Making-testsuite-Scripts So when I change the version of the package, I autoreconf, then make then autoreconf again. Scenario #2 - I have inherited a library versioning scheme that doesn't play nice with Libtool (an absolute requirement) when the Automake name is not encoded with the version - lib_LTLIBRARIES = libmy_server-4.18.la So every time I change the version argument to AC_INIT, I have to search around my makefiles for anything that references each library and make the same changes there. So I would be very interested in a solution to these issues. Cheers, Robert ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Dynamic package version numbers with Autoconf and Automake (was: Re: Automake 1.12.0b test release)
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?
Thanks,
Stefano
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Dynamic package version numbers with Autoconf and Automake (was: Re: Automake 1.12.0b test release)
On Wed, 15 Aug 2012, Stefano Lattarini wrote:
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.
Yes, and in your suggested scenario, it is not possible to edit a file
without adding a new changeset (Catch-22).
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.
Agreed.
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?
A script (version.sh) is executed in order to obtain the package and
version information. In the most common case, the version is a
development snapshot and the version is based on the latest
specified date in the ChangeLog file. For formal releases, the
version is hard-coded in the script.
Any time that 'make' is executed is a candidate time for the package
version to be changed. In the GraphicsMagick project, editing the
top ChangeLog file causes configure to be re-executed (due to added
rules). This assures that the version is always correct (at the
expense of more compilation time).
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Dynamic package version numbers with Autoconf and Automake (was: Re: Automake 1.12.0b test release)
The script I intend to use to obtain package information is in the
GraphicsMagick repository and produces information gleaned from a
'version.sh' script which has the smarts to produce some obvious
variable names.
echo `./scripts/pkginfo.sh package_bugreport`
graphicsmagick-b...@lists.sourceforge.net
% echo `./scripts/pkginfo.sh package_name`
GraphicsMagick
% echo `./scripts/pkginfo.sh package_version`
1.4.020120814
It is intended to be used like this in configure.ac:
AC_INIT(m4_esyscmd([scripts/pkginfo.sh package_name]),
m4_esyscmd([scripts/pkginfo.sh package_version]),
m4_esyscmd([scripts/pkginfo.sh package_bugreport]))
Unfortunately, the values passed to AC_INIT are cached so even if the
configure script is run again, it uses the cached values rather than
the new values.
The script:
#!/bin/sh
#
# Print the package version based on content of $srcdir/version.sh.
#
# This script is expected to be run under the context of a configure
# script (via AC_INIT) to dynamically determine the package version.
me=$0
info=$1
srcdir=`dirname $0`/..
value=
nl='
'
. version.sh
case ${info} in
package_bugreport )
value=${PACKAGE_BUGREPORT}
;;
package_name )
value=${PACKAGE_NAME}
;;
package_version )
value=${PACKAGE_VERSION}${PACKAGE_VERSION_ADDENDUM}
;;
* )
echo $me: Must supply argument {package_bugreport, package_name,
package_version}
exit 1
;;
esac
# Omit the trailing newline, so that m4_esyscmd can use the result directly.
echo ${value} | tr -d $nl
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Dynamic package version numbers with Autoconf and Automake
Stefano Lattarini stefano.lattar...@gmail.com writes: Actually, it depends. Where and why do you use such dynamically-computed version number in exactly? That seems the real question. My own method is to have: (1) The primary version number is based on VCS info (this is obviously unavailable for source trees not based on a VCS checkout). (2) The autoconf version number (in AC_INIT) is used as a backup/default only when VCS info is unavailable. This number is relatively static, and typically only updated after a release. (3) The final version info is updated (using VCS info and/or autoconf version info) at make time using a script, and when it changes, only causes a source file (e.g., version.c) to change. This means that although some things are rebuilt after a commit (version.o, and relinking of any binaries that use it), the amount of rebuilding is relatively minor while still yielding accurate info. -miles -- Non-combatant, n. A dead Quaker. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
