bug-autoconf
[Top][All Lists]
Advanced

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

Re: m4_copy and m4_rename semantic changes


From: Ralf Wildenhues
Subject: Re: m4_copy and m4_rename semantic changes
Date: Mon, 8 Jun 2009 20:27:33 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi Eric,

* Eric Blake wrote on Mon, Jun 08, 2009 at 02:52:11PM CEST:
> According to Ralf Wildenhues on 5/30/2009 3:51 AM:
> > m4_copy and m4_rename changed their API before being published.
> > GCC already uses these macros from Autoconf 2.59, and expects
> > the old semantics.  I need to add some m4_undefine in order to
> > avoid autoconf failures.
> 
> Can you point to your gcc patch, so I can see exactly what semantic
> difference they were depending on?

Sure.  It's not posted or in the GCC tree yet (I am slowly getting
things together with the aim of dumping them to gcc-patches after
Autoconf 2.64 is out and when we've convinced GCC and src to adopt it).
If you want to see the patches now, or think I should start this process
earlier, would be fine with me, too.

The diff is rather mechanical and starts off like this:

diff --git a/boehm-gc/configure.ac b/boehm-gc/configure.ac
index 326a051..7742b13 100644
--- a/boehm-gc/configure.ac
+++ b/boehm-gc/configure.ac
@@ -49,6 +49,7 @@ m4_rename([_AC_ARG_VAR_PRECIOUS],[real_PRECIOUS])
 m4_define([_AC_ARG_VAR_PRECIOUS],[])
 AC_PROG_CC
 AC_PROG_CXX
+m4_undefine([_AC_ARG_VAR_PRECIOUS])
 m4_rename([real_PRECIOUS],[_AC_ARG_VAR_PRECIOUS])
 
 AM_PROG_CC_C_O
diff --git a/config/override.m4 b/config/override.m4
index 9bb1496..1f5b4ca 100644
--- a/config/override.m4
+++ b/config/override.m4
@@ -25,6 +25,7 @@ ifdef([m4_PACKAGE_VERSION],
 [dnl AC_DEFUN a commonly used macro so this file is picked up.
 m4_copy([AC_PREREQ], [_AC_PREREQ])
 AC_DEFUN([AC_PREREQ], [frob])
+m4_undefine([AC_PREREQ])
 m4_copy([_AC_PREREQ], [AC_PREREQ])
 

the first hunk repeats for several configure.ac files.
 
> > Just FYI.  Even with these previously undocumented macros, changes
> > might break software.  It might be a good idea to note the m4_copy
> > and m4_rename issue a bit more prominently in NEWS.
> 
> If I'm going to touch up the NEWS item to mention how code can be portably
> written to use either the older undocumented semantics or the new
> documented ones, then I'd like to know exactly what had to be done here.

Just m4_undefine the target macro before a m4_rename or m4_copy.

> > Also, GCC makes use of the undefined (and recently removed) macro
> > _AC_CHECK_HEADER_OLD.
> 
> I agree with Paolo's idea of adding an AU_DEFUN.  I'll see if I can get to
> that today.

For that I tested with merely

diff --git a/config/acx.m4 b/config/acx.m4
index cea08b7..494a7f2 100644
--- a/config/acx.m4
+++ b/config/acx.m4
@@ -350,10 +350,10 @@ fi
 # Eventually autoconf will default to checking headers with the compiler
 # instead, and we'll have to do this differently.
 
-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.

Cheers,
Ralf




reply via email to

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