-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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'). > > 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. > > In the medium to long run, Autoconf should be changed to not depend > at autoconf run time upon a volatile version string. For example, > > AC_VERSION_STRING_FILE([.version]) > > could have semantics so that .version is read each time configure > is run. That would mean that the configure script itself doesn't > contain the version string (if this macro is used), but I think > that is an acceptable compromise. (Automake could let the .version > file be a config.status dependency automatically, of course.) 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. 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. > 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. > > 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. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki2lz0ACgkQ84KuGfSFAYCYqQCeM0lVQhxcSMREQmOkGF3HXMU6 0/8AoIVZ5BhjKWmnupyngsz0D52kJnTw =qeaZ -----END PGP SIGNATURE-----
