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

On 22/10/2020, Zack Weinberg <[email protected]> wrote:
> On Thu, Oct 22, 2020 at 11:53 AM Nick Bowler <[email protected]> wrote:
>> On 2020-10-22, Zack Weinberg <[email protected]> wrote:
>> > 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 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]]])
>
> I tried that and it doesn't work.  No amount of extra quotation (ok, I
> only went up to four levels before I gave up) will prevent the square
> brackets from being lost, if I don't have autoconf use m4_defn to set
> the value of the shell variable PACKAGE_BUGREPORT.

It works perfectly fine for me with Autoconf-2.69...

  % cat >configure.ac <<'EOF'
AC_INIT([bar], [1.0], [[foo-bug@[192.0.2.1]]])

AS_ECHO(["AC_PACKAGE_BUGREPORT"])
AS_ECHO(["$PACKAGE_BUGREPORT"])

AC_OUTPUT
EOF

  % autoconf-2.69
  % ./configure
  2.69
  foo-bug@[192.0.2.1]
  foo-bug@[192.0.2.1]
  configure: creating ./config.status

And it also works as expected with the zack/ac-init-quoting branch if I
simply revert the patch hunks identified earlier in this thread:

  % autoconf-zack-patched
  % ./configure
  2.69c.10-6487-dirty
  foo-bug@[192.0.2.1]
  foo-bug@[192.0.2.1]
  configure: creating ./config.status

If the hunks are not reverted, quotation problems are readily apparent:

  % autoconf-zack-unpatched
  2.69c.10-6487
  foo-bug@[192.0.2.1]
  [foo-bug@[192.0.2.1]]
  configure: creating ./config.status

(those patch hunks are not the only instances of overquotation added by the
patch, I see that the patch also overquotes the bugreport address in the
configure --help text)

Cheers,
  Nick