Re: [PATCH 6/6] use printf as $ECHO

[Eric Blake]

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

> This patch bumps the requirement for *building* Libtool to
> Autoconf 2.62, which provides a handy $as_echo which does
> exactly the same as we need for Libtool.  However, Libtool
> itself uses its own echo replacement, so it is not tied to
> Autoconf 2.62.

Should we relax to 2.61a instead (as that is still available on alpha.gnu.org, 
and was the first release to actually have $as_echo)?  Not that it matters 
much, the set of people who bootstrap libtool is much smaller than the set of 
people who use libtool in building another package (and as most of them are on 
this list, and are probably already using autoconf 2.63 or even newer on at 
least a part-time basis...)

> * configure.ac: Bump Autoconf requirement.
> * libltdl/config/general.m4: Use $as_echo as default $ECHO.
> * tests/testsuite.at: Use $as_echo as default $ECHO.
> 
> * libltdl/m4/libtool.m4 (LT_INIT): Add _LT_SHELL_INIT to
> work around Autoconf <2.64 bug.
> (_LT_OUTPUT_LIBTOOL_COMMANDS_INIT): Create func_do_echo if
> needed.  Eliminate lt_ECHO requoting.
> (_LT_SHELL_INIT): Use a public M4sh diversion.
> (_LT_PROG_PRINTF_BACKSLASH): New.
> (_LT_PROG_ECHO_BACKSLASH): Rewrite.
> (LT_CMD_MAX_LEN): Do not use --fallback-echo.
> * libltdl/config/ltmain.m4sh: Create func_do_echo.  Remove
> fallback echo handling.
> (func_emit_wrapper_part1): Quote lt_cmd_ECHO, lt_func_ECHO,
> ECHO.  Remove fallback echo handling.
> (Execute mode): Do not set qecho.
> 
>  
> -AC_PREREQ(2.59)dnl We use AS_HELP_STRING
> +AC_PREREQ(2.62)dnl Some m4sh scripts use $as_echo
>  dnl Oldest automake required for bootstrap is below in AM_INIT_AUTOMAKE.

Should we enhance this comment to mention that the configure.ac for 
bootstrapping libtool is more stringent than the requirement for using libtool, 
just so casual readers aren't scared by this line?

> 
>  M4SH_VERBATIM([[

Hmm.  This is a nicer name for m4_echo, for how it is being used; maybe it is 
time to migrated it into the Autoconf manual (perhaps under the name 
AS_VERBATIM)?

>  : ${CP="cp -f"}
> -: ${ECHO="echo"}
> +: ${ECHO=$as_echo}

This is delving a bit into m4sh internals ($as_echo is undocumented, only 
AS_ECHO is public), but it seems a lot less painful to maintain than what this 
patch is replacing.  Maybe it's time to create/document AS_ECHO_PREPARE as the 
kosher way to get $as_echo?

> +
> +AC_MSG_CHECKING([for a working printf])

This looks a bit confusing in configure output; would it be better to 
state "printf(1)" rather than "printf" (since many people think of printf(3) 
first)?

> +if test "X`printf %s $ECHO`" = "X$ECHO"; then
> +  ECHO='printf %s\n'

Just for safety, shouldn't the test use '%s\n' rather than bare %s (in other 
words, make our test match our usage pattern)?

> +  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
> +  for as_dir in /bin$PATH_SEPARATOR/usr/bin$PATH_SEPARATOR$PATH

What a lot of duplicate code, all because _AS_PATH_WALK is undocumented.  Oh 
well; you did the right thing by not using an undocumented interface, even if 
it is bulky.

> +        for as_base in sh bash ksh zsh sh5; do
> +          as_shell=$as_dir/$as_base
> +          test -f "$as_shell" || test -f "$as_shell.exe" || continue

On the other hand, your copy-n-paste means that you are using a lot of m4sh 
variables; it would be a bit nicer to see these in the lt_ namespace rather 
than as_.

> +       lt_func_ECHO='func_do_echo () { '$as_shell' -c "$lt_cmd_ECHO" x "$[]
1";}'

This fallback forks for every echo.  Can't we rely on $as_echo (if it is 
builtin) rather than having to find an external program?

> +case "$ECHO" in
> +  printf*) AC_MSG_RESULT([shell builtin]) ;;
> +  */printf*) AC_MSG_RESULT([$as_dir/printf]) ;;

I guess we aren't worried about mingw \ directory separators?  On the other 
hand, any shell ported to mingw tends to have working print.

I may have missed something, but it seems like this patch now requires that the 
$ECHO solution be based on 'printf', even if a shell has a builtin 'echo' that 
fills the job.  Is it worth still checking whether 'echo' fits the bill, in 
case it can avoid the forks of lt_func_ECHO?

-- 
Eric Blake