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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 22, 2011, 19:30 UTC
Message-ID: <7v4o7vdfz2.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110222155637.GC27178@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 13 quoted lines

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