Re: GNUmakefile: git-version-gen, maintainer-check, install

[Ralf Wildenhues]

* Eric Blake wrote on Thu, Aug 28, 2008 at 02:17:01PM CEST:
> According to Ralf Wildenhues on 8/28/2008 1:39 AM:
> > 
> > Pause is not good.  It doesn't scale with system speed, it doesn't
> > parallelize, who looks at build logs interactively anyway, except
> > to get annoyed by the fact that it's still not done yet?
> 
> I suppose it could be made a bit smarter with 'test -t 1' - only pause if
> stdout is a tty.  The point of a pause is for someone interactively typing
> 'make install', and not an automated script (of course, using 'test -t'
> won't help users who do 'make install | tee log').

FWIW, I almost always pipe through tee; if only to allow unlimited
scrolling (when not using 'screen').

> > This whole issue is getting more and more abstruse, ever since it
> > was decided that the version should contain the git string, but at
> > the same time autoconf should not rerun upon each version string
> > change.
> 
> It really boils down to the fact that if we want a git string in the
> version, then that version string should _not_ appear in config.h.

Not only config.h.  Any file generated by config.status really,
otherwise we're no further.

Which brings me to a different, and altogether trivially simple
solution: just don't change the version string passed to configure.ac
currently.  Just don't let it get into the autotools machinery at all.
Decide for yourself that some file, call it .devel-version, contains the
current version, and let some private source file be generated from it.
Leave
  AC_INIT([foo], [2.1a], [bugme])

untouched.  Then ./configure outputs 2.1a, while ./prog outputs
something like 2.1a-g83akb.

Problem solved.  No need whatsoever for autotools to change.  At release
time, you can then change the string in configure.ac and rebuild.  No
need for complicated rebuild machinery in GNUmakefile.

> I'd much rather have it so that adding the notation in configure.ac on how
> the version string is generated does _not_ require rerunning configure.

The question is: where do you want that git version number to really
appear?  Which files do you want to have carry the correct devel version
output.  config.log?  ./config.status --version?  ./program --version?
./program --version showing versions of a number of libraries it uses?

This is really the fundamental question that you need to find an
acceptable compromise on.

> Again, 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.  Rather, the smarts on version updates
> should be migrated into the Makefile.  Maybe something like:
> 
> AM_VERSION_STRING([.version], [command to generate .version contents])
> 
> then Automake emits the code that runs command on every make invocation,
> and updates .version if the version output has changed.

You can implement that in Makefile.am in a handful of lines.
If there is a generally-agreed-upon way to do this, I'm sure it will
be beneficial to turn it into a gnulib module or an Automake macro
(although it will be quite a trivial one).

FWIW, I'd put the version string not in a variable in a .c file,
but rather as a #define in a header file.  That way, it's easier
to let it end up in a shared library (where otherwise you have to
think about variable name clashes again).

> > That being said, I don't care much whether your patch is put in
> > place as an intermediate measure.
> 
> Yes, I agree that everything in GNUmakefile is only a stop-gap measure
> until we have built in a better design into autoconf and automake.  I'll
> wait for feedback on whether I should use 'test -t' before committing.

No idea, really.

> > BTW, why are you removing autom4te.cache?  Working around some bug?
> 
> That's pre-existing.  Jim added it, rather than using autoreconf -f, to
> guarantee that any stale entries in the cache are not used at release
> time.  I don't have any opinion on whether it should stay or go.

Hmm.

Cheers,
Ralf