[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] nmh updates

From: Michael Richardson
Subject: Re: [Nmh-workers] nmh updates
Date: Wed, 13 Oct 2004 14:52:07 -0400


>>>>> "Ken" == Ken Hornstein <address@hidden> 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

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] address@hidden      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys


reply via email to

[Prev in Thread] Current Thread [Next in Thread]