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

Jeff King [off-list ref] writes:

On Sat, Feb 19, 2011 at 05:11:03AM -0600, Jonathan Nieder wrote:

quoted

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