Re: [Nmh-workers] cleaning out the cobwebs

[Ken Hornstein]

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

It has?  Since when?

I think you admit that POSIX won't simply cut it, even now.  I also think
that you're over-estimating the competence of the people who need to build
nmh; a lot of the time that falls to system administrators who are not
necessarily programmers.  A LOT of programs use autoconf; everyone
understands how it works.  You can even set it up so it takes the correct
options for things like --prefix at your site automatically.  If we can
write autoconf tests that automatically determine if a particular function
is broken or not, I don't see how that is _bad_.  We still have systems that
require optional libraries for networking calls; another perfect thing for
autoconf to test for.

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

If autoconf actually _did_ that every time, it would be bogus.  But it
doesn't.  Well, okay, it _could_, but that's a decision that the person
who writes the configure template makes; we don't do that for any of the
options that I'm aware of.  What autoconf _can_ do is after you decide
that you want to use Kerberos, run the vendor-supplied krb5-config script
(assuming your Kerberos isn't completely ancient) and extract out the
right Kerberos compilation and linker options.  This assumes that we
actually linked against Kerberos directly (nowadays, we don't; we link
against Cyrus-SASL, but we don't do that unless the user asks us to).

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

I respect that doing that is your preference.  However, I don't
believe that is _everyone's_ preference.

I keep around my old build directories, and I can go back and look at
config.status to see what options I used last time.  I guess I don't see
how that is worse than doing diff/patch upgrades.

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

The cases I'm familiar with, that is working around assumptions that
everything is Linux.  Certainly we can do better than that.

--Ken