On Wed, 23 Feb 2011, Drew Northup wrote: > > On Wed, 2011-02-23 at 12:18 -0500, Nicolas Pitre wrote: > > On Wed, 23 Feb 2011, Junio C Hamano wrote: > > > > > Jeff King <peff@xxxxxxxx> writes: > > > > > > > On Tue, Feb 22, 2011 at 11:30:41AM -0800, Junio C Hamano wrote: > > > > > > > >> > Speaking of Makefiles, one downside to all of this directory > > > >> > segmentation is that you can't run "make" from the subdirectories. > > > >> > > > >> I had an impression that "make -C lib/" would be one of the goals, iow, > > > >> when we split the directory structure, the next step would be to split the > > > >> top-level Makefile so that each directory is covered by its own Makefile, > > > >> just like Documentation/ is already usable that way. > > > > > > > > Ugh. I am not thrilled at the prospect of more recursive make. > > > > > > Likewise. Notice that I have consistently been unthrilled when people > > > started talking about splitting the source code tree? > > > > Maybe that would be wiser to consider an initial set of patches as those > > which were proposed to only do the simple file move first, then wait for > > the dust to settle before doing more changes. Doing too much in one go > > is inevitably going to bounce against the human tendency to resist any > > kind of change, good or bad. > > > Nicolas > > Nicolas, > They are doing it this way because change is not the objective. A > possible better way of managing the codebase is. Incidentally I know that (guess whom this proposal came from initially). ;-) > Perhaps it isn't the > right way to go--and we won't know that until we've explored all of the > side-effects, advantages, disadvantages, etc. > > Besides, if we move anything around into a deeper directory structure we > are inevitably going to have to deal with more recursive make problems. > We can't just commit to master a tree that has everything moved about > and get around to dealing with the Makefiles later. The initial set of patches simply moved files into subdirectories and made the corresponding renames within the Makefile. Reorganizing the Makefile into a better Makefile or sub-makefiles can be done subsequently. That's my point. Nicolas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html