>> I asked about removing this feature once, and I only got minor >> pushback. While this API is part of POSIX, it doesn't seem like they >> are standardized in terms of header files & library names. > >POSIX, he say #include <ndbm.h>. And there's no special `-l foo' >required, unlike for some other include files. >http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ndbm.h.html >http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html#tag_20_11_13 >That's what configure.ac tries first.
Well, fair enough. That would remove a ton of hair when it comes to m4/ndbm.m4. I think part of this was because we always made it a requirement so we tried to find it whereever it was. If we just made it optional then the few people who cared would be required to set CPPFLAGS and/or LDFLAGS appropriately. > dnl Classic ndbm with no library required (eg NetBSD): try this > dnl first so we don't accidentally link in a pointless but harmless > dnl library in one of the later ndbm.h+libfoo tests: > NMH_CHECK_NDBM(ndbm.h,,, > dnl Berkeley DBv2 emulating ndbm: header in db.h, e.g., 32-bit Cygwin: > NMH_CHECK_NDBM(db.h,db,, > dnl Berkeley DBv1 emulating ndbm: > NMH_CHECK_NDBM(ndbm.h,db,, > NMH_CHECK_NDBM(ndbm.h,db1,, > ... > >> I'd rather make this support conditional; if we can't find a working >> db/dbm library then we just don't support duplicate message >> suppression. > >As long as slocal's -(no)suppressdup were errors so the user knew. And >a `make check' of it would be good because then of the `skip' in the >final count. Looks to me like the slocal test already does a check if that, if that's what you mean. >Would the big `nmh configuration' that's output at the end of >./configure then include whether ndbm.h support was found? It would be >handy if more were there, e.g. the recent `ICONV_ENABLED', as it's >something the user sees, might even read, and can easily pass onto us. Sure, that would make sense. Although I think we've moving iconv() to the "required" list, so having that in the configure output doesn't make sense to me. >> Also, the implementation seems to have the Message-Id database grow >> without bounds, so I have to wonder how much it's being used. > >Perhaps disk space has kept pace. Or the user sees the `possibly >corrupt file' error message and deletes it or otherwise fixes. Maybe? Or maybe next to nobody uses it? :-) In a perfect world it would be automatically pruned of old entries, but I don't think it's worth spending too much time on that code. --Ken -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers