[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: distcheck fails with autotest: autom4te: cannot open ../../tests/tes
From: |
Jim Meyering |
Subject: |
Re: distcheck fails with autotest: autom4te: cannot open ../../tests/testsuite.tmp: Permission denied |
Date: |
Fri, 02 Nov 2007 20:01:44 +0100 |
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.
- distcheck fails with autotest: autom4te: cannot open ../../tests/testsuite.tmp: Permission denied, Benoit SIGOURE, 2007/11/01
- Re: distcheck fails with autotest: autom4te: cannot open ../../tests/testsuite.tmp: Permission denied, Ralf Wildenhues, 2007/11/02
- Re: distcheck fails with autotest: autom4te: cannot open ../../tests/testsuite.tmp: Permission denied, Benoit SIGOURE, 2007/11/02
- Re: distcheck fails with autotest: autom4te: cannot open ../../tests/testsuite.tmp: Permission denied, Ralf Wildenhues, 2007/11/02
- Re: distcheck fails with autotest: autom4te: cannot open ../../tests/testsuite.tmp: Permission denied, Jim Meyering, 2007/11/02
- Re: distcheck fails with autotest: autom4te: cannot open ../../tests/testsuite.tmp: Permission denied, Ralf Wildenhues, 2007/11/02
- Re: distcheck fails with autotest: autom4te: cannot open ../../tests/testsuite.tmp: Permission denied,
Jim Meyering <=
- m4_version_compare and new version numbering [was: distcheck fails with autotest...], Eric Blake, 2007/11/03
- Re: m4_version_compare and new version numbering, Jim Meyering, 2007/11/03
- Re: m4_version_compare and new version numbering, Benoit SIGOURE, 2007/11/03
- Re: m4_version_compare and new version numbering, Jim Meyering, 2007/11/03
- Re: m4_version_compare and new version numbering, Andreas Schwab, 2007/11/03
- Re: m4_version_compare and new version numbering, Jim Meyering, 2007/11/03
- Re: m4_version_compare and new version numbering, Andreas Schwab, 2007/11/03
- Re: m4_version_compare and new version numbering, Eric Blake, 2007/11/03
- Re: m4_version_compare and new version numbering, Jim Meyering, 2007/11/03
- Re: m4_version_compare and new version numbering, Ralf Wildenhues, 2007/11/03