Re: Dynamic package version numbers with Autoconf and Automake (was: Re: Automake 1.12.0b test release)

[Roger Leigh]

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])],
        address@hidden)

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 <address@hidden>
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/Linux    http://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