Re: RFE: allow for computed version number

[Bruno Haible]

Ralf Wildenhues wrote:
> I have been playing with the idea of having two separate version strings.
> ...
> smells of the developer working around limitations of the tools, rather
> than the tools providing adequate functionality

Yes, exactly.

This approach of two pieces is useful for the PACKAGE name - after all,
even a "GNU Binutils for Fedora" is a "GNU Binutils", and the tarname
remains 'binutils' -, but not for the version.

> > Why AC_INIT(PACKAGE, VERSION) is bad
> > ====================================
> 
> I hear you.  When we go and revise newer interfaces, to find out they
> are not actually better than their older counterparts, we may need to
> ask ourselves if our strategy to move forward can be improved.  Such
> moves are painful, and they should be minimized, which in practice may
> mean that we should think harder when adding new interfaces.

Not "think harder", but "work in an early feedback loop with the users".
It may mean announcing more frequent prereleases. Or it can be achieved by
declaring some new features "experimental" (but documented!) and upgrading
them to "stable" only at the next release.

> > It would be good to be able to invoke AM_INIT_AUTOMAKE with options, and
> > be able to set the package and version names (with computed values)
> > separately.
> 
> So that then there would not be any version nor package information in
> files generated by automake and autoconf and config.status?

No version information, yes. The package information can stay there, since
it does not change between "./configure" and "make distclean".

> do you allow package and version information in config.status output,
> i.e., letting configure be rerun upon version change, in automake lingo,
>   CONFIG_STATUS_DEPENDENCIES = $(srcdir)/../version.sh
> 
> ?

This is undesired. Eric wants to make the version be `git-version-gen`,
which means that it changes at every git commit. We *don't* want to rerun
configure when the version changes.

> How should 'make dist' work in this case?

Find attached a prototype with diffs to Automake 1.11, and to GNU hello 2.4.

On GNU hello side, I added a script that computes the version number in some
way. and told automake how to retrieve the version number. Also, I moved the
version number out of hello.c, so that only a tiny version.c needs to be
recompiled when the version changes. In Makefile.am I added a dependency
for version.o and special CPPFLAGS for version.c. (It is a pity that adding
special CPPFLAGS for a single file requires the creation of an intermediate
library.)

On the Automake side, you find a prototype of a macro AM_INIT_VERSION. It can
be used in three ways:

- with a lazily computed version number (this is for projects where the version
  changes several times a day):

    AM_INIT_VERSION([$$version], [version=`sh $(top_srcdir)/gen-version`])

- with a version number that is known at configure time (for projects where
  the version number changes once a week):

    . $srcdir/version.sh # sets myversion
    AM_INIT_VERSION([$myversion])

- with a version number that is known at autoconf time (like the status quo
  in automake):

    AM_INIT_VERSION([3.14])
  or
    AM_INIT_VERSION([esyscmd([./gen-version])])

"make dist" computes the version number once, then computes the 'distdir'
variable from it, and passes it to a sub-make invocation, from where it
and the 'top_distdir' variable will be propagated to subdirectories.

Bruno

hello-patch
Description: Text Data

automake-patch
Description: Text Data