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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 10, 2013, 23:05 UTC
Message-ID: <7vk3m1efda.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130610220627.GB28345@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

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

Show 21 quoted lines

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