bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bu


From: Nick Bowler
Subject: Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?
Date: Thu, 22 Oct 2020 11:53:30 -0400

On 2020-10-22, Zack Weinberg <zackw@panix.com> wrote:
> On Wed, Oct 21, 2020 at 10:25 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>>
>> On 10/21/20 6:15 AM, Zack Weinberg wrote:
>> > We*could*  add a special case in AC_INIT where, if any of the third,
>> > fourth, or fifth arguments contain the literal strings
>> > `AC_PACKAGE_NAME` or `AC_PACKAGE_VERSION`, those are replaced with the
>> > values of the first and second argument, respectively.  This would
>> > keep the GHC code working as-is.  I'm not sure whether that's a good
>> > idea; cc:ing Paul and Eric for their thoughts.
>>
>> I'm not following all the details here
>
> The concrete problem is that, without the hack I described, we cannot
> support both
>
> AC_INIT([foo], [1.0], [foo-bug@foo.org], [foo-AC_PACKAGE_VERSION])
>
> and
>
> AC_INIT([bar], [1.0], [foo-bug@[192.0.2.1]])

I think this is missing the point.  The m4 way is that such an
email address should simply be double quoted to avoid the unwanted
m4 expansion, for example:

  AC_INIT([bar], [1.0], [[foo-bug@[192.0.2.1]]])

This works already, as expected, in existing versions of Autoconf.

But if your package actually used such an email address today, it will
be broken by the patch due to the overquotation in AC_INIT.  To avoid
regressions like the one reported, and to be consistent with how most
macros are expected to function, we should simply not overquote in
the definition of AC_INIT.

Cheers,
  Nick



reply via email to

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