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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Sat, Feb 19, 2011 at 05:11:03AM -0600, Jonathan Nieder wrote:
>
>>  - merge builtins/ with commands/.  It never was clear to me why
>>    making a command builtin should require changing its filename.
>
> This may be a bit too radical, but maybe the Makefile should use this
> structure to save maintenance effort. In other words, is there any
> reason not to just have:
>
>   BUILTIN_SOURCES = $(wildcard builtin/*.c)
>   BUILTIN_OBJS = $(patsubst builtin/%.c, builtin/%.o, $(BUILTIN_SOURCES))
>
> and similar for LIB_OBJS and LIB_H?

The developers would have to be careful not to put a throw-away test
programs written in C (especially the ones that has its own "main()") in
builtin/ (or lib/) directories if we go that route.  This obviously cuts
both ways; it sometimes is handy.

> 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.

> 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.

Not that libgit.a in its current shape is very useful outside the context
of the git.git proper, though.