Automake, Autoconf and POSIX shells (was: Re: GraphicsMagick Automake TAP)

[Stefano Lattarini]

[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