Received: (at submit) by debbugs.gnu.org; 24 Jan 2022 14:03:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 24 09:03:39 2022 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> To: bug-automake@HIDDEN Subject: Re: bug#31728: [PATCH] dmalloc: mark macro as obsolete 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-Debbugs-Envelope-To: submit 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
bug-automake@HIDDEN:bug#31728; Package automake.
Full text available.Received: (at 31728) by debbugs.gnu.org; 22 Jan 2022 21:44:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 16:44:14 2022 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> To: vapier@HIDDEN Subject: Re: bug#31728: [PATCH] dmalloc: mark macro as obsolete In-Reply-To: <YeeAfL6Iee2p1uvr@vapier> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 31728 Cc: 31728 <at> debbugs.gnu.org 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
bug-automake@HIDDEN:bug#31728; Package automake.
Full text available.Received: (at 31728) by debbugs.gnu.org; 19 Jan 2022 03:07:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 18 22:07:51 2022 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> To: Karl Berry <karl@HIDDEN> Subject: Re: bug#31728: [PATCH] dmalloc: mark macro as obsolete 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-Debbugs-Envelope-To: 31728 Cc: 31728 <at> debbugs.gnu.org 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--
bug-automake@HIDDEN:bug#31728; Package automake.
Full text available.Received: (at 31728) by debbugs.gnu.org; 18 Jan 2022 23:15:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 18 18:15:10 2022 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> To: vapier@HIDDEN Subject: Re: bug#31728: [PATCH] dmalloc: mark macro as obsolete In-Reply-To: <20220118062334.5472-1-vapier@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 31728 Cc: 31728 <at> debbugs.gnu.org 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
bug-automake@HIDDEN:bug#31728; Package automake.
Full text available.
Received: (at 31728) by debbugs.gnu.org; 18 Jan 2022 06:23:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 18 01:23:45 2022
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>
To: 31728 <at> debbugs.gnu.org
Subject: [PATCH] dmalloc: mark macro as obsolete
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-Debbugs-Envelope-To: 31728
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
bug-automake@HIDDEN:bug#31728; Package automake.
Full text available.Received: (at 31728) by debbugs.gnu.org; 12 Dec 2021 03:37:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 11 22:37:17 2021 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> To: Karl Berry <karl@HIDDEN> Subject: Re: bug#31728: Automake and AM_WITH_DMALLOC; endorsing proprietary software? 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-Debbugs-Envelope-To: 31728 Cc: nbowler@HIDDEN, 31728 <at> debbugs.gnu.org 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--
bug-automake@HIDDEN:bug#31728; Package automake.
Full text available.
Received: (at 31728) by debbugs.gnu.org; 11 Dec 2021 22:42:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 11 17:42:54 2021
Received: from localhost ([127.0.0.1]:50247 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mwB4w-0004Fm-AD
for submit <at> debbugs.gnu.org; Sat, 11 Dec 2021 17:42:54 -0500
Received: from freefriends.org ([96.88.95.60]:52860)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <karl@HIDDEN>) id 1mwB4t-0004Fd-4F
for 31728 <at> debbugs.gnu.org; Sat, 11 Dec 2021 17:42:52 -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 1BBMgnrf022848
(version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sat, 11 Dec 2021 15:42:50 -0700
Received: (from apache@localhost)
by freefriends.org (8.14.7/8.14.7/Submit) id 1BBMgmDQ022847;
Sat, 11 Dec 2021 15:42:48 -0700
Date: Sat, 11 Dec 2021 15:42:48 -0700
Message-Id: <202112112242.1BBMgmDQ022847@HIDDEN>
From: Karl Berry <karl@HIDDEN>
To: vapier@HIDDEN
Subject: Re: bug#31728: Automake and AM_WITH_DMALLOC;
endorsing proprietary software?
In-Reply-To: <YbMB2YT0Od112Kga@vapier>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 31728
Cc: nbowler@HIDDEN, 31728 <at> debbugs.gnu.org
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 (---)
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
bug-automake@HIDDEN:bug#31728; Package automake.
Full text available.Received: (at 31728) by debbugs.gnu.org; 10 Dec 2021 07:29:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 10 02:29:30 2021 Received: from localhost ([127.0.0.1]:45405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mvaLS-0007xR-FD for submit <at> debbugs.gnu.org; Fri, 10 Dec 2021 02:29:30 -0500 Received: from woodpecker.gentoo.org ([140.211.166.183]:59606 helo=smtp.gentoo.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <vapier@HIDDEN>) id 1mvaLR-0007xD-7x for 31728 <at> debbugs.gnu.org; Fri, 10 Dec 2021 02:29:29 -0500 Received: by smtp.gentoo.org (Postfix, from userid 559) id DCD7F343020; Fri, 10 Dec 2021 07:29:22 +0000 (UTC) Date: Fri, 10 Dec 2021 02:29:29 -0500 From: Mike Frysinger <vapier@HIDDEN> To: Nick Bowler <nbowler@HIDDEN> Subject: Re: bug#31728: Automake and AM_WITH_DMALLOC; endorsing proprietary software? 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> X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 31728 Cc: 31728 <at> debbugs.gnu.org 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 (------) 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
bug-automake@HIDDEN:bug#31728; Package automake.
Full text available.Received: (at submit) by debbugs.gnu.org; 5 Jun 2018 19:09:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 05 15:09:48 2018 Received: from localhost ([127.0.0.1]:35497 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fQHL0-0003SO-L4 for submit <at> debbugs.gnu.org; Tue, 05 Jun 2018 15:09:48 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51906) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <nbowler@HIDDEN>) id 1fQHKy-0003S8-8D for submit <at> debbugs.gnu.org; Tue, 05 Jun 2018 15:09:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <nbowler@HIDDEN>) id 1fQHKs-0003l1-1o for submit <at> debbugs.gnu.org; Tue, 05 Jun 2018 15:09:39 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:46617) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <nbowler@HIDDEN>) id 1fQHKr-0003ks-UF for submit <at> debbugs.gnu.org; Tue, 05 Jun 2018 15:09:37 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <nbowler@HIDDEN>) id 1fQHKq-0003gc-I4 for bug-automake@HIDDEN; Tue, 05 Jun 2018 15:09:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <nbowler@HIDDEN>) id 1fQHKl-0003hC-Sd for bug-automake@HIDDEN; Tue, 05 Jun 2018 15:09:36 -0400 Received: from mail-lf0-x22d.google.com ([2a00:1450:4010:c07::22d]:39580) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from <nbowler@HIDDEN>) id 1fQHKl-0003fP-Ii for bug-automake@HIDDEN; Tue, 05 Jun 2018 15:09:31 -0400 Received: by mail-lf0-x22d.google.com with SMTP id t134-v6so5273829lff.6 for <bug-automake@HIDDEN>; Tue, 05 Jun 2018 12:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=draconx-ca.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=OzjBE6qnVeXHF76Mykeb51+a+4Rb9YEnXiRXP6zWN4o=; b=103833+wQBtNRS2cflD0WyVFkfjMfL/JMa9wWXE4tS3DJoV+x1+j4ElwXaNoDzLRXI JE8pNq+YmegC3/j6TVL0+/IQX/pzWdPnImzXC95sZPUAGF/F+Kw9Ht5Q33p2Ys0aM38N IVa6xMJF1ygkW/VdwpVmFM2fY08eXGG0h1mvl58kVMlnkcsP61C3MBWSxsXj5Y17tRs3 r3DEGCTLBcUCRt/1NZM00qciVjuPeToTt0fIYiRQnt5wtAFIpiRBBgVvshpyoUHVAG8m pCiUZPocH6sGp8+Q4zir0yv61Axx8nFMRO8nuoJPPBk9VySzDMJteH5cILOxoDZ11MxS TQOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OzjBE6qnVeXHF76Mykeb51+a+4Rb9YEnXiRXP6zWN4o=; b=MzL7gA5PZRLN2ckXoUXPR0SdF2EBq1/b34NTOY1g/zaej9O93u76CzEUSywMtFw0e6 xFbshCf5sVSqlhS9WvIqbt9FCPY5YvSg9zn+L3y9aYkK0Y2xLwkRlduOGlbZH2hR3sIC zPfCyKtgJfwAMFQetd55Yz1hgTqY7WynNYd+YnRQ1KUjrAT61Ws7LtYyTfkVacmsP+an Se+azE4ziKcfHLS6S0iElY+W530RxMNgN0KQKycoR8/A+phgfxTR3AKnhNhw857txJ7N 2jtzuU0/5oWZPl7uBbYEtLLvCWG+8I/lbWDHG1wm0aSCFlxY3tE/MguOZIpNXDGNlN+B d9uQ== X-Gm-Message-State: APt69E0+5W0mQG0VNZi8XzYIrmhxwcdcZoznzRpXoClCfl4TUws5qX8K 1WdnvM8Fb92NlUkoBDMAc+hSdXGVbJMCJFlAs+Hvng== X-Google-Smtp-Source: ADUXVKIuNwwh+Hj+39nQKqAMn9dcxNt1rBa25FN/pqmpu6S7hPSedmfvAW6DQZKYLUJ7JMObUklJJOCbSX/7MSpq4mI= X-Received: by 2002:a2e:428e:: with SMTP id h14-v6mr7538701ljf.136.1528225769746; Tue, 05 Jun 2018 12:09:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8889:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 12:09:29 -0700 (PDT) X-Originating-IP: [162.243.96.244] From: Nick Bowler <nbowler@HIDDEN> Date: Tue, 5 Jun 2018 15:09:29 -0400 Message-ID: <CADyTPEzig02npgBd-9LVUmAUQUSfn1Y-57gzzKECykoKvOyrPg@HIDDEN> Subject: Automake and AM_WITH_DMALLOC; endorsing proprietary software? To: bug-automake@HIDDEN Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit 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 (------) 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
Nick Bowler <nbowler@HIDDEN>:bug-automake@HIDDEN.
Full text available.bug-automake@HIDDEN:bug#31728; Package automake.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.