[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: m4_copy and m4_rename semantic changes

From: Eric Blake
Subject: Re: m4_copy and m4_rename semantic changes
Date: Mon, 8 Jun 2009 19:28:47 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

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_define([AC_CHECK_HEADER],m4_defn([_AC_CHECK_HEADER_OLD]))
> -ac_c_preproc_warn_flag=yes])# 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]