autoconf-patches
[Top][All Lists]
Advanced

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

Re: [PATCH 5/5] use shell function for AS_BASENAME, AS_DIRNAME, AS_MKDIR


From: Eric Blake
Subject: Re: [PATCH 5/5] use shell function for AS_BASENAME, AS_DIRNAME, AS_MKDIR_P
Date: Thu, 09 Oct 2008 06:55:24 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Paolo Bonzini on 9/18/2008 8:15 AM:
> This patch defines shell functions for the various implementation
> of basename/dirname/mkdir_p and changes macros such as AS_BASENAME
> to simply dispatch to those macros.

In general, I like where this is headed, but I'm not quite ready to apply
this as-is.

> 
> Some care is needed to delay the definition of as_me, and to define
> the shell functions in _AS_PREPARE for config.status.  There's also
> a bug that _AS_LINENO_PREPARE was not using m4_defun.

Can some of this cleanup be separated out and applied first, so that the
actual patch adding shell functions is not doing other things at the same
time?

> 
> I decided to stop having AS_PREPARE call _AS_PREPARE, because the
> former can let _AS_BASENAME_PREPARE and friends expand shell functions,
> while _AS_PREPARE (which is used for the prolog of config.status)
> must do that on its own.

For that matter, why should anyone except status.m4 be using AS_PREPARE?
The point of AS_REQUIRE is that the initialization will be emitted on an
as-needed basis (ie. if you write an m4sh script that doesn't use as_ln_s,
then why should the script be slowed down by emitting _AS_LN_S_PREPARE at
all?).  config.status is special because it is a script written by a
script, and not a script written in m4sh, so we have to do all of the
initializations rather than relying on lazy initialzation.

> 
>       (AS_BASENAME): Just dispatch to $as_basename.
>       (_AS_BASENAME_EXPR): Do not require _AS_EXPR_PREPARE.
>       (_AS_BASENAME_PREPARE): Do that here.  Test availability of
>       basename and expr.  Define shell functions.

Here, does it really make sense to define two functions, one of which will
never be used?  Or would it be better to write a conditional function
definition:

if (basename -- /) >/dev/null 2>&1 && test "X`basename -- / 2>&1`" = "X/";
then
  as_func_basename ()
  {
    basename "$@"
  }
elif (as_func_basename_expr -- /) >/dev/null 2>&1; then
  as_func_basename ()
  {
    _AS_DIRNAME_EXPR([$[]2])
  }

and so forth.  For that matter, I would like to use XSI parameter
expansion, when available, to avoid forking (even using basename is slower
than doing things like ${2##.*/}, libtool has some examples of this).

On the other hand, your patch is an improvement in its own right, and
maybe changes like this can be follow-up patches.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjt/zwACgkQ84KuGfSFAYAswgCfVwjQrh+HwUvs5wamL7xfvmPM
JNoAnAghOzv00bbMMsECkjRB+mk7+ngx
=qS4G
-----END PGP SIGNATURE-----




reply via email to

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