Re: m4_copy and m4_rename semantic changes

[Eric Blake]

Eric Blake <ebb9 <at> byu.net> writes:

> 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?  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]))

On second thought, changing just m4_rename up front does a disservice to users 
copying code from gcc - what works in gcc will fail elsewhere if they don't 
also copy the m4_rename override.  Maybe a better approach would be to add a 
new m4sugar macro:

# m4_rename_force(old, new)
# -------------------------
# Like m4_rename, except don't fail when overwriting a previously defined
# macro value of NEW.

(and likewise for m4_copy_force)

Then, instead of adding m4_undefine prior to lots of m4_rename uses, you would 
instead use the new name, to make the intent obvious.

But that means touching just as many gcc files either way, so maybe adding the 
explicit m4_undefine is best, after all.  I won't add m4_rename_force to 
m4sugar unless you want to go in that direction.

-- 
Eric Blake