Re: distcheck fails with autotest: autom4te: cannot open ../../tests/testsuite.tmp: Permission denied

[Ralf Wildenhues]

* Jim Meyering wrote on Fri, Nov 02, 2007 at 07:32:34PM CET:
> Ralf Wildenhues <address@hidden> wrote:
> ..
> > | 2007-10-28  Jim Meyering  <address@hidden>
> > [...]
> > |         * 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