* Ralf Corsepius wrote on Fri, Sep 16, 2005 at 12:39:13PM CEST:
> On Wed, 2005-09-14 at 13:52 -0500, Bob Friesenhahn wrote:
>
> > The drawback is that due to the use of relatively crude tools like sh,
> > sed, awk, and make, the GNU system is more complex, larger, and more
> > difficult to maintain. If the GNU system could rely on an evironment
> > like Python, Perl, or Ruby being pre-installed, then it could be much
> > smaller, faster, and easier to maintain.
> I never understood, why autoconf can't rely on a single shell (say bash
> or else) or adopt a (may-be stripped down) shell as part of autoconf
> (CONFIG_SHELL).
>
> It would make configure scripts much smaller and easier to use.
Well, merely allowing shell functions together with local variables
would allow for much smaller scripts. Moving over to this style in
a backward-compatible fashion seems to be possible if done carefully,
but is bound to be quite a bit of work. I don't know when Autoconf
will be able to rely on these (which exactly..?) shell features.
There is quite a bit of size to save; the next Libtool release alone
will cut some configure script sizes in half (if it doesn't use C++ or
Fortran, that is). If, in Autoconf 3(?), macros like
AC_CHECK_HEADERS([foo.h bar.h])
expand to
for ac_header in foo.h bar.h; do
func_ac_check_header "$LINENO" "$ac_header" "$default_action"
done
plus one constant-size function (similarly with other tests), script
size may end up much smaller. (Surely, if/when Libtool uses shell
functions in its configure test, C++/Fortran users will benefit as
well.)
Speaking of which, it may make sense to add to the shell function spy
(combined with the better-shell-function-finder) a probable method for
declaring (and testing functionality of) local variables..
Cheers,
Ralf
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
