RFC: Moving C to its own directory

David O'Brien obrien@FreeBSD.org
Mon Jun 2 19:03:00 GMT 2003

On Mon, Jun 02, 2003 at 11:06:28AM -0700, cgd@broadcom.com wrote:
> 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.

It's not elitism.  You asked if I was 100% sure, and in thinking about,
there is always a possbility that autoconf will discover more than one
intended.  What's your solution to the issue then??

> This has nothing to do with "deterministic Makefiles".

For the OS, it hasn't been a problem.  You keep missing that FreeBSD has
been doing this for ages.  If an application has its own header named
identical to one in /usr/include, then all bets are off.

> 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*?

One typically isn't doing a full checkout using -D to build the product
-- that's what tags (as in co -r <TAG>) are for.  The most typical use of
-D is in "cvs diff -D <list of files>" and you know the particular file
you want to see the differences in date in.

Please end the thread now.  It works for FreeBSD, as tested by many years
and tons of users.  Don't FUD that it doesn't work at all.  If you don't
feel it will work for GCC, then fine.  I beg to differ, but neither of us
are on the GCC S.C.

-- David  (obrien@FreeBSD.org)

More information about the Gcc mailing list