Complete.Org: Mailing Lists: Archives: freeciv-dev: November 1998:
Re: [Freeciv-Dev] CVS: dwp: Autogenerated files from previous batch of c
Home

Re: [Freeciv-Dev] CVS: dwp: Autogenerated files from previous batch of c

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxxx
Subject: Re: [Freeciv-Dev] CVS: dwp: Autogenerated files from previous batch of chan...
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Tue, 17 Nov 1998 09:58:44 +1100

Falk Hueffner wrote:

> > ---- Log message:
> > 
> > Autogenerated files from previous batch of changes:
> > aclocal ; autoheader ; automake ; autoconf
> 
> Are you folks sure it is a wise idea to have autogenerated files in
> the CVS tree? They're at best redundant, and at worse outdated.

My understanding is that we _should_ include these files in the
_distribution_, when we make a release, for the reasons below.
(I'm not sure if that is in question or not?)  Given that the question 
is then whether they should be in _cvs_; see later.  

For including the files in the _distribution_, I believe we include all 
the autogenerated files which are platform independent, so that normal 
users don't need to have automake and autoconf installed and working on 
their system in order to compile freeciv.

>From autoconf docs:

%  The configuration scripts produced by Autoconf are independent of Autoconf 
% when they are run, so their users do not need to have Autoconf.

Also:

%    A software package that uses a `configure' script should be
% distributed with a file `Makefile.in', but no `Makefile'; that way, the
% user has to properly configure the package for the local system before
% compiling it.

This is what we do; we include Makefile.in (autogenerated by automake but 
system independent) but not Makefile (autogenerated by configure and system 
and user depedent).  Of course users who have the auto-tools and know what 
they are doing are free to regenerate all the autogenerated files if they wish.

Now whether they should be in _cvs_?

For: means people using cvs don't need automake/autoconf, as above.

Against: redundant and possibly out of date files, as Falk said. 
A related problem was that I decided to make an individual checkin for 
autogenerated changes derived from a batch of configure related changes, 
because each small individual change to configure.in can generate large 
diffs to the configure script (due to changes in internal numbering).  
So I didn't want to pollute the CVS repository unnecessarily. 

I'm in favour of keeping them in cvs, so we don't unnecessarily exclude
developers who don't happen to have automake or autoconf.  (Indeed some 
recent testing I did on a Solaris machine would have been more difficult
without these files in cvs, because that machine doesn't seem to have 
autoconf/automake.)

-- David



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