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

[Mike Frysinger]

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