Re: config.in

["Eli Zaretskii" <eliz@is.elta.co.il>]

> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: 17 Apr 2002 10:08:13 +0900
> 
> 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.

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

> > IMHO it doesn't make sense to go through all that just to save us the
> > ``cost'' of a 25KB file.
> 
> The `cost' is not 25KB, it's all the annoyance of constantly having to
> fight with CVS getting confused because a file got regenerated locally
> which then doesn't match the CVS version.  In my case, this also ends
> up making CVS updates take much longer because CVS ends up resending
> all the `changed' files back to the server over my slooow connection.

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.

I also doubt that the long update time you see will be significantly
affected by excluding config.in.  It's loaddefs.el that makes the
difference.

Yes, the CVS behavior whereby files are sent upstream if they are
suspected to be different is a bug (I'm being hit by that twice a
year, when the DST setting changes, because the Windows client
doesn't DTRT wrt time stamps).  But I've given up long ago on trying
to convince CVS maintainers that some of their ``features'' are
actually bad bugs, because I kept being told that I didn't understand
``the CVS spirit''.

> the default should be
> what's good for GNU systems, which are by far the majority among
> developers.

I _was_ talking about GNU systems; I build Emacs on fencepost
regularly.  I don't like to depend on the versions of the different
auto-* tools installed by sysadmins--it could just happen that they
fall out of sync, for example.  I also build both trunk and branch,
which use different Autoconf versions, so it's very easy to forget to
run an older version of Autoconf manually before running configure.
Now I will have to remember to run 2 commands by hand.  I don't want
that complication to ruin a release tarball some day.

As another data point, the GDB development keeps all regenerated
files in the CVS, including configure and even the Info files.