-----BEGIN PGP SIGNED MESSAGE-----
"Ken" == Ken Hornstein <kenh(_at_)cmf(_dot_)nrl(_dot_)navy(_dot_)mil>
writes:
>> Well, I'll defer to the majority here and modify the INSTALL file
>> instead. But I want to point out that this is the opposite of
>> how just about every other package out there is done. Other
>> packages come with configure and config.h.in so that one doesn't
>> need autoheader and autoconf to do an installation. Can you
>> explain the rationale for being different?
Ken> The majority of open-source projects that I deal with do it
Ken> this way, FWIW. One example is OpenAFS
Ken> (http://www.openafs.org). I suspect if you did a survey you'd
Ken> find that more people stored the configure files in CVS than
Ken> not, but I believe they're wrong. Here's why:
Ken> - The point behind a revision control system is to track files
Ken> that _humans_ generate. Performing revision control on a file
Ken> that is automatically generated to me doesn't make any sense.
Ken> It gets worse when different versions of autoconf can generate
Ken> different configure scripts.
Ken, I agree with everything you say.
But, since every project I've worked on winds up with weird
dependancies upon the specific version of autoconf/autoheader, I think
that we do a serious disservice if you can't build easily from CVS.
Ken> - I've run into _tons_ of problems with projects who store the
Ken> configure files in CVS; if you have Makefile rules which
Ken> automatically rebuild configure (which we do, which I think is
Ken> a good idea) you have to be extremely careful in the order you
Ken> commit your files so that the timestamps end up correct so
Ken> configure is newer than configure.in; in one project I worked
Ken> on, nobody ever did this, so there were endless problems with
Ken> people accidentally commiting back configure scripts that they
Ken> didn't mean to generate but did because of the timestampts on
Ken> configure/configure.in and the Makefile rules.
The answer is that you "touch .devel", and then you get the rules that
auto-generate the right files.
Ken> Now, there's some confusion here on what is required to do an
Ken> install. When a tar file is built, of course I run autoheader
Ken> and autoconf so an end-user doesn't need autoconf to build nmh.
Ken> But I consider people who check out the CVS tree to be in the
Ken> "developer" category, and thus I think it's reasonable to
Ken> require them to have autoconf.
I'm okay with that, as long as you agree to run multiple versions of
autoconf on things (you can decide if 2.13 compatibility is important,
but running the absolute latest is important to me), and document which
version you actually did use in a file somewhere.
Ideally, your makefile rules will invoke "autoconf250" rather than
"autoconf".
- --
] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr(_at_)xelerance(_dot_)com http://www.sandelman.ottawa.on.ca/mcr/
|device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQW15VIqHRg3pndX9AQHS5QQAwy7yoX4KyKfZC7zjzGhyhErxMIGb+Cth
aURnlx36G7uMp34fC24LHUfqUIzFF0fUo8Nqjj58idNf2qfIQ4QfomEftv5NpL8R
Cf7PPQainwuecbcgpHta5zOZs0nrsRaE4Rqgfw2qgiaHO7gNfm+bV8kD+zePrmyV
+rroAQRYHDU=
=tTBv
-----END PGP SIGNATURE-----
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers