Jeff King <peff@xxxxxxxx> 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. -- 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