Re: RFE: allow for computed version number

[Ralf Wildenhues]

Hi Bruno,

thanks for the good writeup!

* Bruno Haible wrote on Sun, May 24, 2009 at 03:15:47AM CEST:
> It has been mentioned in a discussion [1][2][3]
>   "In the medium to long run, Autoconf should be changed to not depend
>    at autoconf run time upon a volatile version string."
> and
>   "the goal is that the version string should _not_ appear in
>    config.h, so there should be _no_ configure output that changes in content
>    due to a version string change."

For the Automake package itself, I have been playing with the idea of
having two separate version strings.  One, the current VERSION, changes
only after a release, or, more precisely, reflects that we are after the
last tagged version.  The other shows the full per-commit version string.

I fully understand that this may be a weird solution to use in general,
smells of the developer working around limitations of the tools, rather
than the tools providing adequate functionality, and I must admit of not
having put further thought into the issue yet.  This would be
implementable without any changes to autotools AFAICS.

> 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.

> 2) The propagation/substitution mechanism through 'configure', 'config.status'
>    etc. is not adequate for values that change before "make distclean". See
>    above.

Good point.

> Temporary hack #1
> =================
> 
> In gettext 0.17 I used this mechanism for a computed version number:
> - Use AC_INIT without arguments.
> - Then compute the version number.
> - Then use the two-argument form of AM_INIT_AUTOMAKE.
> 
> -----------------------------------------------------
>   AC_INIT
>   AC_CONFIG_SRCDIR(...)
>   . $srcdir/../version.sh
>   AM_INIT_AUTOMAKE([gettext], [$VERSION_NUMBER])
> -----------------------------------------------------
> 
> The drawback of this approach is that it's not possible to pass
> automake options to AM_INIT_AUTOMAKE. Ralf mentions in [4] that some
> automake options can only be passed this way, not through the Makefile.am.

Note that you can use the optional third argument to AM_INIT_AUTOMAKE,
[NO-DEFINE], to keep PACKAGE and VERSION from showing up in config.h.
(I'm mentioning it here for completeness only, as it of course still
causes autotools to be rerun, all it avoids is the lots of rebuilds due
to changed config.h.)

> 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?

How should 'make dist' work in this case?

Or 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

?

> I'm *not* asking for a specific way of handling the version in a separate
> file; simply to allow any way of computing the version (e.g. fetching it
> from a shell script, by calling git-version-gen, etc.) Rationale: There
> is more than one type of distributed VCS. Also, we need time to experiment
> with this version propagation in order to find out the best way of doing it.

Understood.

Thanks,
Ralf