Re: make dist

[Bob Proulx]

Charles Levert wrote:
> Tony Abou-Assaleh wrote:
> > GNU Autoconf recommends renaming configure.in to configure.ac. The only
> > benefit is a more meaningful name. Shall we?
> 
> One problem I see is that CVS doesn't support
> renaming a file so that the log history for
> the old configure.in would never be associated
> with the log history for the new configure.ac.
> You have to know about looking in both.
> So I don't advocate doing this unless there is
> a clearer benefit than a more meaningful name.

Personally I prefer the configure.ac name when practical.  In CVS I
think it is enough to mention in the log that the file was renamed
from the previous name as the first log comment.  That should be
enough to point the reader from one to the other.

But I also recognize that when searching through the logs this is not
as convenient and one has to know that the history was split.  And
then look in both files.  So renames are best to be scheduled at major
release points when discontinuities in the history are not *as*
important.  (I believe the history to be important and am not
advocating making it difficult to search gratuitously.)

I hesitate to mention this because I am not trying to open Pandora's
box but post CVS version control systems almost all preserve history
across file renames.  I have not heard any mention and don't want to
stir up trouble but if there is any inclination to move off of CVS at
any point in the future then renames after that time would preserve
the full history.  That would be a good argument for keeping the
current names until that time and doing any scheduled renames in the
new system.

> > 'GNU which' has a 'bootstrap' [1] script that serves the same function as
> > our autogen.sh, but I think is better written (actually that's how I
> > realized that I had an old automake). Can we borrow it? I could make the
> > necessary renamings, modifications, and testings.
> 
> Maybe.  I see a "head -1" in this.  Won't that
> cause some problems with newer coreutils
> versions?  I wouldn't want to trade one problem
> for another.

In the coreutils NEWS file:  (Version 5.93 is currently released as
stable.)

  * Major changes in release 5.90 (2005-09-29) [unstable]

  ** Bring back support for `head -NUM', `tail -NUM', etc. even when
    conforming to POSIX 1003.1-2001.  The following changes apply only
    when conforming to POSIX 1003.1-2001; there is no effect when
    conforming to older POSIX versions.

Note that this does not cover 'tail +NUM' which expects +NUM to be a
filename.  It only covers 'tail -NUM'.

Bob