[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Automake, Autoconf and POSIX shells (was: Re: GraphicsMagick Automake TA
Automake, Autoconf and POSIX shells (was: Re: GraphicsMagick Automake TAP)
Sun, 19 Aug 2012 20:03:46 +0200
[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)
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
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
> 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.
- Automake, Autoconf and POSIX shells (was: Re: GraphicsMagick Automake TAP),
Stefano Lattarini <=