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

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

Jeff King <peff@peff.net> writes:

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

Correct; that is what we aimed for when we made builtin-*.c (later
moved to builtin/*.c).  Some builtin/*.c files can contain more than
one cmd_foo implementations, so "single" is not a solid rule, and it
does not have to be, because all of them are expected to be linked
into the main binary together with git.c to be called from main().

And as you hinted, if some global data or functions in it turns out
to be useful for standalone binaries, their definitions must migrate
out of buitlin/*.c to ./*.c files, because standalone binaries with
their own main() definition cannot be linked with builtin/*.o, the
latter of which requires to be linked with git.o with its own main().

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

The rationale behind libgit.a was so that make targets for the
standalone binaries (note: all of them were standalone in the
beginning) do not have to list *.o files that each of them needs to
be linked with.  It was primary done as a convenient way to have the
linker figure out the dependency and link only what was needed.