bug#31728: [PATCH] dmalloc: mark macro as obsolete

[Zack Weinberg]

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