Re: m4_copy and m4_rename semantic changes

[Eric Blake]

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

> > Can you point to your gcc patch, so I can see exactly what semantic
> > difference they were depending on?
> 
> If you want to see the patches now, or think I should start this process
> earlier, would be fine with me, too.

Up to you if you want to start making this public; it might be useful for other 
projects out there to see what we've done, as well as let the autoconf list 
document known formulas for making configur.ac files compatible across a broad 
spectrum of autoconf releases.

> 
> The diff is rather mechanical and starts off like this:
> 
> +m4_undefine([_AC_ARG_VAR_PRECIOUS])
>  m4_rename([real_PRECIOUS],[_AC_ARG_VAR_PRECIOUS])

Why not go for a simpler change - redefine m4_rename up front to deal with pre-
existing targets, rather than touching every use of m4_rename?  I think this 
(untested) snippet should do the trick:

# m4_rename(old, new)
# -------------------
# Autoconf 2.64 learned to warn the user about overwriting an existing
# macro via m4_rename, but gcc knowingly uses this idiom.  This wrapper
# silences the failure.
m4_pushdef([m4_rename],
[m4_ifdef([$2],[m4_undefine([$2])])]m4_defn([m4_rename]))

> 
> -AC_DEFUN([AC_PROG_CPP_WERROR],
> -[AC_REQUIRE([AC_PROG_CPP])dnl
> -m4_define([AC_CHECK_HEADER],m4_defn([_AC_CHECK_HEADER_OLD]))
> -ac_c_preproc_warn_flag=yes])# AC_PROG_CPP_WERROR
> +dnl AC_DEFUN([AC_PROG_CPP_WERROR],
> +dnl [AC_REQUIRE([AC_PROG_CPP])dnl
> +dnl m4_define([AC_CHECK_HEADER],m4_defn([_AC_CHECK_HEADER_PREPROC]))
> +dnl ac_c_preproc_warn_flag=yes])# AC_PROG_CPP_WERROR
> 
> which will just use Autoconf's AC_PROG_CPP_WERROR; but still have to
> evaluate the impact.

Even though your proposed gcc change means no longer using the undocumented 
_AC_CHECK_HEADER_OLD, an AU_DEFUN in autoconf would help for other uses of this 
macro in the wild.

-- 
Eric Blake