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

[John Darrington]

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/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.
       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?
     
     Bruno

Autoconf and some other projects use the return code 77 to indicate that a test 
neither passed nor failed, but could not be conducted.  Similarly aegis and 
projects using it regard 0 as "pass", 1 as "fail" and anything else as 
"indeterminate".
Anyone relying on this behaviour would get confused.

J'


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

signature.asc
Description: Digital signature