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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 10, 2013, 23:41 UTC
Message-ID: <7v8v2hedou.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vk3m1efda.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 25 quoted lines

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

For the particular case of trying to make sequencer.o, which does not currently have dependencies on builtin/*.o, depend on something that is in builtin/notes.o, the link phase of standalone that wants anything from revision.o (which is pretty much everything ;-) goes like this:

        upload-pack.c   wants handle_revision_opt etc.
        revision.c      provides handle_revision_opt
                        wants name_decoration etc.
        log-tree.c      provides name_decoration
                        wants append_signoff
        sequencer.c     provides append_signoff

So sequencer.o _is_ meant to be usable from standalone and belongs to libgit.a

If sequencer.o wants to call init_copy_notes_for_rewrite() and its friends [*1*] that are currently in builtin/notes.o, first the called function(s) should be moved outside builtin/notes.o to notes.o or somewhere more library-ish place to be included in libgit.a, which is meant to be usable from standalone.

[Footnote]

*1* ... which is a very reasonable thing to do.  But moving
    sequencer.o to builtin/sequencer.o is *not* the way to do this.