[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: GNUmakefile: git-version-gen, maintainer-check, install
Date: Thu, 28 Aug 2008 06:17:01 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080708 Thunderbird/ Mnenhy/

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             address@hidden
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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]