From: Felipe Contreras Date: Tue, 11 Jun 2013 04:04:52 GMT Subject: Re: [PATCH] build: get rid of the notion of a git library Message-ID: In-Reply-To: <7v4nd5ecmy.fsf@alter.siamese.dyndns.org> On Mon, Jun 10, 2013 at 7:04 PM, Junio C Hamano wrote: > Felipe Contreras 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