[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] nmh updates
From: |
Ken Hornstein |
Subject: |
Re: [Nmh-workers] nmh updates |
Date: |
Wed, 13 Oct 2004 14:28:47 -0400 |
>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?
The majority of open-source projects that I deal with do it this way,
FWIW. One example is OpenAFS (http://www.openafs.org). I suspect if you
did a survey you'd find that more people stored the configure files in
CVS than not, but I believe they're wrong. Here's why:
- The point behind a revision control system is to track files that
_humans_ generate. Performing revision control on a file that is
automatically generated to me doesn't make any sense. It gets worse
when different versions of autoconf can generate different configure
scripts.
- I've run into _tons_ of problems with projects who store the configure
files in CVS; if you have Makefile rules which automatically rebuild
configure (which we do, which I think is a good idea) you have to
be extremely careful in the order you commit your files so that the
timestamps end up correct so configure is newer than configure.in;
in one project I worked on, nobody ever did this, so there were endless
problems with people accidentally commiting back configure scripts
that they didn't mean to generate but did because of the timestampts
on configure/configure.in and the Makefile rules.
Now, there's some confusion here on what is required to do an install.
When a tar file is built, of course I run autoheader and autoconf so
an end-user doesn't need autoconf to build nmh. But I consider people
who check out the CVS tree to be in the "developer" category, and thus
I think it's reasonable to require them to have autoconf.
--Ken