>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 [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
