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