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

[Paolo Bonzini]

>> 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?

Yes, I'll look at separating some of the changes.

>> 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?

AS_PREPARE is used in the prolog of the configure script; _AS_PREPARE is
used in the prolog of config.status.

The problem is that we want the configure script's initialization to be
emitted in the right diversion, and that's why we cannot just use
_AS_PREPARE.

Or are you saying that AS_PREPARE is totally useless?  I'm not sure we
would not miss anything in the prolog of the configure script if
AS_PREPARE was not used.

>>      (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?

Can I leave the final patch to do this to you after I do the above
splitting?

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

No big deal, as long as it's not me the one who takes care of squashing
the follow-ups with this patch.

Paolo