Re: [Nmh-workers] cleaning out the cobwebs

[Ken Hornstein]

>Separate from the above, I would like to see as much as the pre-Posix
>gratuitous stuff removed from sbr.  It's fine with me if going forward,
>new versions of nmh only run on Posix-compatible systems.  I too am a hater
>of autoconf/automake;  I like elegance, not the ugliest sledgehammer in
>existence.  That said, I'd rather use these than create new ones.

While I'm not particularly in love with autoconf or automake, my response
to people who say that they hate autoconf is: what do you propose we use
instead?

Unfortunately, dealing with portability is ugly, and there is AFAIK no
elegant way to deal with this ugliness.  And unlike 90% of the open
source projects out there, autoconf and automake actually have
nearly-complete manuals that allow someone who has no experience with
these tools to get up to speed on them fairly quickly.  They are fairly
standard in the open source/Unix world, and all of the attempts I've seen
to use something else instead of them end up being vastly inferior.

(I know you were saying basically the same thing, Jon, but I guess this
is more toward the other comments.  And we don't use automake, so that's
really moot I think).

If someone wants to use something instead ... well, okay, let's see a
concrete proposal.  Unless you are suggesting going back to simply
editing a Makefile by hand to set things like features, install location,
etc etc.

>BTW, it seems to me that part of what's going on in m_getfld.c is poking
>around in stdio buffers to avoid fetching the data twice.  Most message are
>pretty small so I've wondered whether it would be better to just memory map
>the files.  Or, maybe systems are fast enough today that we can just bail
>on the tricky stuff and use stdio.  Any opinions?

My feeling: that might have been a win 15 years ago.  Now?  Meh.  When the
code gets so complicated that potential developers can't understand it,
then I don't think it's worth it.

--Ken