Re: [HACKERS] Removing derived files from CVS

geek+(at)cmu(dot)edu writes:
> Then <scrappy(at)hub(dot)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-version diffs for gram.c or configure to see what I'm
talking about: a small change to the master often generates huge
diffs on the derived). That costs everyone who downloads from
CVS. It's probably faster to generate gram.c or configure locally
than to pull these diffs from CVS.
* unreliable timestamps after a "cvs update": the derived may or may
not look newer than the master, depending on what order cvs updates
them in. So you may end up rebuilding locally 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