Ralf Wildenhues <Ralf.Wildenhues@xxxxxx> wrote: > * Jim Meyering wrote on Fri, Nov 02, 2007 at 08:01:44PM CET: >> Ralf Wildenhues <Ralf.Wildenhues@xxxxxx> wrote: >> > * Jim Meyering wrote on Fri, Nov 02, 2007 at 07:32:34PM CET: >> >> Ralf Wildenhues <Ralf.Wildenhues@xxxxxx> wrote: >> >> .. >> >> > Yuck, that's ugly. Should we have a VERSION file, changed by a commit >> >> > hook or something like that? >> > >> >> A non-version-controlled file that's updated upon every commit? >> >> Maybe. Or have configure generate this VERSION file. >> > >> > Well, actually the use of m4_esyscmd in AC_INIT means that we have to >> > regenerate configure upon every commit, so that PACKAGE et al are >> >> Why do it upon every commit? > > Because then config.status would substitute the right value all the > time, no? > >> As long as everything is self-consistent, and "make check" >> passes, there's no need to set a new version number. > > But wouldn't the version string give the wrong number then? > As in: we get a testsuite failure listing 2.61a-248xxx but really the > user was already at 253xxx? Hi Ralf, As long as the tools are created first, and then used to regenerate everything tested by "make check" (including themselves), there is no need to adjust the version string after every commit. So a build+check would have to be slightly different to accommodate this. Here's a proposed new set of commands for README-hacking: diff --git a/README-hacking b/README-hacking index 32c4a47..61616fe 100644 --- a/README-hacking +++ b/README-hacking @@ -33,12 +33,15 @@ You can get a copy of the source repository like this: The next step is to generate files like configure and Makefile.in: $ cd autoconf - $ ( PATH=`pwd`/tests:$PATH; autoreconf -vi ) + $ autoreconf -vi -And there you are! Just +Since we're building autoconf itself, and its tests are picky, the +following procedure includes an extra step to ensure that some +generated files are regenerated using the tools just build by "make": $ ./configure $ make + $ ( PATH=`pwd`/tests:$PATH; autoreconf -vi ) $ make check At this point, there should be no difference between your local copy, That covers the initial bits. Hmm... with GNU Make, it'd be easy. Just export PATH=`pwd`/tests:$PATH in GNUmakefile. Hey, this problem arises only with "developers", so how about assuming GNU make and doing just that? I think it's certainly fair to assume people doing autoconf development have GNU make installed. "make dist" already requires that. ... > Good then we're all violently agreeing once my human language parser > works again. ;-) Phew. I was a little worried there for a minute :-) _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
