Re: [Nmh-workers] nmh updates

[Ken Hornstein]

>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