Re: [RFC/PATCH 0/3] Thinning the git toplevel directory

[Drew Northup <drew.northup@maine.edu>]

On Thu, 2011-02-24 at 14:08 -0500, Jeff King wrote:
> On Thu, Feb 24, 2011 at 01:04:21PM -0500, Nicolas Pitre wrote:
> 
> > > It can be done as a separate patch, but it should all be done in the
> > > public branch (pu?) as atomically as possible (one merge from Junio's
> > > workspace). In other words, the public branch should never fail to build
> > > because of this work.
> > 
> > Who said this would fail to compile?
> > 
> > If you move bar.c into the foo directory, then in the existing Makefile 
> > you simply have to make a mechanical rename of bar.c to foo/bar.c.  
> > Restructuring the Makefile can be done separately from the file move 
> > without ever breaking the build (except for unintentional mistakes of 
> > course).
> 
> Exactly. Maybe it wasn't clear in the previous bits of the thread, but
> Makefile reorganization is a totally optional thing that can come on top
> of file movement if we choose. I just brought it up with file movement
> because having a bunch of subdirs is going to probably make us _want_ to
> do something with Makefiles.
> 
> In the interim it may not work to run make from the "cmds" subdirectory,
> but that is not a "fail to build" breakage. As long as we build via
> "make" from the root, then there is no regression. Adding extra make
> fluff on top of that is feature work, not a bug fix.
> 
> -Peff

I am glad to hear that is the case here. Pretty much everything else
I've ever worked on absolutely breaks if files are moved around and
Makefiles are not updated to suit.

-- 
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59