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

[Jim Meyering]

Ralf Wildenhues <address@hidden> wrote:

> * 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

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.