Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use.

[Ralph Corderoy]

Hi Ken,

> I think part of this was because we always made it a requirement so we
> tried to find it whereever it was.

And systems were a lot more varied a decade or more ago.  Even Cygwin
may have fallen into line by now.  :-)

> If we just made it optional then the few people who cared would be
> required to set CPPFLAGS and/or LDFLAGS appropriately.

True, but `it's POSIX' and that was used for iconv to make it mandatory.
And optional means the code and the tests have to be that bit more
complex.

> > 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.

Right, there's tests of -suppressdup, so if ndbm.h were made optional
then they'd need to `skip++' so the user saw the big `tests skipped' at
the end.

> > Would the big `nmh configuration' that's output at the end of
> > ./configure then include whether ndbm.h support was found?
>
> 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.

No, you're right, that was just something that occurred to me a few days
ago when the iconv issue came up.

> Maybe?  Or maybe next to nobody uses it? :-)  In a perfect world it
> would be automatically pruned of old entries

I don't think we can define `old'.  I wonder how well ndbm.h copes with
Message-IDs designed to cause collisions with its internal layout.  :-)

> but I don't think it's worth spending too much time on that code.

Nope.  For each message we open, lock, fetch, store?, close, unlock.
And they're going to translate to more than one syscall each.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy