Re: config.in

[Miles Bader]

"Eli Zaretskii" <address@hidden> writes:
> > Anyone who checks emacs out of CVS is basically not a normal user,
> > and it's perfectly reasonable to expect them to have normal GNU
> > tools.
> 
> IMHO, those requirements should be kept at the minimum, and that this
> should be a factor in our decisions, not something rejected off hand.

I agree -- but only a factor, and a secondary one.

> > 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!

> I was talking about config.in alone, not about the other generated
> files.  I don't have anything against removing other generated files
> we've discussed here, since they all are made during the build by
> running Emacs Commands.

The _main_ problem is `configure', which is generated by autoconf.

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.

> 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).  The
tradeoffs are not necessarily the same in every situation.

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research