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: >> .. >> > | 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 Why do it upon every commit? As long as everything is self-consistent, and "make check" passes, there's no need to set a new version number. If you run "make install" or "make dist", *then* it may need to be regenerated. > 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. Because these versions are post-2.61a, and pre-2.61b :-) > Oh well. Indeed. >> 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. > 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. Hey, I would never suggest limiting Autoconf's applicability. I just said "it would be nice", being pretty confident that was impossible. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
