bug#31728: [PATCH] dmalloc: mark macro as obsolete
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#31728: [PATCH] dmalloc: mark macro as obsolete
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#31728: [PATCH] dmalloc: mark macro as obsolete
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 signature.asc Description: PGP signature
bug#31728: [PATCH] dmalloc: mark macro as obsolete
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#31728: [PATCH] dmalloc: mark macro as obsolete
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
