Robert Anderson <[EMAIL PROTECTED]> writes:
> It seems to me either autoconf depends on shell functions or it
> doesn't. Requiring developers to know which features are shell
> function dependent and which aren't seems like needless complexity.
The complexity would be needless if there were no
backward-compatibility concerns. But I was concerned that some
developers may want to use new Autoconf versions to generate shell
scripts that run on ancient platforms. For those developers, ideally
I wanted to be able to say "if you stick to the features advertised by
Autoconf 2.57, your scripts will not rely on shell functions".
On thinking about it more, though, I agree with you. It's not worth
the hassle.
However, before embarking on using shell functions in mainline code,
we really should modify AS_PREPARE so that "configure" searches for a
shell that supports shell functions if possible. This will make it
more likely that "configure" will succeed on older platforms.
This will be a bit tricky, since it's an extra constraint on the
shell. AS_PREPARE already enforces one constraint (see
_AS_LINENO_PREPARE) that is not a hard one ("configure" falls back on
using sed+sh if sh doesn't support line numbers), but the
shell-function constraint doesn't really have a fallback, so the code
will be a bit different. I guess you can fold this stuff into
_AS_LINENO_PREPARE, and change its name to _AS_POSIX_SHELL_PREPARE or
something like that.
(The hardest part about doing this may be finding an implementation
that doesn't support shell functions, to test with. :-)
> It occurs to me that this could also be solved by generating a small
> standalone script using the tmpdir mechanism, to replace the shell
> function. Would that solution be preferable?
We considered this approach, and I even championed it for a while.
However, I now feel that it will cause its own set of portability
problems, and it's probably not worth the hassle given that shell
functions are a superior solution and are the intended long-term
direction.
