Re: [PATCH] use m4 -g when available

[Eric Blake]

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

> What about unsetting POSIXLY_CORRECT around the first test?  After all
> there are good chances that we can achieve the same effect later with
> -g, and the user can always unset POSIXLY_CORRECT later to fix the
> problem (so rejecting the M4 tout court would not be nice).
> 
> What about squashing in the attached?

Works for me; making the check for --gnu orthogonal to the path search 
certainly seems easier than my idea of trying to run m4 twice (once with, and 
once without -g) during the path search.

|    AC_CACHE_CHECK([for GNU M4 that supports accurate traces], [ac_cv_path_M4],
|      [rm -f conftest.m4f
| +had_posixly_correct=${POSIXLY_CORRECT:+yes}

s/had_posixly_correct/ac_&/ to be namespace clean, particularly since other 
projects, like bison, have already started borrowing our m4.m4 file, and since 
this particular macro is indeed owned by the Autoconf project.

| +  if test x$had_posixly_correct = xyes; then
| +    POSIXLY_CORRECT=:

I think we're safe in saying that POSIXLY_CORRECT merely has to exist without 
regards to its value; as far as I know, there aren't any GNU programs that 
would depend on us taking the effort to restore it back to the value it had 
before we temporarily unset it.  But if anyone knows a counter-example, then 
this line would need help.

| +    if test $ac_cv_prog_gnu_m4_gnu = no; then
| +      AC_MSG_WARN([The version of M4 that was found does not support -g.])
| +      AC_MSG_WARN([Using it with POSIXLY_CORRECT set may cause problems.])

This message could be a bit misleading.  The only versions of m4 where the 
absence of -g will make a difference are m4 1.6 and newer (or, put another way, 
the only versions of m4 which lack -g are 1.4.11 and older, but those versions 
didn't honor POSIXLY_CORRECT to begin with, but always exposed gnu 
extensions).  With m4 1.4.12 and 1.4.13, -g/--gnu exists, but is still a no-op, 
designed for future-proofing when it does matter for newer m4.  The real 
failure scenario is if the user configures autoconf with m4 1.4.11 or older, 
then upgrades to m4 1.6 without reconfiguring autoconf, and runs in an 
environment with POSIXLY_CORRECT.  Then again, since the warning is only output 
for users running with old m4 but POSIXLY_CORRECT set during configure, it is 
already a very narrow set of users that will see it in the first place.  Maybe 
this wording is nicer (although it's longer):

'The version of M4 that was found does not support -g, but POSIXLY_CORRECT is 
set.  A future upgrade to newer M4 without reconfiguring autoconf may cause 
problems.'

Your call if you feel like changing it.

One other thing - everywhere else in autom4te.in, we used m4's long options 
(that is, --gnu reads better than -g when inspecting the underlying m4 command 
displayed by 'autoconf --verbose').  And since we tested whether --help 
mentions --gnu, then we should set M4_GNU to --gnu, not -g.

So, I'm okay with committing with these nits addressed.

[As a side note, I know that the BSD folks ported autoconf 2.59 to allow the 
use of BSD m4 rather than requiring GNU m4, and that their port involved making 
autom4te call m4 with short options instead of long, because the BSD m4 already 
understands -g, but does not know long options.  But newer m4sugar already has 
enough other exploits specific to GNU m4 that trip up the current BSD m4 
implementation that the BSD folks would have to first spend time getting BSD m4 
into better shape before they can try to repeat their trick of teaching 
autoconf 2.64 to use short options and BSD m4.]

-- 
Eric Blake