Hi Eric, Ralf,
I've now pushed the big patch, with some explanations in m4/README (attached
below).
Ralf Wildenhues wrote:
> Well, I think what Eric was hinting at was that, for example, some tests
> in Autoconf's and Automake's own test suites interpret an exit status of
> 77 from a configure ex
Hello,
* Bruno Haible wrote on Sun, Dec 05, 2010 at 02:12:49AM CET:
> > If the particular
> > combination of failures matches 63, 77, or 99 (as commonly used by
> > automake and autoconf to mean version mismatch, skip, or hard fail),
> > then the configure script might misbehave.
>
> In the gener
Hi Eric,
> If the particular
> combination of failures matches 63, 77, or 99 (as commonly used by
> automake and autoconf to mean version mismatch, skip, or hard fail),
> then the configure script might misbehave.
In the generated configure scripts, AC_RUN_IFELSE tests for an exit
code equal to 0
On 12/04/2010 11:44 AM, Bruno Haible wrote:
> Eric, Paul, Jim,
>
>> That sort of thing (possibly with bit masks, as you mention)
>> sounds like a win to me.
>
> Thanks for your support.
>
> Eric Blake wrote:
>> A bit-mask approach gives more information,
>> but may be a bit harder to code, and y
John Darrington wrote:
> I'd like to extend this style to all AC_RUN_IFELSE invocations in gnulib,
> ...
> Autoconf and some other projects use the return code 77 to indicate that a
> test
> neither passed nor failed, but could not be conducted.
I'm talking about programs run through A
On Tue, Nov 30, 2010 at 04:07:27AM +0100, Bruno Haible wrote:
Hi,
For a long time, we've written our test programs in *.m4 macros in such a
way
that when they fail, the return code is 1.
But often we have several tests, combined in a single program.
Example: m4
Bruno Haible wrote:
> Hi,
>
> For a long time, we've written our test programs in *.m4 macros in such a way
> that when they fail, the return code is 1.
>
> But often we have several tests, combined in a single program.
> Example: m4/utimes.m4.
>
> Eric's new style is to use a different return cod
On 11/29/2010 08:07 PM, Bruno Haible wrote:
> Hi,
>
> For a long time, we've written our test programs in *.m4 macros in such a way
> that when they fail, the return code is 1.
>
> But often we have several tests, combined in a single program.
> Example: m4/utimes.m4.
>
> Eric's new style is to
Hi,
For a long time, we've written our test programs in *.m4 macros in such a way
that when they fail, the return code is 1.
But often we have several tests, combined in a single program.
Example: m4/utimes.m4.
Eric's new style is to use a different return code (1, 2, 3, ...) at every
possible f
