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:

quoted

quoted

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