Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

Zack Weinberg <[email protected]>
Newsgroups gmane.comp.sysutils.autoconf.bugs
Message-ID <CAKCAbMiVfmzRdr01TyUKSDFLmHukqksQna1hDhSm+JBU-hZe6Q@mail.gmail.com>
On Wed, Oct 21, 2020 at 10:25 PM Paul Eggert <[email protected]> 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], [[email protected]], [foo-AC_PACKAGE_VERSION])

and

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

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.

zw
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.