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

[Felipe Contreras <felipe.contreras@gmail.com>]

On Mon, Jun 10, 2013 at 7:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> *1* ... which is a very reasonable thing to do.  But moving
>>>     sequencer.o to builtin/sequencer.o is *not* the way to do this.
>>
>> By now we all know what is the *CURRENT* way to do this; in other
>> words, the status quo, which is BTW all messed up, because builtin/*.o
>> objects depend on each other already.
>
> builtin/*.o are allowed to depend on each other.  They are by
> definition builtins, meant to be linked into a single binary.

That's not what John Keeping said[1]. I'm going to assume he was
wrong, but I don't think that's relevant for my point.

Either way, the meaning of builtin/ should probably be explained somewhere.

>> We are discussing the way it *SHOULD* be. Why aren't you leaning on that?
>
> And I do not see the reason why builtin/*.o should not depend on
> each other.  It is not messed up at all.  They are meant to be
> linked into a single binary---that is what being "built-in" is.
>
> A good way forward, the way it *SHOULD* be, is to slim the builtin/*.o
> by moving parts that do not have to be in the single "git" binary
> but are also usable in standalone binaries out of them.
>
> And that is what I just suggested.

But init_copy_notes_for_rewrite() can *not* be used by anything other
than git builtins. Standalone binaries will never use such a function,
therefore it doesn't belong in libgit.a. Another example is
alias_lookup(). They belong in builtin/lib.a.

[1] http://article.gmane.org/gmane.comp.version-control.git/227017

-- 
Felipe Contreras