Re: return values of test programs in *.m4 macros

[Eric Blake]

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 use a different return code (1, 2, 3, ...) at every
> possible failure point. This return code is then printed in the config.log.
> Example: m4/chown.m4.
> 
> Or even bit masks, as in m4/fcntl-o.m4.
> 
> I'd like to extend this style to all AC_RUN_IFELSE invocations in gnulib,
> so that
>   1) When gnulib is being ported to a new platform, we can understand
>      which of the portability flaws affect the platform, without running
>      test programs by hand, just by running ./configure and analyzing
>      config.log.

Well, if we exit on failure, we'd only know the first portability flaw,
and not any subsequent ones, but often that's a good enough start at
understanding the problem.  A bit-mask approach gives more information,
but may be a bit harder to code, and you are still limited to only 6
failures before you run afoul of $? limitations.

>   2) Sometimes parts of tests are unreliable (e.g. m4/utimes.m4 on NFS
>      mounted file systems). When someone reports a test failure, here too
>      it is convenient for us to be able to say "send us your config.log"
>      rather than having to execute test programs by hand.
> 
> Of course these return codes shall all be < 126.
> 
> Opinions? Objections?

I like the idea (in fact, the very reason why I started using different
return codes was so that reading config.log could tell me which failure
I encountered, which was sometimes enough to narrow in on whether my .m4
file was in error instead of the platform being buggy).

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature