autoconf-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] more cleanup before adding shell functions


From: Paolo Bonzini
Subject: Re: [PATCH] more cleanup before adding shell functions
Date: Thu, 09 Oct 2008 19:14:10 +0200
User-agent: Thunderbird 2.0.0.17 (Macintosh/20080914)

> Hmmm.  Since AS_SHELL_SANITIZE does not use $as_me,

Of course, otherwise it would not be set yet in the wrong diversion
after this patch. :-)

> maybe a better approach is 
> to make _AS_ECHO_LOG, AS_MESSAGE, _AS_LINENO_PREPARE, and AS_TMPDIR (ie. the 
> actual clients of $as_me) be the ones that AS_REQUIRE([_AS_ME_PREPARE]).

I was not sure whether as_me was considered part of the public m4sh
interface, though undocumented:

$ grep as_me bin/*
bin/autoconf.as:Try \`$as_me --help' for more information."
bin/autoconf.as:  AS_ECHO(["$as_me: option \`$[1]'\'' requires an
argument"]) >&2
bin/autoconf.as:       AS_ECHO(["$as_me: invalid option $[1]"])
bin/autoconf.as:        AS_ECHO(["$as_me: warning: both \`configure.ac'
and \`configure.in' are present."]) >&2
bin/autoconf.as:        AS_ECHO(["$as_me: warning: proceeding with
\`configure.ac'."]) >&2
bin/autoconf.as:      AS_ECHO(["$as_me: no input file"]) >&2
bin/autoconf.as:     AS_ECHO(["$as_me: invalid number of arguments."])
bin/autoconf.as:$verbose && AS_ECHO(["$as_me: running $AUTOM4TE $*"]) >&2

> in general, it seems like it should be possible to write an m4sh 
> input file that does not call AS_PREPARE, and instead uses AS_REQUIRE for 
> lazy 
> initialization of only the *_PREPARE features it uses, for a smaller/faster 
> output file.

Definitely.  Only whoever needs _AS_PREPARE would need AS_PREPARE, the
others should just expect AS_REQUIRE to work.

Also, the following renames should be done:

- AS_SHELL_SANITIZE => _AS_SHELL_SANITIZE

- _AS_SHELL_SANITIZE+_AS_PREPARE => AS_INIT_GENERATED or something like that

- furthermore, AS_INIT_GENERATED should assert that AS_PREPARE has been
called.

>> +m4_defun([_AS_ME_PREPARE],
>> +[AS_REQUIRE([_AS_BASENAME_PREPARE])dnl
>> +as_me=`AS_BASENAME("$[0]")`
> 
> Here's where a rewrite of AS_BASENAME might be useful to avoid forks. [...]
> Since AS_BASENAME is undocumented, and since it is most useful in variable 
> assignments, perhaps it is time to redefine it as follows (untested)
> 
> # AS_BASENAME(var, name, [ext])
> # -----------------------------
> # Compute the basename of NAME, with trailing EXT removed, and assign
> # the result to the shell variable VAR.
> m4_defun([AS_BASENAME],
> [AS_REQUIRE([_AS_BASENAME_PREPARE])dnl
> as_func_basename "$2"m4_ifval([$3], [ "$3"])
> $1=$as_func_basename_result
> ])
> 
> where as_func_basename is appropriately defined in _AS_BASENAME_PREPARE, and 
> includes any `` necessary for shells that lack XSI parameter expansion.

Yes.  (Except, do we want the third argument and the additional baggage
for expr/sed-based implementations?)

> In other words, change the semantics of AS_BASENAME to make assigning the 
> result to a variable part of the macro's job, at which point clients must no 
> longer use AS_BASENAME inside command substitution, and a fork or two is 
> avoided in decent shells.  Carrying on in the example, it would mean:
> 
> m4_defun([_AS_ME_PREPARE]
> [AS_BASENAME([as_me], ["$[0]"])
> ])

Agreed.  Yet another cleanup to do before introducing shell functions?
I'm passing the ball.  :-)

Paolo




reply via email to

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