[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: m4_copy and m4_rename semantic changes
From: |
Eric Blake |
Subject: |
Re: m4_copy and m4_rename semantic changes |
Date: |
Mon, 8 Jun 2009 19:40:06 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
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