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: Eric Blake
Subject: Re: m4_copy and m4_rename semantic changes
Date: Thu, 11 Jun 2009 07:26:21 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Wildenhues on 6/8/2009 1:43 PM:
> * 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.)

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?

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

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoxBfwACgkQ84KuGfSFAYA/0wCfeRRnO9NElNatu+xjlxupplk4
bdYAn2sbiT/gUvdksiMHmQz+rLsA+O4a
=zYOv
-----END PGP SIGNATURE-----




reply via email to

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