nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] cleaning out the cobwebs

2010-11-05 23:37:17
    Date:        Wed, 03 Nov 2010 13:40:43 -0400
    From:        Ken Hornstein <kenh(_at_)pobox(_dot_)com>
    Message-ID:  
<201011031740(_dot_)oA3HehIg026014(_at_)hedwig(_dot_)cmf(_dot_)nrl(_dot_)navy(_dot_)mil>


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

I know that was written as kind of a rhetorical question, no-one would
ever want to go back to editing Makefiles and config.h type files, would
they, these days?

But yes, that is exactly the right solution these days - the time for autoconf
has passed (when Larry Wall wrote the config script for perl upon which all of
this is based, it was a great idea - no longer.)

That's partly because now it is possible to write much more portable code
in the first place, with some actual expectation that it will work, and
work effectively.   However, I am not nearly as confident as some here that
everything is possible simply by writing posix compatible code.   I don't mean
by that that posix code can't do what MH needs, but that I suspect that there
are still real users on real systems that don't do everything the posix way,
and I don't think that simply ignoring them is a rational approach.

More on the kind of config that's needed for this below.

But aside from that, as has been pointed out, there are compilation choices
(does my installation of MH really need support for ...), and installation
choices (where should the binaries, man page, etc, all get put).

For those, autoconf is no real help anyway, autoconf cannot know whether
I want to use kerberos with MH or not.  It often guesses - if it sees I have
kerberos (or whatever) installed, it just assumes I must want to use it, but
that's completely bogus.   Really, all autoconf provides for this kind of
option is a semi-standardised way by which I can tell the Makefiles which
options I want to turn on or off, and what path names should be uses for
installation directories, etc.   Personally, I prefer to simply edit that
kind of thing into the Makefile (or whatever) because then I have to do it
just once (I even get to use diff/patch type upgrade methods to move from
one version to the next).   As long as there aren't too many files that
need human attention, it is simply easier that way than supplying a whole
bunch of --prefix=/a/b/c --with-xxx --without-yyy type options to
configure every time I need to run it.

What's more, for anyone who does prefer a command line "edit the options"
tool, we have sed already - a simple script wrapper around that, and the
file editing can all be based upon command line options for those who prefer
it that way.

But the real reason autoconf isn't needed any more, isn't either of those,
that is, it isn't because POSIX rules everywhere, and that editing Makefiles
is easier than giving command line options (even though both of those are
mostly correct), it is that these days we're no longer in the situation where
we have every random half-knowing idiot in the world attempting to figure
out the answers to all of these questions by themselves.   Almost no-one
downloads nmh.tar.gz and starts from that to install MH any more, and those
who do, almost certainly know what they're doing and whether of not their
system has statfs() or statvfs() or whatever today's remaining questionable
portability issues are.

Almost everyone these days uses either pre-built binaries that someone else
has compiled for them, or one of the packaging systems that automate the
entire build process.  The only people who need to know what the settings for
all these options are are the people to provide the package system template 
files - and they're almost always people who understand enough about the
system they're building for to not need assistance from something like
autoconf - and more particularly, to not need to find ways to defeat it
(I observe NetBSD's pkgsrc developers go to sometimes absurd lengths to
defeat what configure scripts are trying to do when simply supplying patch
files to modify a Makefile or a configuration header file is trivial).

So, yes, please, remove all vestiges of autoconf from nmh - by making the
code portable where that is possible, and where it isn't, then yes,
just put the remaining config in whichever is appropriate of the main
Makefile, or a single options.h or config.h type header file (and from
which everything else gets info it needs).

kre


_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>