Re: [HACKERS] Removing derived files from CVS

geek+@cmu.edu writes:
> Then <scrappy@hub.org> spoke up and said:
>> Agreed here too...someone at one point mentioned that there might be a
>> way, inside of CVS, to have it auto-generate these files as its being
>> checked out (ie. if file is configure.in, run autoconf)...

> From my reading, it looks like the easiest thing to do is set up
> commit rules such that committing gram.y automatically generates
> gram.c.

I thought about that, but it only solves *one* of the problems we've
run into: developers forgetting to commit a derived file when they
commit the master.  We'd still have these problems: * excessive CVS traffic for the derived files (check the
version-to-versiondiffs for gram.c or configure to see what I'm   talking about: a small change to the master often
generateshuge   diffs on the derived).  That costs everyone who downloads from   CVS.  It's probably faster to generate
gram.cor configure locally   than to pull these diffs from CVS. * unreliable timestamps after a "cvs update": the
derivedmay or may   not look newer than the master, depending on what order cvs updates   them in.  So you may end up
rebuildinglocally anyway. * unreliable timestamps in tarball drops: same as above.
 

If we could run a program during check *out* not check in then we might
have something, but I see no facility for that in cvs.  There'd be
severe portability problems anyway (how do you know what incantation to
mutter to run yacc/bison, when you haven't done configure yet?).

So I think removing the deriveds from CVS altogether is a much better
answer.
        regards, tom lane