[Adding the Automake and Autoconf list, as this might be of public interest] On 08/19/2012 05:48 PM, Bob Friesenhahn wrote: > Something I notice is that Automake's configure.ac contains an > elaborate testing of shells resulting in a AM_TEST_RUNNER_SHELL > definition which is used for the Bourne shell based test drivers. > No, $(AM_TEST_RUNNER_SHELL) is meant to be used only by the Automake's *own* test scripts. The Automake-provided test driver scripts and test harness recipes are expected to work also on Bourne shells, like (say) Solaris /bin/sh. Let me stress this: until Autoconf can ensure that the $CONFIG_SHELL it detects and sets is a proper POSIX shell (and I hope this will be done soon!), Automake will continue to assume just Bourne-shell features in its generated recipes and provided scripts. > Users of Automake-based test suites do not have access to this > functionality. > And they don't need it, not by default anyway. > It is not good that users of Automake-based tests don't have > access to the smarts necessary to run the test drivers without > copying large-chunks of GPL-licensed code into their program. > Again, this is a misunderstanding. The $(AM_TEST_RUNNER_SHELL) is not required to run the test drivers at all. In fact, if you peek in the Automake's own Makefile.in, you'll see that the scripts 'test-driver' and 'tap-driver.sh' are run simply by $(SHELL). > Under Solaris 10, I found that some fancy ksh-style syntax was > failing due to use of /bin/sh. > You mean in your test scripts, or in the Automake-provided driver scripts? The latter would be an Automake bug, while the former would be a user error: if you want to use POSIX features in your scripts, it's *your* responsibility to ensure they're run through a capable enough shell; Automake leaves the developer full freedom (and thus full burden) to decide which shell or interpreter (if any) must be used to run his tests. > Setting SH_LOG_COMPILER and TAP_LOG_COMPILER to $(SHELL) at least > seemed to pick up the shell selected by configure, which is better > than /bin/sh under Solaris 10. > This is the correct way to proceed IMHO. It's not 100% fool-proof, because Autoconf does not ensure that $SHELL will be set to a POSIX shell; still, I expect that could happen only on very old or very fringe systems. > For my test scripts, I have the option of either coding everything > to work with the weakest shell, or else hoping to find a better > shell on the system without the kind assistance of Automake. > Yes (I'd personally go with the second option BTW). And I believe this is not Automake's fault -- I believe it should be Autoconf to be enhanced to guarantee the presence of a decent shell (as, e.g., AC_PROG_AWK guarantees to find a proper awk, and Automake can then rely on that in its recipes). I recall that the Autoconf developers agreed with last time I brought this up, so everything should work out for the best in the end. Thanks, Stefano _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
