autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sed, pathnames, commas, ?(shell functions)


From: Paul Eggert
Subject: Re: sed, pathnames, commas, ?(shell functions)
Date: 26 Feb 2003 13:54:46 -0800
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3

Robert Anderson <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]