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

[Jeff King <peff@peff.net>]

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