emacs-devel
[Top][All Lists]
Advanced

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

Re: config.in


From: Eli Zaretskii
Subject: Re: config.in
Date: Wed, 17 Apr 2002 05:22:32 -0400

> From: Miles Bader <address@hidden>
> Date: 17 Apr 2002 14:54:35 +0900
> 
> > > Note that even if these generated files are included, they may _still_
> > > need the auto* programs, because CVS makes no attempt to preserve
> > > timestamps, and the Makefile will attempt to regenerate the files
> > > anyway (though the checked-out contents are actually `up to date').
> > 
> > This can be handled with a simple call to `touch', if it turns out to
> > be a real problem.
> 
> That is an annoying and error-prone method of dealing with the problem
> (and yes, it's a problem, that's why this issue keeps coming up); more
> often than not, by the time you realize something's amiss, it's too
> late, and CVS has screwed up the file by inserting conflict markers.
> 
> Morever, such a solution is _certainly_ not something that you'd
> recommend to clueless users; it's easier to tell them to install
> autoconf!

You misunderstood me--or rather, I didn't explain well enough what I
meant.  I didn't mean to suggest a manual `touch'.  The idea was to
put something into the configury which will do that automatically,
assuming we can detect time stamp mismatches that are produced by CVS.

> However, if we remove configure from CVS, then we should be consistent
> and remove the other autoconf generated files too, since they don't
> require any additional tools.

Yes, I agree that we should be consistent here.

> > As another data point, the GDB development keeps all regenerated
> > files in the CVS, including configure and even the Info files.
> 
> That is their decision (though I wouldn't be surprised if exactly this
> same flame war pops up periodically on their mailing lists).

FWIW, I'm reading their lists for the last couple of years, and I
don't remember any complaints.



reply via email to

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