Re: m4_copy and m4_rename semantic changes

[Ralf Wildenhues]

Hi Eric,

* Eric Blake wrote on Thu, Jun 11, 2009 at 03:26:21PM CEST:
> According to Ralf Wildenhues on 6/8/2009 1:43 PM:
> > * Eric Blake wrote on Mon, Jun 08, 2009 at 09:28:47PM CEST:
> >> 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.)
> 
> Good point.  So, back to my other question - would you rather manually
> undefine the pre-existing definitions at all usage points, or would you
> rather that I create a new m4sugar macro m4_rename_force in autoconf 2.64
> which performs the rename regardless of the defined-ness of the
> destination, at which point your gcc patch would be s/m4_rename/&_force/
> rather than adding a line of m4_undefine?

Well, I don't mind to have a m4_rename_force, but I would still add the
m4_undefine everywhere, in order to have consistent code that can also
be reused with older Autoconf (parts of the GCC tree are also used in
other projects such as libffi, without the override code in ../config,
and it is helpful not to have to force Autoconf version bump everywhere
at the same time).

> > 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.
> 
> I think there is room for both semantics (warn about overwriting, vs.
> blindly overwrite).  It is a bit unfortunate that m4_copy changed from the
> latter semantics when it was undefined to the former semantics as part of
> exposing it.  But other m4sugar semantics seem to favor warning on
> undefined (such as m4_defn, m4_undefine, ...), so it seems like the
> simpler name should be the warning version, hence my proposal of m4_rename
> vs. m4_rename_force.

Understood, thanks.

Cheers,
Ralf