[Top][All Lists]
[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 21:43:52 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
* Eric Blake wrote on Mon, Jun 08, 2009 at 09:28:47PM CEST:
> Ralf Wildenhues writes:
> >
> > 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?
Because I want the straight non-workaround code to be the one for the
newest autoconf version. (And I hate to find out failure to use aclocal
-I ../config from errors other than the one intended to detect that
condition.)
> 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]))
If you start arguing for this, then I'd argue the API change of
m4_rename in Autoconf proper is a step backwards and should be undone:
If the Autoconf API is not usable without hacks, then it is not as good
as it could be.
> 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.
Yes.
Cheers,
Ralf