* 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
