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 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




reply via email to

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