$as_me [was: [PATCH] more cleanup before adding shell functions]

[Eric Blake]

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

[ok, time to split this mail into multiple topics]

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

Our general policy has been that if it is undocumented, it isn't supposed to be 
used outside of autoconf.  But we are also sensitive to the fact that 
documentation is incomplete, people use stuff without asking, and we don't like 
to introduce gratuitous regressions, if they are identified in time.

Can anyone find an actual m4sh client that does not use AS_PREPARE but which 
does use $as_me?

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

This doesn't count against us, since it is from the autoconf package - we 
simply add AS_REQUIRE([_AS_ME_PREPARE]) to autoconf.as, and problem solved.

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> Libtool uses it, too.  I think it's a really old interface, and even if
> undocumented, should be assumed to be used.  I don't think it is
> possible to drop it in real-world configure scripts, and it won't speed
> up real-world examples either.

Nope, that doesn't count either:

$ git grep as_me
libltdl/m4/libtool.m4:# Generated by $as_me.
libltdl/m4/libtool.m4:  AS_BOX([Running $as_me.])
libltdl/m4/libtool.m4:\`$as_me' creates a local libtool stub from the current 
configuration,
libltdl/m4/libtool.m4:# Generated automatically by $as_me ($PACKAGE$TIMESTAMP) 
$VERSION
libltdl/m4/libtool.m4:   (eval echo "\"\$as_me:__oline__: $lt_compile\"" 
>&AS_MESSAGE_LOG_FD)
libltdl/m4/libtool.m4:   echo "$as_me:__oline__: \$? = $ac_status" 
>&AS_MESSAGE_LOG_FD
libltdl/m4/libtool.m4:   (eval echo "\"\$as_me:__oline__: $lt_compile\"" 
>&AS_MESSAGE_LOG_FD)
libltdl/m4/libtool.m4:   echo "$as_me:__oline__: \$? = $ac_status" 
>&AS_MESSAGE_LOG_FD
libltdl/m4/libtool.m4:  (eval echo "\"\$as_me:__oline__: $ac_compile\"" 
>&AS_MESSAGE_LOG_FD)
libltdl/m4/libtool.m4:  (eval echo "\"\$as_me:__oline__: $NM 
\\\"conftest.$ac_objext\\\"\"" >&AS_MESSAGE_LOG_FD)
libltdl/m4/libtool.m4:  (eval echo "\"\$as_me:__oline__: output\"" 
>&AS_MESSAGE_LOG_FD)

Still doesn't count.  This is just usage in the regular .m4 files which are 
included by configure.ac; nothing in ltmain.m4sh.  So these uses of $as_me are 
either encountered during configure (which already does AS_PREPARE because it 
cannot predict what its clients will need and so must provide it all), or 
during config.status or the generated libtool script (both of which use 
_AS_PREPARE, because we no longer have m4sh lazy initialization).

> 
> I think a recent report on bug-gnulib shows that even gnulib-tool would
> need as_me, really.

Well, gnulib-tool doesn't yet use m4sh, but yes, if we were to rewrite it to do 
so, then $as_me would take the place of $progname.  But this doesn't count 
either - anything not yet written in m4sh can be written with forward 
compatibility in mind (or else use the AS_PREPARE sledgehammer):

m4_ifdef([_AS_ME_PREPARE], [AS_REQUIRE([_AS_ME_PREPARE])])

What I'm worried about is whether any existing m4sh clients use $as_me, to the 
point where my patch would break them.  I also agree that this patch won't 
speed up most real-world examples, since AS_ERROR pulls in $as_me support, and 
few scripts would likely ever be written without AS_ERROR.

-- 
Eric Blake