GNU bug report logs -
#67516
[PATCH] aclocal: handle both # and dnl for serial number lines
Previous Next
Reported by: Karl Berry <karl <at> freefriends.org>
Date: Tue, 28 Nov 2023 21:08:02 UTC
Severity: normal
Tags: patch
Done: Karl Berry <karl <at> freefriends.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 67516 in the body.
You can then email your comments to 67516 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
automake-patches <at> gnu.org
:
bug#67516
; Package
automake-patches
.
(Tue, 28 Nov 2023 21:08:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Karl Berry <karl <at> freefriends.org>
:
New bug report received and forwarded. Copy sent to
automake-patches <at> gnu.org
.
(Tue, 28 Nov 2023 21:08:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Ross - you sent a change to automake-patches back in February 2017.
Sorry for the absurdly delayed reply.
https://lists.gnu.org/archive/html/automake-patches/2017-02/msg00001.html
Instead of only accepting comment lines that start with # for serial
lines, also accept dnl.
...
-my $serial_line_rx = '^#\s*serial\s+(\S*)';
+my $serial_line_rx = '^(?:#|dnl)\s*serial\s+(\S*)';
While there's no technical problem with the patch, I'm not sure
supporting dnl is desirable. It seems better for the serial line to
always end up in whatever file is generated, for the sake of debugging
and documentation, instead of being eliminated at m4-time. If there was
a specific case where it was better to eliminate it, please describe ...
Also, because it's been so many years and I don't think it's ever come
up as a request, clearly things go on in any case :).
(Thanks to Bogdan for unearthing this from the archives.) --best, karl.
Reply sent
to
Karl Berry <karl <at> freefriends.org>
:
You have taken responsibility.
(Tue, 28 Nov 2023 21:14:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Karl Berry <karl <at> freefriends.org>
:
bug acknowledged by developer.
(Tue, 28 Nov 2023 21:14:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 67516-done <at> debbugs.gnu.org (full text, mbox):
Information forwarded
to
automake-patches <at> gnu.org
:
bug#67516
; Package
automake-patches
.
(Tue, 28 Nov 2023 21:28:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 67516 <at> debbugs.gnu.org (full text, mbox):
On 2023-11-28 16:06, Karl Berry wrote:
> Hi Ross - you sent a change to automake-patches back in February 2017.
> Sorry for the absurdly delayed reply.
>
> https://lists.gnu.org/archive/html/automake-patches/2017-02/msg00001.html
>
> Instead of only accepting comment lines that start with # for serial
> lines, also accept dnl.
> ...
> -my $serial_line_rx = '^#\s*serial\s+(\S*)';
> +my $serial_line_rx = '^(?:#|dnl)\s*serial\s+(\S*)';
>
> While there's no technical problem with the patch, I'm not sure
> supporting dnl is desirable. It seems better for the serial line to
> always end up in whatever file is generated, for the sake of debugging
> and documentation, instead of being eliminated at m4-time. If there was
> a specific case where it was better to eliminate it, please describe ...
This shouldn't make any difference. In all "normal" uses of aclocal
everything in these files is going to be diverted to KILL anyway so
neither form should result in any output text going into configure.
And with respect to how aclocal imports macro files into a project
(either as separate files w/ --install, or directly into aclocal.m4),
it just copies files verbatim so it doesn't matter what syntax is used.
But by the same token there would seem to be no technical reason to
prefer dnl over #...
Cheers,
Nick
Information forwarded
to
automake-patches <at> gnu.org
:
bug#67516
; Package
automake-patches
.
(Fri, 01 Dec 2023 20:11:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 67516 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 28 Nov 2023 16:27, Nick Bowler wrote:
> On 2023-11-28 16:06, Karl Berry wrote:
> > Hi Ross - you sent a change to automake-patches back in February 2017.
> > Sorry for the absurdly delayed reply.
> >
> > https://lists.gnu.org/archive/html/automake-patches/2017-02/msg00001.html
> >
> > Instead of only accepting comment lines that start with # for serial
> > lines, also accept dnl.
> > ...
> > -my $serial_line_rx = '^#\s*serial\s+(\S*)';
> > +my $serial_line_rx = '^(?:#|dnl)\s*serial\s+(\S*)';
> >
> > While there's no technical problem with the patch, I'm not sure
> > supporting dnl is desirable. It seems better for the serial line to
> > always end up in whatever file is generated, for the sake of debugging
> > and documentation, instead of being eliminated at m4-time. If there was
> > a specific case where it was better to eliminate it, please describe ...
>
> This shouldn't make any difference. In all "normal" uses of aclocal
> everything in these files is going to be diverted to KILL anyway so
> neither form should result in any output text going into configure.
>
> And with respect to how aclocal imports macro files into a project
> (either as separate files w/ --install, or directly into aclocal.m4),
> it just copies files verbatim so it doesn't matter what syntax is used.
>
> But by the same token there would seem to be no technical reason to
> prefer dnl over #...
only angle of concern i can think of is that people are using dnl in their code
without realizing it's basically silently ignored. if we don't want to support
dnl, we should prob be chatty about it at some log level.
-mike
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
automake-patches <at> gnu.org
:
bug#67516
; Package
automake-patches
.
(Fri, 01 Dec 2023 23:11:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 67516 <at> debbugs.gnu.org (full text, mbox):
without realizing it's basically silently ignored. if we don't want
to support dnl, we should prob be chatty about it at some log level.
The "Serials" node in the manual only mentions "#". I guess I don't see
a need to go out of our way to do anything else, given that this was the
only report about it (and the OP's email now bounces). --thanks, karl.
Information forwarded
to
automake-patches <at> gnu.org
:
bug#67516
; Package
automake-patches
.
(Sat, 02 Dec 2023 01:01:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 67516 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 01 Dec 2023 16:10, Karl Berry wrote:
> without realizing it's basically silently ignored. if we don't want
> to support dnl, we should prob be chatty about it at some log level.
>
> The "Serials" node in the manual only mentions "#". I guess I don't see
> a need to go out of our way to do anything else, given that this was the
> only report about it (and the OP's email now bounces). --thanks, karl.
i tend to see it as "if one person took the time to track us down and
complain, then chances are there's more who didn't". which means some
people tried dnl, noticed, fought the system, then figured it out. imo
if the diagnostics are easy & cheap to add, then saving a few people a
bit of pain is nice, especially when it's a common practice we adopt,
and not just this one thing in isolation.
all that said, i'm not interested in writing the patch for this particular
issue, especially when manual serial management is uncommon, and i rarely
do it myself.
-mike
[signature.asc (application/pgp-signature, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 30 Dec 2023 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 173 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.