[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use.
From: |
Ken Hornstein |
Subject: |
Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use. |
Date: |
Thu, 01 Feb 2018 15:17:25 -0500 |
>> 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
- Re: [Nmh-workers] Where are we at for 1.7.1?, Anthony J. Bentley, 2018/02/01
- Re: [Nmh-workers] Where are we at for 1.7.1?, Ralph Corderoy, 2018/02/01
- Re: [Nmh-workers] Where are we at for 1.7.1?, Ralph Corderoy, 2018/02/01
- Re: [Nmh-workers] Where are we at for 1.7.1?, Ken Hornstein, 2018/02/01
- Re: [Nmh-workers] Searching the nmh-workers Archive., Ralph Corderoy, 2018/02/01
- Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use., Ralph Corderoy, 2018/02/01
- Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use.,
Ken Hornstein <=
- Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use., Ralph Corderoy, 2018/02/01
- Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use., Ken Hornstein, 2018/02/01
- Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use., Ralph Corderoy, 2018/02/02
- Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use., Ken Hornstein, 2018/02/02
- Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use., P Vix, 2018/02/02
- Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use., Ralph Corderoy, 2018/02/03
Re: [Nmh-workers] Where are we at for 1.7.1?, Todd C. Miller, 2018/02/01
Re: [Nmh-workers] Where are we at for 1.7.1?, Andy Bradford, 2018/02/01