* Jim Meyering wrote on Fri, Nov 02, 2007 at 07:32:34PM CET: > Ralf Wildenhues <Ralf.Wildenhues@xxxxxx> wrote: > .. > > | 2007-10-28 Jim Meyering <meyering@xxxxxxxxxx> > > [...] > > | * tests/Makefile.am ($(srcdir)/package.m4): Depend on Makefile, > > | not configure.ac, now that the version number changes automatically. > > > > 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 substituted correctly. Which doesn't happen ATM. So it should be AC_SUBST([CONFIGURE_DEPENDENCIES], [VERSION]) If you generate VERSION by configure, you have a nice circular dependency. Yuck yuck. Also, why is the current version something like 2.61a-248-dc51? That compares wrongly in order with 2.61b which is what post 2.61a CVS versions had. Oh well. > 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. FWIW one goal of Autoconf is to enable packages to bootstrap. The more requirements you allow to add (decent shell, ...), the less packages will be able to use that Autoconf to bootstrap. For example should Bash be allowed to require for its configuration a shell better than current bash? Just saving a few forks IMVHO doesn't justify limiting Autoconf's wide applicability. Cheers, Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
