* 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
