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 ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
