Removing derived files from CVS - Mailing list pgsql-hackers

I have been looking into what it would take to remove derived files
from the CVS repository, and it doesn't look bad at all.  I propose
we do so before 6.5 beta.

In case anyone's forgotten: the issue is derived files, such as gram.c,
which we currently keep in the CVS repository even though they are not
master source files.  Doing so causes a number of headaches, including
wasted time to check in and check out updates to both master and derived
files, unreasonable bulk of the CVS files for these derived files,
errors due to timestamp skew (after checking out, it can look like you
have an up-to-date derived file when you do not), etc etc.

The only reason for keeping these files in CVS is so that users who
obtain the source distribution don't have to have tools that can rebuild
these files.  But there's a better way to handle that: generate the derived
files while preparing tarballs.  That way we can remove the derived
files from CVS.  We'll also eliminate the other time skew problem that's
been seen in more than one past release tarball: the derived files will
be certain to have newer timestamps than their masters in the tarballs.

The most reliable way to do this is just to have a script that doesconfigure"make" all the derived filesmake distclean
and invoke this script as part of the tarball generation procedure.
Configuring in order to find out which yacc and lex to use may seem
a tad expensive ;-) but this way will work, whereas taking shortcuts
would have a tendency to break.  Doing the make distclean also ensures
that the tarball will not contain any extraneous files, which seems like
a good idea.

I have just tested this procedure and determined that it takes less than
2 minutes on hub.org, which seems well within the realm of acceptability
for a nightly batch job.

So, a few questions for the list:

1. Does anyone object to removing these files from the CVS repository and
handling them as
above:src/backend/parser/gram.csrc/backend/parser/parse.hsrc/backend/parser/scan.csrc/interfaces/ecpg/preproc/preproc.csrc/interfaces/ecpg/preproc/preproc.hsrc/interfaces/ecpg/preproc/pgc.c

2. Should we also handle src/configure this way?  That would mean that
people who obtain the code straight from CVS would have to have autoconf
installed.  It's probably a good idea but I'm not certain.

3. src/pl/plpgsql/src/ also contains yacc and lex output files that are
checked into CVS.  We definitely should remove them from CVS, but should
we leave them to be generated by recipients of the distribution, or
should we handle them like the big grammar files?  I don't think they
are big enough to break anyone's yacc, but...

4. Currently, a recipient must have at least minimally working yacc/lex
capability anyway, because the bootstrap files in src/backend/bootstrap/
are not pre-built in the distribution.  If we used the same procedure
for the bootstrap and plpgsql files as for the bigger parsers, then it
would be possible to build Postgres without a local yacc or lex.  Is
this worth doing, or would it just bloat the distribution to no purpose?
As far as I know we have not gotten complaints about the need for
yacc/lex for these files; it's only that the parser and ecpg grammars
are too big for some vendor versions...
        regards, tom lane