Hello Jim, * 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? > If you run "make install" or "make dist", *then* it > may need to be regenerated. 'make install' really should not change anything in an up to date build tree. If I do 'make all' as user, and install as root, then return to be user, then I won't be able to remove root-owned files. With dist, things are less clear, but also I'd expect it not to rebuild any of the stuff that 'all' has already built successfully. > >> It's a shame to pessimize the code, making everyone incur the subshell > >> cost, to work around such a bug (assuming it is one). > >> It'd be nice if there were a way to require a working shell. > > > > You mean you would completely refuse to build on a current GNU/Linux > > just because its bash has one bug? Autoconf caters to shells such as > > Solaris sh, and in comparison it has lots of ugly issues. > > Hmm.. perhaps you're misreading my words? > Of course I don't mean that. Yes, I was reading much more into them than you actually wrote, also I did not read carefully at all. Apologies for that. > > Just saving a few forks IMVHO doesn't justify limiting Autoconf's wide > > applicability. > > Hey, I would never suggest limiting Autoconf's applicability. > I just said "it would be nice", being pretty confident that was > impossible. Good then we're all violently agreeing once my human language parser works again. ;-) Cheers, Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
