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

[Ralf Wildenhues]

Hello Jim,

* Jim Meyering wrote on Fri, Nov 02, 2007 at 08:01:44PM CET:
> Ralf Wildenhues <address@hidden> wrote:
> > * Jim Meyering wrote on Fri, Nov 02, 2007 at 07:32:34PM CET:
> >> Ralf Wildenhues <address@hidden> 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