Hello, I haven't fully reviewed this patch yet; there are more issues with it. However:
* Paolo Bonzini wrote on Sat, Nov 08, 2008 at 11:13:32AM CET: > > >> 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)? A bit long, no? > >> +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)? > > I'll leave this to Ralf to judge. for a working printf command? > >> +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_ECHO_PREPARE does the same... Here's a chance to fix both at once. :-) > > 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? > > The point of this patch series is that apparently Autoconf now thinks > printf is better than echo. IIUC then this line of thinking has not yet received exposure to the real world. As such, I am quite concerned that this patch will break some of the older systems. Esp., I'm quite sure that we need the cat here-document fallback; but it may not be necessary need to be with a restart. Sven Mascheck's pages contained a similar construct in a shell function (there was some complication, I think an eval, to prevent older shells from expanding variables too early or so); of course I can't find it there now in a casual search. :-/ Also, for Libtool it is pretty important to have a builtin $ECHO; this thing can be called thousands of times in link mode, unfortunately. Cheers, Ralf
