GNU logs - #31728, boring messages

Message sent to bug-automake@HIDDEN:

Subject: bug#31728: Automake and AM_WITH_DMALLOC; endorsing proprietary software?
Resent-From: Nick Bowler <nbowler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-automake@HIDDEN
Resent-Date: Tue, 05 Jun 2018 19:10:01 +0000
Resent-Message-ID: <handler.31728.B.152822578813298 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 31728 <at> debbugs.gnu.org
MIME-Version: 1.0
From: Nick Bowler <nbowler@HIDDEN>
Date: Tue, 5 Jun 2018 15:09:29 -0400
Message-ID: <CADyTPEzig02npgBd-9LVUmAUQUSfn1Y-57gzzKECykoKvOyrPg@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi,

I have some doubts about the automake-provided macro AM_WITH_DMALLOC.
This appears to be a development tool which could be useful to help
programmers debug their packages.  It has a very brief description
in the Automake manual in section 6.4.1 "Public Macros"[1], including
a link to the dmalloc website.

The trouble is that dmalloc appears to be non-free: the license does
not seem to permit distribution for a fee (see below).  This macro in
Automake doesn't seem to exist for any real portability purpose, but
rather it only adds options that help extend program functionality
with this library.

Perhaps I am mistaken, but I wonder if this macro has a place in a
GNU package like Automake.  The manual entry may encourage developers
to use this macro/library.  For an example of this, GNU make 4.2.1
did make use of the AM_WITH_DMALLOC macro, so in turn that package's
configure --help output suggests this tool for debugging.

The license text found in the latest dmalloc 5.5.2 release is this:

  Copyright 2000 by Gray Watson

  Permission to use, copy, modify, and distribute this software for
  any purpose and without fee is hereby granted, provided that the
  above copyright notice and this permission notice appear in all
  copies, and that the name of Gray Watson not be used in advertising
  or publicity pertaining to distribution of the document or software
  without specific, written prior permission.

  Gray Watson makes no representations about the suitability of the
  software described herein for any purpose.  It is provided "as is"
  without express or implied warranty.

The permission grant is almost identical to the ISC license except that
"and/or" is changed to "and" and, more importantly, the words "with or
without fee" are changed to "and without fee".

[1] https://www.gnu.org/software/automake/manual/automake.html#index-AM_005fWITH_005fDMALLOC

Thoughts?

Cheers,
  Nick

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Nick Bowler <nbowler@HIDDEN>
Subject: bug#31728: Acknowledgement (Automake and AM_WITH_DMALLOC;
 endorsing proprietary software?)
Message-ID: <handler.31728.B.152822578813298.ack <at> debbugs.gnu.org>
References: <CADyTPEzig02npgBd-9LVUmAUQUSfn1Y-57gzzKECykoKvOyrPg@HIDDEN>
X-Gnu-PR-Message: ack 31728
X-Gnu-PR-Package: automake
Reply-To: 31728 <at> debbugs.gnu.org
Date: Tue, 05 Jun 2018 19:10:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-automake@HIDDEN

If you wish to submit further information on this problem, please
send it to 31728 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
31728: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D31728
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-automake@HIDDEN:

Subject: bug#31728: Automake and AM_WITH_DMALLOC; endorsing proprietary software?
Resent-From: Mike Frysinger <vapier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-automake@HIDDEN
Resent-Date: Fri, 10 Dec 2021 07:30:02 +0000
Resent-Message-ID: <handler.31728.B31728.163912137030598 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Nick Bowler <nbowler@HIDDEN>
Cc: 31728 <at> debbugs.gnu.org
Date: Fri, 10 Dec 2021 02:29:29 -0500
From: Mike Frysinger <vapier@HIDDEN>
Message-ID: <YbMB2YT0Od112Kga@vapier>
Mail-Followup-To: Nick Bowler <nbowler@HIDDEN>, 31728 <at> debbugs.gnu.org
References: <CADyTPEzig02npgBd-9LVUmAUQUSfn1Y-57gzzKECykoKvOyrPg@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CADyTPEzig02npgBd-9LVUmAUQUSfn1Y-57gzzKECykoKvOyrPg@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

confirm 31728
severity 31728 wishlist

On 05 Jun 2018 15:09, Nick Bowler wrote:
> The trouble is that dmalloc appears to be non-free: the license does
> not seem to permit distribution for a fee (see below).

first this part.  ianal, so i won't try to interpret the nuance here,
but it seems a bit mooted with the latest dmalloc which explicitly
switches to the ISC license and the OSI recognizes that as open source.

that said ...

> I have some doubts about the automake-provided macro AM_WITH_DMALLOC.
> This appears to be a development tool which could be useful to help
> programmers debug their packages.  It has a very brief description
> in the Automake manual in section 6.4.1 "Public Macros"[1], including
> a link to the dmalloc website.
> 
> This macro in
> Automake doesn't seem to exist for any real portability purpose, but
> rather it only adds options that help extend program functionality
> with this library.
> 
> Perhaps I am mistaken, but I wonder if this macro has a place in a
> GNU package like Automake.  The manual entry may encourage developers
> to use this macro/library.  For an example of this, GNU make 4.2.1
> did make use of the AM_WITH_DMALLOC macro, so in turn that package's
> configure --help output suggests this tool for debugging.

i tend to agree with this sentiment that the macro doesn't really fit
with automake's mission.  and more importantly, i think the ecosystem
has grown significantly since the macro was first added back in 1996.
we are not hurting for memory checking tools nowadays, both from ones
based in compile-time instrumentation (e.g. the various GNU sanitizers),
to ones that work at runtime only (e.g. valgrind and GNU C library's
various M_* env vars).  i don't think we can add value by adding macros
for each tech stack, and the number of users of dmalloc i think has
fallen off a cliff.

so imo we should deprecate this macro (i guess in the 1.17 release) and
then drop it entirely (i guess in the 1.18+ release).
-mike

Message sent to bug-automake@HIDDEN:

Subject: bug#31728: Automake and AM_WITH_DMALLOC; endorsing proprietary software?
References: <CADyTPEzig02npgBd-9LVUmAUQUSfn1Y-57gzzKECykoKvOyrPg@HIDDEN>
Resent-From: Karl Berry <karl@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-automake@HIDDEN
Resent-Date: Sat, 11 Dec 2021 22:43:01 +0000
Resent-Message-ID: <handler.31728.B31728.163926257416358 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: vapier@HIDDEN
Cc: nbowler@HIDDEN, 31728 <at> debbugs.gnu.org
Date: Sat, 11 Dec 2021 15:42:48 -0700
Message-Id: <202112112242.1BBMgmDQ022847@HIDDEN>
From: Karl Berry <karl@HIDDEN>
In-Reply-To: <YbMB2YT0Od112Kga@vapier>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Mike,

    i tend to agree with this sentiment that the macro doesn't really fit
    with automake's mission.  and more importantly, i think the ecosystem
    has grown significantly since the macro was first added back in 1996.

I also agree, but I still wouldn't want to delete the macro and thus
gratuitously break people's working automake setups.  People might well
have AM_WITH_DMALLOC left over from when they were debugging 20 years
ago.  There is no reason to make them spend time thinking about it now,
IMHO -- even if all they have to do is remove it, that's too much to ask
for no actual gain.

Instead, let's update the doc to recognize the situation.
Can you draft something, mentioning the other tools, along the lines of
what you wrote in this email?

If anyone ever comes along with a need for dmalloc or to update the
macro (unlikely), we could go further then.

If dmalloc were (still) nonfree, it would be a different story.

Thanks,
Karl

Message sent to bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31728: Automake and AM_WITH_DMALLOC; endorsing proprietary software?
Resent-From: Mike Frysinger <vapier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-automake@HIDDEN
Resent-Date: Sun, 12 Dec 2021 03:38:01 +0000
Resent-Message-ID: <handler.31728.B31728.163928023710923 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31728
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: 
To: Karl Berry <karl@HIDDEN>
Cc: nbowler@HIDDEN, 31728 <at> debbugs.gnu.org
Received: via spool by 31728-submit <at> debbugs.gnu.org id=B31728.163928023710923
          (code B ref 31728); Sun, 12 Dec 2021 03:38:01 +0000
Received: (at 31728) by debbugs.gnu.org; 12 Dec 2021 03:37:17 +0000
Received: from localhost ([127.0.0.1]:50400 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mwFfp-0002q7-8S
	for submit <at> debbugs.gnu.org; Sat, 11 Dec 2021 22:37:17 -0500
Received: from woodpecker.gentoo.org ([140.211.166.183]:47796
 helo=smtp.gentoo.org) by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <vapier@HIDDEN>) id 1mwFfn-0002pt-KK
 for 31728 <at> debbugs.gnu.org; Sat, 11 Dec 2021 22:37:16 -0500
Received: by smtp.gentoo.org (Postfix, from userid 559)
 id 4060134337A; Sun, 12 Dec 2021 03:37:09 +0000 (UTC)
Date: Sat, 11 Dec 2021 22:37:16 -0500
From: Mike Frysinger <vapier@HIDDEN>
Message-ID: <YbVubEm0pO32qNc2@vapier>
Mail-Followup-To: Karl Berry <karl@HIDDEN>, nbowler@HIDDEN,
 31728 <at> debbugs.gnu.org
References: <YbMB2YT0Od112Kga@vapier>
 <202112112242.1BBMgmDQ022847@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="KKw155TjErmjmkIl"
Content-Disposition: inline
In-Reply-To: <202112112242.1BBMgmDQ022847@HIDDEN>
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)


--KKw155TjErmjmkIl
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 11 Dec 2021 15:42, Karl Berry wrote:
>     i tend to agree with this sentiment that the macro doesn't really fit
>     with automake's mission.  and more importantly, i think the ecosystem
>     has grown significantly since the macro was first added back in 1996.
>=20
> I also agree, but I still wouldn't want to delete the macro and thus
> gratuitously break people's working automake setups.  People might well
> have AM_WITH_DMALLOC left over from when they were debugging 20 years
> ago.  There is no reason to make them spend time thinking about it now,
> IMHO -- even if all they have to do is remove it, that's too much to ask
> for no actual gain.
>=20
> Instead, let's update the doc to recognize the situation.
> Can you draft something, mentioning the other tools, along the lines of
> what you wrote in this email?
>=20
> If anyone ever comes along with a need for dmalloc or to update the
> macro (unlikely), we could go further then.

i think we can still mark it obsolete even if we don't plan on deleting it
for a while.  that should at least prevent new users from showing up, and
slowly encourage people to remove existing usage.
-mike

--KKw155TjErmjmkIl
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmG1bmwACgkQQWM7n+g3
9YE2wA/+I6jCHnjp3vVw9kLt0KJ92m5TPjv/6KUQ0ifD2I2uUHCvMUsQZUCNnxQq
73xfS83NKN/mJ/hM0y5FnEHMsLMhqpEoJn2hDH7zCWDHlLLCWzjUHN836xzNGeRE
spgkYMudpa/aIeQy30QJ3qas6rdcjWWEKctIsIp+Ne5k6TKJM9lzTPe7q4pRumwN
K3ev3qOW8VjoH1yQii2L+ZjwkpLHzUoxIdN/040qSbnB8f62Z6ReJ4ML5xAblVE+
SSamQVuY3lt2FH33Xct7nu+0aIL1MMclQbh/2+ejkBpxPHYIk3aYu8Ue/9x2fIMg
fGP1P6cSV+mIHQv1hzkLi9brQOZ2gXA8sr1YAAiiEMeVPxdwipuCNu7+e0g1IB6c
oFCgMkUXSQWT438Znz3Yq5OpI9BxsWk3VNHa0weQ5DJIJxtOktXkl6PoaVPanctx
x5UBC1Xw80kNGtnzw/1Ta3BC/AcVI25RX0Pb/EIj7OTRHqXGADR2HF/ZSySE6muS
FlsE8zZpY8uucKRp0dRV5R4EY9dQ4d0PCbo6rxVdvFuqfygxJMMnuvGsielxaKNf
MWJyeE05yBrdVsC+MJW5IR6a2FAtS4Xon0LydvGUT1G/f207NjKaqz7WjG3rKMS8
WV6Km4ajiTtT5zWJVOzZ+sxdWqX7x68ASd8S6u6gZ1wdMIF1080=
=oHyV
-----END PGP SIGNATURE-----

--KKw155TjErmjmkIl--

Message sent to bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31728: [PATCH] dmalloc: mark macro as obsolete
References: <CADyTPEzig02npgBd-9LVUmAUQUSfn1Y-57gzzKECykoKvOyrPg@HIDDEN>
In-Reply-To: <CADyTPEzig02npgBd-9LVUmAUQUSfn1Y-57gzzKECykoKvOyrPg@HIDDEN>
Resent-From: Mike Frysinger <vapier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-automake@HIDDEN
Resent-Date: Tue, 18 Jan 2022 06:24:02 +0000
Resent-Message-ID: <handler.31728.B31728.16424870257854 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31728
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: 
To: 31728 <at> debbugs.gnu.org
Received: via spool by 31728-submit <at> debbugs.gnu.org id=B31728.16424870257854
          (code B ref 31728); Tue, 18 Jan 2022 06:24:02 +0000
Received: (at 31728) by debbugs.gnu.org; 18 Jan 2022 06:23:45 +0000
Received: from localhost ([127.0.0.1]:48632 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n9huC-00022a-Jk
	for submit <at> debbugs.gnu.org; Tue, 18 Jan 2022 01:23:45 -0500
Received: from woodpecker.gentoo.org ([140.211.166.183]:58672
 helo=smtp.gentoo.org) by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <vapier@HIDDEN>) id 1n9huA-00022K-Ku
 for 31728 <at> debbugs.gnu.org; Tue, 18 Jan 2022 01:23:43 -0500
Received: by smtp.gentoo.org (Postfix, from userid 559)
 id 4F848342EB0; Tue, 18 Jan 2022 06:23:36 +0000 (UTC)
From: Mike Frysinger <vapier@HIDDEN>
Date: Tue, 18 Jan 2022 01:23:34 -0500
Message-Id: <20220118062334.5472-1-vapier@HIDDEN>
X-Mailer: git-send-email 2.33.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

This macro doesn't really fit in with Automake's mission.  It's a simple
configure option to add a specific library when linking.  Maybe back in
1996 the dmalloc project was more canonical, but nowadays developers have
a wealth of options when it comes to memory debugging, both from ones
based in compile-time instrumentation (e.g. the various GNU sanitizers),
to ones that work at runtime only (e.g. valgrind and GNU C library's
various M_* env vars).  We can't really add value by trying to track all
of them, and dmalloc itself seems to have fallen significantly in use.

Lets mark it obsolete and start issuing warnings whenever anyone tries
to use it.  Considering we've had it in automake for 2 decades, we can
probably keep it around for a while still in warning mode to give users
ample time to migrate.

This was suggested in https://debbugs.gnu.org/31728.

* doc/automake.texi: Move AM_WITH_DMALLOC to Obsolete Macros chapter.
* m4/dmalloc.m4: Call m4_warn(obsolete) when used.
---
 doc/automake.texi | 21 ++++++++++++---------
 m4/dmalloc.m4     |  5 ++++-
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/doc/automake.texi b/doc/automake.texi
index 9916a41d4b79..ae7a49cba247 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -4170,15 +4170,6 @@ the @command{missing} script is appropriate.
 Control the machinery for less verbose build output
 (@pxref{Automake Silent Rules}).
 
-@item AM_WITH_DMALLOC
-@acindex AM_WITH_DMALLOC
-@cindex @command{dmalloc}, support for
-@vindex WITH_DMALLOC
-@opindex --with-dmalloc
-Add support for the @uref{https://dmalloc.com/, Dmalloc package}.  If
-the user runs @command{configure} with @option{--with-dmalloc}, then
-define @code{WITH_DMALLOC} and add @option{-ldmalloc} to @code{LIBS}.
-
 @end table
 
 
@@ -4218,6 +4209,18 @@ you are advised to switch ASAP to the more modern Autoconf-provided
 interface instead; both the macro and the variable might be removed
 in a future major Automake release.
 
+@item AM_WITH_DMALLOC
+@acindex AM_WITH_DMALLOC
+@cindex @command{dmalloc}, support for
+@vindex WITH_DMALLOC
+@opindex --with-dmalloc
+
+Add support for the @uref{https://dmalloc.com/, Dmalloc package}.  If
+the user runs @command{configure} with @option{--with-dmalloc}, then
+define @code{WITH_DMALLOC} and add @option{-ldmalloc} to @code{LIBS}.
+
+This macro is @emph{deprecated} and will be removed in a future release.
+
 @end table
 
 
diff --git a/m4/dmalloc.m4 b/m4/dmalloc.m4
index 66d943e4de4c..eecb7e4186f8 100644
--- a/m4/dmalloc.m4
+++ b/m4/dmalloc.m4
@@ -10,7 +10,10 @@
 # with or without modifications, as long as this notice is preserved.
 
 AC_DEFUN([AM_WITH_DMALLOC],
-[AC_MSG_CHECKING([if malloc debugging is wanted])
+[m4_warn([obsolete],
+['$0': this macro is obsolete.
+You should add your own configure and link tests instead.])dnl
+AC_MSG_CHECKING([if malloc debugging is wanted])
 AC_ARG_WITH([dmalloc],
 [AS_HELP_STRING([--with-dmalloc],
                 [use dmalloc, as in http://www.dmalloc.com])],
-- 
2.33.0

Message sent to bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31728: [PATCH] dmalloc: mark macro as obsolete
References: <CADyTPEzig02npgBd-9LVUmAUQUSfn1Y-57gzzKECykoKvOyrPg@HIDDEN>
Resent-From: Karl Berry <karl@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-automake@HIDDEN
Resent-Date: Tue, 18 Jan 2022 23:16:01 +0000
Resent-Message-ID: <handler.31728.B31728.164254771018406 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31728
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: 
To: vapier@HIDDEN
Cc: 31728 <at> debbugs.gnu.org
Received: via spool by 31728-submit <at> debbugs.gnu.org id=B31728.164254771018406
          (code B ref 31728); Tue, 18 Jan 2022 23:16:01 +0000
Received: (at 31728) by debbugs.gnu.org; 18 Jan 2022 23:15:10 +0000
Received: from localhost ([127.0.0.1]:51938 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n9xh0-0004mn-KO
	for submit <at> debbugs.gnu.org; Tue, 18 Jan 2022 18:15:10 -0500
Received: from freefriends.org ([96.88.95.60]:41320)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <karl@HIDDEN>) id 1n9xgy-0004mX-SN
 for 31728 <at> debbugs.gnu.org; Tue, 18 Jan 2022 18:15:09 -0500
X-Envelope-From: karl@HIDDEN
Received: from freefriends.org (freefriends.org [96.88.95.60])
 by freefriends.org (8.14.7/8.14.7) with ESMTP id 20INF7u2022016
 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); 
 Tue, 18 Jan 2022 16:15:07 -0700
Received: (from apache@localhost)
 by freefriends.org (8.14.7/8.14.7/Submit) id 20INF6hR021989;
 Tue, 18 Jan 2022 16:15:06 -0700
Date: Tue, 18 Jan 2022 16:15:06 -0700
Message-Id: <202201182315.20INF6hR021989@HIDDEN>
From: Karl Berry <karl@HIDDEN>
In-Reply-To: <20220118062334.5472-1-vapier@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

To me, the question is, does the current AM_WITH_DMALLOC actually work?
Or not?  If it does, I see no reason to have it issue a warning, and
thus annoy anyone who has it in their configure.ac, where it is
presumably residing harmlessly.

I agree it does not "fit with Automake's mission", and wouldn't want to
add any similar macros, but to me that's not enough reason to
"deprecate" something that's been part of Automake for so long.

I feel strongly that the macro should never be deleted, useless though
it may be(come). -k

Message sent to bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31728: [PATCH] dmalloc: mark macro as obsolete
Resent-From: Mike Frysinger <vapier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-automake@HIDDEN
Resent-Date: Wed, 19 Jan 2022 03:08:02 +0000
Resent-Message-ID: <handler.31728.B31728.16425616719381 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31728
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: 
To: Karl Berry <karl@HIDDEN>
Cc: 31728 <at> debbugs.gnu.org
Received: via spool by 31728-submit <at> debbugs.gnu.org id=B31728.16425616719381
          (code B ref 31728); Wed, 19 Jan 2022 03:08:02 +0000
Received: (at 31728) by debbugs.gnu.org; 19 Jan 2022 03:07:51 +0000
Received: from localhost ([127.0.0.1]:52046 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nA1KA-0002RF-Mr
	for submit <at> debbugs.gnu.org; Tue, 18 Jan 2022 22:07:50 -0500
Received: from woodpecker.gentoo.org ([140.211.166.183]:60142
 helo=smtp.gentoo.org) by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <vapier@HIDDEN>) id 1nA1K6-0002Qw-7Y
 for 31728 <at> debbugs.gnu.org; Tue, 18 Jan 2022 22:07:49 -0500
Received: by smtp.gentoo.org (Postfix, from userid 559)
 id D047C3431BC; Wed, 19 Jan 2022 03:07:39 +0000 (UTC)
Date: Tue, 18 Jan 2022 22:07:40 -0500
From: Mike Frysinger <vapier@HIDDEN>
Message-ID: <YeeAfL6Iee2p1uvr@vapier>
Mail-Followup-To: Karl Berry <karl@HIDDEN>, 31728 <at> debbugs.gnu.org
References: <20220118062334.5472-1-vapier@HIDDEN>
 <202201182315.20INF6hR021989@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="tXwGitsCgikU+zfB"
Content-Disposition: inline
In-Reply-To: <202201182315.20INF6hR021989@HIDDEN>
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)


--tXwGitsCgikU+zfB
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

On 18 Jan 2022 16:15, Karl Berry wrote:
> To me, the question is, does the current AM_WITH_DMALLOC actually work?
> Or not?  If it does, I see no reason to have it issue a warning, and
> thus annoy anyone who has it in their configure.ac, where it is
> presumably residing harmlessly.

how are you defining "work" ?  all it does is add -ldmalloc to $LIBS.
it doesn't verify the library actually exists, or that it's even the
right library for the language (-ldmalloc is for C while -ldmallocxx
is for C++, and there's another for threaded projects).

it also adds -g to LDFLAGS ... for some reason.  i assume it wanted
to use -g in CFLAGS instead so it has access to debugging information.
afaict, -g doesn't actually do anything with linkers ... GNU ld ignores
it for historical compatibility with other tools, and it has for over
20 years (git history stops at 1999).

so it works in that it's syntactically valid shell code, and uses the
right autoconf macros, but it doesn't really work in the sense that
users care about and actually want to rely on.

> I agree it does not "fit with Automake's mission", and wouldn't want to
> add any similar macros, but to me that's not enough reason to
> "deprecate" something that's been part of Automake for so long.

imo automake should be providing a curated experience, not get bogged
down under its own historical baggage, or provide macros that (frankly)
are not that useful or maintained.

in the case of this macro, we can see it has at least 4 issues:
* outdated homepage
* bad language/runtime support
* lacks proper detection (e.g. compile/link tests)
* uses useless/obsolete flags (LDFLAGS=-g)

rather than continue to provide a disservice to our users and put up a
facade that we're actually keeping this thing healthy, just cut it off.
i strongly doubt anyone will care.

it's also a drain on us.  when we need to update macros or cleanup style
or similar house keeping tasks, this is a time suck.  we spend energy on
code no one uses.  i won't argue it's a *lot* of time, but it's def not
zero.  i'd rather we spend that time doing what we should be doing :).

> I feel strongly that the macro should never be deleted, useless though
> it may be(come). -k

let's deprecate it and we can circle back in a decade to see if you still
think we should keep it.
-mike

--tXwGitsCgikU+zfB
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmHngHwACgkQQWM7n+g3
9YETOBAAprvTeqVM1k5MQEDelceX04oydWskSnOsqAz9wj1VNp8QJyQOB6by9LnB
OqgrS7KfEO7I6udTeUbZHsc5sfexZ46Z0ZAt3Rcn/PZw0bmO6mnEjctaQ+Nv8tkH
iIRV55xaLf6becglFwZAw1PuJ3ci9tDRSeOweHzzZiqouNhniKOhKoqo0Kzm4LIR
wFCVe3pTF0IjkXcL0fc1ivNtzqBTPRTgFk57xkV9iH3zKmG6Y28/xkFs4DQmYwnj
xXEnurXV9OF+qC+X3Ab8O91oW+RQwhwyT10zfv7RO3/Open6cbFOeWdd5ID0ZSFK
BomWEuYAYlKfyOGuOo5RNfls2YQo07UDZwuPDZNLK0Fm/aSlS0dMtrMuE4I/HPjS
EvGsBVx3iPTDPNIdEzcHvRRQxPwFV1VLpPZXCYzlHRdGIe6M1SPpT8AC70LyU2/6
f3gfDkXNkcjwgi/YLR3Kxo0l64XwJULdOBm7J9kZw3nc4umCb5CstQIU5Wd6UkC/
g5QbRtqEHw6dNU8PIAV9/+Ew9wNvSeOxRk/7t/GqLCEzAQU6xi8TyGbr+Qxt7PDr
zVy0sRhoo99AfkGjRqiJWrnLPIk2WlQR29izlbFKEZRllygUKF7gH3Y6AlYR2eE3
98QGlUyg/BNucphfA3KBXcMDavFKu6yOOx4ohmoB9/0EHqZ7jR8=
=r5JI
-----END PGP SIGNATURE-----

--tXwGitsCgikU+zfB--

Message sent to bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31728: [PATCH] dmalloc: mark macro as obsolete
References: <CADyTPEzig02npgBd-9LVUmAUQUSfn1Y-57gzzKECykoKvOyrPg@HIDDEN>
Resent-From: Karl Berry <karl@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-automake@HIDDEN
Resent-Date: Sat, 22 Jan 2022 21:45:02 +0000
Resent-Message-ID: <handler.31728.B31728.164288785429881 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31728
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: 
To: vapier@HIDDEN
Cc: 31728 <at> debbugs.gnu.org
Received: via spool by 31728-submit <at> debbugs.gnu.org id=B31728.164288785429881
          (code B ref 31728); Sat, 22 Jan 2022 21:45:02 +0000
Received: (at 31728) by debbugs.gnu.org; 22 Jan 2022 21:44:14 +0000
Received: from localhost ([127.0.0.1]:38138 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nBOBB-0007lt-T4
	for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 16:44:14 -0500
Received: from freefriends.org ([96.88.95.60]:59066)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <karl@HIDDEN>) id 1nBOBA-0007lm-QU
 for 31728 <at> debbugs.gnu.org; Sat, 22 Jan 2022 16:44:13 -0500
X-Envelope-From: karl@HIDDEN
Received: from freefriends.org (freefriends.org [96.88.95.60])
 by freefriends.org (8.14.7/8.14.7) with ESMTP id 20MLiBFv020768
 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); 
 Sat, 22 Jan 2022 14:44:12 -0700
Received: (from apache@localhost)
 by freefriends.org (8.14.7/8.14.7/Submit) id 20MLiBYI020767;
 Sat, 22 Jan 2022 14:44:11 -0700
Date: Sat, 22 Jan 2022 14:44:11 -0700
Message-Id: <202201222144.20MLiBYI020767@HIDDEN>
From: Karl Berry <karl@HIDDEN>
In-Reply-To: <YeeAfL6Iee2p1uvr@vapier>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Sorry, I still disagree with "deprecating" AM_WITH_DMALLOC (or anything
else). My wish would be to add some strong wording in the manual about
how it doesn't do anything especially useful, new code shouldn't use it,
etc., and let it go at that.

I don't argue that AM_WITH_DMALLOC is useful.  But since it has been
there forever, I argue that deprecating it is harmful, in that it causes
gratuitous work for maintainers whose configure.ac's happen to have it.

Having been forced to waste more of my time than I care to think about
because some upstream maintainer decided to "clean up" their interface
or code, and deprecate/remove perfectly fine, or at least not harmful,
macros/functions/options/whatever, I (strongly) don't want to inflict
that on anyone else.

As far as I can see, the only way AM_WITH_DMALLOC will cause any problem
to anyone is if we deprecate/remove it. No one has ever complained about
it outside of this bug, so far as I know. So how about if we save
everyone time and trouble and do nothing to it? -k

Message sent to bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31728: [PATCH] dmalloc: mark macro as obsolete
Resent-From: "Zack Weinberg" <zack@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-automake@HIDDEN
Resent-Date: Mon, 24 Jan 2022 14:04:01 +0000
Resent-Message-ID: <handler.31728.B.164303301912481 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31728
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: 
To: 31728 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-automake@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.164303301912481
          (code B ref -1); Mon, 24 Jan 2022 14:04:01 +0000
Received: (at submit) by debbugs.gnu.org; 24 Jan 2022 14:03:39 +0000
Received: from localhost ([127.0.0.1]:42612 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nBzwZ-0003FE-E0
	for submit <at> debbugs.gnu.org; Mon, 24 Jan 2022 09:03:39 -0500
Received: from lists.gnu.org ([209.51.188.17]:53632)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <zack@HIDDEN>) id 1nBzwU-0003Ey-88
 for submit <at> debbugs.gnu.org; Mon, 24 Jan 2022 09:03:37 -0500
Received: from eggs.gnu.org ([209.51.188.92]:38204)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <zack@HIDDEN>) id 1nBzwU-0006mi-0l
 for bug-automake@HIDDEN; Mon, 24 Jan 2022 09:03:34 -0500
Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:55847)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <zack@HIDDEN>) id 1nBzwK-0002XM-34
 for bug-automake@HIDDEN; Mon, 24 Jan 2022 09:03:31 -0500
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
 by mailout.west.internal (Postfix) with ESMTP id B5082320208F
 for <bug-automake@HIDDEN>; Mon, 24 Jan 2022 09:02:41 -0500 (EST)
Received: from imap45 ([10.202.2.95])
 by compute4.internal (MEProxy); Mon, 24 Jan 2022 09:02:41 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h=
 cc:content-type:date:date:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:references:reply-to:sender:subject
 :subject:to:to; s=fm2; bh=LkhLNzlCbJAW1HRLxy7FxQJlvBHchxHJtNrHpD
 KrmpM=; b=JTq4hrB1vnkoVYBmFQNPUEi/wmUdrmNlvoVfif9Ypd5BfvCPGEC5qQ
 dxiBTG/0UN3aitviYMSSv3ZSpvG8mbXfCUXkPP47n6GSsSrdjLUGdwrJR3if++7R
 ZdIY5+b35S4POcv5ll41cibj83k3Ngujm4F90sHk40rks2/FytLyHEkdUYot/yPu
 K2CBCRH96IjAy+QhD/2t/PUn55bm4RBf6Rj4hulERe+gJp9ytpis1aaPfPEZFpo/
 fDDLkf6MFrpHsAXvYLwt4RejaR6dmdCdDELXSpqy1c6qZ2qVA0y2e0ILT0Ai+DDW
 EH6g8atmVIylsvBwlnxowMYtKJYrJP8w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:date:from:from
 :in-reply-to:in-reply-to:message-id:mime-version:references
 :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=LkhLNzlCbJAW1HRLx
 y7FxQJlvBHchxHJtNrHpDKrmpM=; b=CW3kCtmmurtSfDDYQ7PuRQQUVLZbciNGr
 snvhiejIiT40JcidOr4s2I0qO83ct3kBNWRWuGG1YaO+KTvRuHmG3KCcT+B8lsJn
 4ryGd6yfg0V6Ykq7tnityIQ2O/A+NXNGdatWKoxSKQ65jrWYPv0FhczZSp83XvPA
 MvR9oO8dfwEnp7Y3eauj3YlX+8Dupd5e3AVFCaJjAisNHCfkdHmn2iBEqj68qcX9
 uEreIEMUOVu9UO8iLkL8/06uQ5eunPA7R31eOGkP8LNzet0mR8eCGmZQxSi2LZLO
 27MOZj+zLq+/cIdwHk63ASpvsqo+yui+Aw25cc+l92Utk4WieL2xw==
X-ME-Sender: <xms:f7HuYRlEsN1CXFYDW5YLMyYIlxAs5R6yS1KZP-5mmbYOtfTcnFNhpQ>
 <xme:f7HuYc2QPX45-7UGxStJDs-0SIlk6l6URjSXqIveposHF_WZ_jYnklUKA9R3XlFIg
 f-NNC4VGj1egwd5GBo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvdeigdehlecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre
 dtreertdenucfhrhhomhepfdgkrggtkhcuhggvihhnsggvrhhgfdcuoeiirggtkhesohif
 lhhfohhlihhordhorhhgqeenucggtffrrghtthgvrhhnpefhuefhveeuffetfffgjeetgf
 ekkeehfedtfeelgfehffffveehkeelfefgheffudenucevlhhushhtvghrufhiiigvpedt
 necurfgrrhgrmhepmhgrihhlfhhrohhmpeiirggtkhesohiflhhfohhlihhordhorhhg
X-ME-Proxy: <xmx:gLHuYXotq0qECSjBPbzbPSQ_Y7kxNOmMu-DMMjwCS36TFbj_ZHvr5g>
 <xmx:gLHuYRllGZPOD_kslAgs2w7YbRGJEWOcn1BlWH3vmtYJPeY4hPGJxA>
 <xmx:gLHuYf1F9I80Riu6dQdMpcCxhlo8zi0ofZjOcJ8h4ZqK4MS5oi3_RA>
 <xmx:gbHuYQC58fjL2Y3F5hFmGtVfrbyinDMNMEu2-flKi9tu9UHyuSYBzw>
Received: by mailuser.nyi.internal (Postfix, from userid 501)
 id C124524A0077; Mon, 24 Jan 2022 09:02:39 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4585-ga9d9773056-fm-20220113.001-ga9d97730
Mime-Version: 1.0
Message-Id: <2c177319-5536-4862-8761-48e161113da2@HIDDEN>
In-Reply-To: <202201222144.20MLiBYI020767@HIDDEN>
References: <CADyTPEzig02npgBd-9LVUmAUQUSfn1Y-57gzzKECykoKvOyrPg@HIDDEN>
 <202201222144.20MLiBYI020767@HIDDEN>
Date: Mon, 24 Jan 2022 09:02:19 -0500
From: "Zack Weinberg" <zack@HIDDEN>
Content-Type: text/plain
Received-SPF: pass client-ip=64.147.123.21; envelope-from=zack@HIDDEN;
 helo=wout5-smtp.messagingengine.com
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.6 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.6 (--)

On Sat, Jan 22, 2022, at 4:44 PM, Karl Berry wrote:
> Sorry, I still disagree with "deprecating" AM_WITH_DMALLOC (or anything
> else). My wish would be to add some strong wording in the manual about
> how it doesn't do anything especially useful, new code shouldn't use it,
> etc., and let it go at that.

I understand where you are coming from but I want to make a counterargument.
Autotools in general have a problem where there are lots of macros that
solve problems that are no longer important, but people keep including them
in configure.ac anyway, because they don't realize that they are no longer
important.  Often the code doesn't actually work in the situation the macro
is testing for, because they haven't been diligent enough with the #ifdefs
or whatever, and nobody notices.

Putting strong wording in the manual is not enough to get people to stop
using these macros in new code, because people aren't reading the manual,
they are copying configure.ac fragments from other programs (which may or
may not have been written back in the day when the portability problems
addressed by the macros _were_ still important).

> I don't argue that AM_WITH_DMALLOC is useful.  But since it has been
> there forever, I argue that deprecating it is harmful, in that it causes
> gratuitous work for maintainers whose configure.ac's happen to have it.

Deprecation warnings are a blunt instrument, and I appreciate that they
make extra work for maintainers, but I will argue that that extra work
is _worthwhile_ work because it means their configure.ac's become
_better examples_ for the sorts of people who want to copy and tinker
existing code rather than reading documentation.

zw

Last modified: Mon, 24 Jan 2022 14:15:01 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.