[Top][All Lists]
[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
Re: [PATCH] more cleanup before adding shell functions, Paul Eggert, 2008/10/09