autoconf-patches
[Top][All Lists]
Advanced

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

Re: [PATCH 3/3] add and document AS_INIT_GENERATED


From: Eric Blake
Subject: Re: [PATCH 3/3] add and document AS_INIT_GENERATED
Date: Mon, 13 Oct 2008 15:28:06 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Paolo Bonzini <bonzini <at> gnu.org> writes:

> I see... maybe we should provide AS_STATE_PUSH and AS_STATE_POP macros
> that do all the required macro resetting, in case in the future other
> macros have to be renamed like that.

Sounds like an idea (but it can be a separate patch).

> Now, suppose that there is a shell on the system that supports {Z} and
> one that supports {Y}, but not one that includes {Y,Z}.  Since the child
> does not run AS_CLEANUP, it does not have the loop to choose a better
> shell; so the child must use the second of the two available shells.
> But if you do not do that m4_require here, the parent will provide {Z}
> instead.

Thanks for the clarification.  And this also explains why the child script must 
be generated with #!$SHELL, rather than #!/bin/sh - we are reusing the 
knowledge learned during the parent script on which shell provided all the 
required features (both an optimization that makes the child faster, and a 
technical necessity since we don't have a counterpart M4SH-SANITIZE diversion 
for dumping AS_CLEANUP into the child script).

> 
> This is not likely, but neither is it only hypothetical: just replace Z
> with $LINENO and Y with shell functions.

Which shells lack shell functions?  Every shell I've tried appears to have them 
(this includes Solaris /bin/sh and cygwin ash, which both lack LINENO).  But 
your argument is still sound - cygwin ash lacks $(()), while Solaris /bin/sh 
lacks ${foo#*/}, and both of those are features I hope to start adding in 
_AS_DETECT_SUGGESTED to optimize configure scripts on shells that support them.

> 
> I tested the attached patch with "make pdf" too and checked that there
> are no overfull hboxes.

Always a nice check to run on doc changes.  Thanks!

> +Note that @code{AS_INIT_GENERATED} does not emit the entire prolog,
> +including the @code{#! /bin/sh} line.  Currently, the suggested idiom
> +for writing a M4sh shell script within another script is:

I would write the paragraph like this (I think it is important to warn the user 
to _not_ blindly use /bin/sh in the child script):

Note that @code{AS_INIT_GENERATED} does not emit the entire prolog.  In 
particular, the child script must be previously started with @code{#!$SHELL}, 
rather than @code{#!/bin/sh}, because this macro intentionally skips the search 
for a sufficient shell that was performed in the parent script.  Currently, the 
suggested idiom for writing a M4sh shell script within another script is:

> +
> +This, however, may change in the future until the M4sh interface is
> +stabilized further.

s/until/as/

OK to apply with these changes.

-- 
Eric Blake






reply via email to

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