Thread (2 messages) 2 messages, 2 authors, 2024-02-29

Re: [PATCH v5 2/3] git-std-lib: introduce Git Standard Library

From: Linus Arver <hidden>
Date: 2024-02-29 18:27:05

Junio C Hamano [off-list ref] writes:
Phillip Wood [off-list ref] writes:
quoted
On 22/02/2024 17:50, Calvin Wan wrote:
quoted
quoted
+libgit.a, which is then linked against by common-main.o with other
+external dependencies and turned into the Git executable.
I found this description a bit confusing. As I understand it to build
git we link git.o against common-main.o, libgit.a, xdiff/lib.a,
reftable/libreftable.a and libpcre etc.
In addition, there is no single "the Git executable", simply because
not everything is builtin command.  The purpose of using libgit.a is
because we are too lazy to list and maintain all the internal
dependencies to link final executables like 'git' (which has all the
built-in command implementations) and 'git-remote-curl' (which is a
standalone program).  Instead of feeding exact list of object files
to "$(CC) -o git" command line, we throw everything into libgit.a
and let the linker pick what is needed.  To link "git", we may
include all builtin/*.o, git.o, common-main.o, libgit.a and the
external [*] library dependencies they have.  To link "git-daemon",
we may not link builtin/*.o and git.o and link daemon.o instead.

	Side note: here I am counting xdiff/lib.a as an external
	library as it is mostly a borrowed code.

In other words, libgit.a is not a true library in the sense that it
was designed to be _used_ as a library.  It was merely a detail of
how we implemented lazy dependency management in our build process,
which happend with 0a02ce72 (Clean up the Makefile a bit.,
2005-04-18) whose commit log message uses air-quotes around the word
"library".
Somehow I did not realize that this was going on. Thank you for pointing
this out!

It does make me wonder if we should stop being lazy and do the work that
the linker has been doing for us "for free" ourselves. IOW, stop linking
against a monolithic libgit.a. That way we would replace implicit
dependencies with explicit ones, which might help us understand which
things need what.

But maybe doing that is super painful, so, maybe it's not worth it. IDK.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help