RFC: Moving C to its own directory

[cgd@broadcom.com]

At Mon, 2 Jun 2003 10:56:50 -0700, David O'Brien wrote:
> > Uh, "won't" by luck, or "can't."  Probably the former.  (There can by
> > great joy if a new header with a oft-used name pops up in an old
> > source tree.)
> 
> Can't in BSD due to our deterministic Makefiles, etc.. -- this hasn't bit
> FreeBSD in the many years we've done this type of repo copy.  There is a
> possbility that GCC with its use of autoconf & friends, that something
> could get confused.

"Bzzt!"  Nice bit of BSD elitism.  Too bad it completely misses the
point.

Think about what happens if you move a header.  All of a sudden, an
old date-based checkout may check out this header in a location where
no header was before.  If that location happens to be in some
program-build's include path... you may lose badly.

This has nothing to do with "deterministic Makefiles".


> > (I've had people suggest to me, in the past, "well, then, why not
> > change all of the dates on the revision."  Talk about "just don't get
> > it...")
> 
> Changing the dates in the ,v files would be the Wrong Thing to do.

On the other hand, by copying the ,v file and *not* changing the
dates, you are effectively changing the historical state of the
repository.

All of a sudden, on "June 5, 2002" there might be a new file where
there wasn't one before.

That's somehow *better*?



cgd