[Top][All Lists]

[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: Zack Weinberg
Subject: Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?
Date: Thu, 22 Oct 2020 09:26:03 -0400

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


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

I currently think supporting the latter is more important, based on
the not-at-all-scientific observation that one package was broken by
avoiding further expansion cycles when AC_PACKAGE_TARNAME is used, but
at least three packages were broken by extra expansion cycles
(compared to 2.69) eating punctuation in URLs.  I'm also, on net, not
a fan of the hack.


reply via email to

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