nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] cleaning out the cobwebs

2010-11-06 21:37:55
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

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