Re: [PATCH] build: get rid of the notion of a git library

[Jeff King <peff@peff.net>]

On Mon, Jun 10, 2013 at 04:52:57PM -0500, Felipe Contreras wrote:

> On Mon, Jun 10, 2013 at 4:45 PM, Jeff King <peff@peff.net> wrote:
> 
> > That is what libgit.a _is_ now.  I do not mean to imply any additional
> > judgement on what it could be. But if the goal is to make libgit.a
> > "functions that programs outside git.git would want, and nothing else",
> > we may want to additionally split out a "libgit-internal.a" consisting
> > of code that is used by multiple externals in git, but which would not
> > be appropriate for clients to use.
> 
> That might make sense, but that still doesn't clarify what belongs in
> ./*.o, and what belongs in ./builtin/*.o. And right now that creates a
> mess where you have code shared between ./builtin/*.o that is defined
> in cache.h (overlay_tree_on_cache), and some in builtin.h
> (init_copy_notes_for_rewrite). And it's not clear what should be done
> when code in ./*.o needs to access functionality in ./builtin/*.o,
> specially if that code is only useful for git builtins, and nothing
> else.

My general impression of the goal of our current code organization is:

  1. builtin/*.c should each contain a single builtin command and its
     supporting static functions. Each file gets linked into git.o to
     make the "main" git executable.

  2. ./*.c is one of:

       a. Shared code usable by externals and builtins, which gets
          linked into libgit.a

       b. An external command itself, with its own main(). It gets
          linked against libgit.a.

  3. Functions in libgit.a should be defined in a header file specific
     to their module (e.g., refs.h). cache.h picks up the slack for
     things that are general, or too small to get their own header file,
     or otherwise don't group well.

I said it was a "goal", because I know that we do not follow that in
many places, so it is certainly easy to find counter-examples (and nor
do I think it cannot be changed; I am just trying to describe the
current rationale). Under that organization, there is no place for "code
that does not go into libgit.a, but is not a builtin command in itself".
There was never a need in the past, because libgit.a was a bit of a
dumping ground for linkable functions, and nobody cared that it had
everything and the kitchen sink.

If we want to start caring, then we probably need to create a separate
"kitchen sink"-like library, with the rule that things in libgit.a
cannot depend on it. In other words, a support library for Git's
commands, for the parts that are not appropriate to expose as part of a
library API.

-Peff