On Tue, Feb 22, 2011 at 11:30:41AM -0800, Junio C Hamano wrote: > > It is one less thing to need to do when writing new code, and one less > > thing to have silly textual conflicts on. It probably doesn't matter > > that much, though; we don't actually add new files or commands all that > > often. > > Yeah, you would need to add an entry to the builtin command list yourself > anyway, until we also autogenerate it, which I doubt will ever happen nor > is necessarily a good idea. You also have to add the declaration to builtin.h. It is kind of a hassle to have to add it in three places (Makefile, command list, and declaration) in addition to the actual code. But again, it's not like we do this that often. > > 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. As it is now, we have already dealt with bugs from the little bit of recursion there is (e.g., propagating information between Makefiles) and weird heisenbugs (I still occasionally get build failures on recursing into the perl subdir during a parallel make). And then of course it's easy to misuse; running "make" in t/ is not necessarily testing the latest version. In my experience recursive make always comes with this sort of flakiness. Right now the actual C build process is entirely in the top-level Makefile. I really like that I can trust it to handle dependencies correctly, because it means I can bisect without resorting to "make clean" for each step. -Peff -- 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