git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Vincent van Ravesteijn <vfr@lyx.org>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
	John Keeping <john@keeping.me.uk>,
	Ramkumar Ramachandra <artagnon@gmail.com>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Duy Nguyen <pclouds@gmail.com>
Subject: Re: [PATCH] build: get rid of the notion of a git library
Date: Mon, 10 Jun 2013 17:45:04 -0400	[thread overview]
Message-ID: <20130610214504.GG13333@sigill.intra.peff.net> (raw)
In-Reply-To: <51B4BBB7.8060807@lyx.org>

On Sun, Jun 09, 2013 at 07:30:31PM +0200, Vincent van Ravesteijn wrote:

> I think that libgit.a should contain all code to be able to carry out
> all functions of git. The stuff in builtin/ is just a command-line
> user interface. Whether or not sequencer should be in builtin depends
> on whether the sequencer is only part of this command-line user
> interface.

One code organization issue I have not seen mentioned is that there is
more CLI than what is in builtin, and libgit.a does more than simply
provide code for the sources in builtin/. There are also external
commands shipped in git.git that are not linked against git.c or the
other builtins.

Once upon a time, all commands were that way, and that was the origin of
libgit.a: the set of common code used by all of the C commands in
git.git. Over time, those commands became builtins (mostly to keep the
size of the libexec dir down). These days there are only a handful of
external commands left, mostly ones that have startup time overhead from
the dynamic loader (e.g., remote-curl, http-push, imap-send).

That is what libgit.a _is_ now.  I do not mean to imply any additional
judgement on what it could be. But if the goal is to make libgit.a
"functions that programs outside git.git would want, and nothing else",
we may want to additionally split out a "libgit-internal.a" consisting
of code that is used by multiple externals in git, but which would not
be appropriate for clients to use.

For example, I think most of "http.c" is in that boat, as it is full of
wrappers for curl code that are of enough quality to reuse within git,
but a little too half-baked to be part of a stable API.

We can always link directly against http.o, too, of course. The point of
putting the files into a static library is that it makes the link
faster, and if there are only a handful of such links, it may not be
worth the effort.

-Peff

  parent reply	other threads:[~2013-06-10 21:45 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-08 17:29 [PATCH] build: get rid of the notion of a git library Felipe Contreras
2013-06-08 18:02 ` Ramkumar Ramachandra
2013-06-08 18:22   ` Felipe Contreras
2013-06-09 14:56     ` Ramkumar Ramachandra
2013-06-09 15:12       ` John Keeping
2013-06-09 15:40         ` Felipe Contreras
2013-06-09 16:02           ` John Keeping
2013-06-09 16:22             ` Felipe Contreras
2013-06-09 16:42               ` John Keeping
2013-06-09 17:03                 ` Ramkumar Ramachandra
2013-06-09 17:12                   ` Ramkumar Ramachandra
2013-06-09 17:13                   ` Felipe Contreras
2013-06-09 17:32                     ` John Keeping
2013-06-09 17:45                       ` Felipe Contreras
2013-06-09 16:36             ` Ramkumar Ramachandra
2013-06-09 17:30           ` Vincent van Ravesteijn
2013-06-09 17:35             ` Felipe Contreras
2013-06-10 21:45             ` Jeff King [this message]
2013-06-10 21:52               ` Felipe Contreras
2013-06-10 22:06                 ` Jeff King
2013-06-10 22:22                   ` Felipe Contreras
2013-06-10 23:05                   ` Junio C Hamano
2013-06-10 23:41                     ` Junio C Hamano
2013-06-10 23:51                       ` Felipe Contreras
2013-06-11  0:04                         ` Junio C Hamano
2013-06-11  1:53                           ` Junio C Hamano
2013-06-11  4:15                             ` Felipe Contreras
2013-06-11 17:33                               ` Junio C Hamano
2013-06-11 17:41                                 ` Felipe Contreras
2013-06-11 17:58                                   ` Junio C Hamano
2013-06-11 18:06                                     ` Felipe Contreras
2013-06-11 18:14                                       ` Linus Torvalds
2013-06-11 19:15                                         ` Felipe Contreras
2013-06-11 19:59                                         ` Junio C Hamano
2013-06-11 20:12                                           ` Felipe Contreras
2013-06-12  0:12                                           ` [PATCH 0/3] Refactor useful notes functions into notes-utils.[ch] Johan Herland
2013-06-12  0:12                                             ` [PATCH 1/3] finish_copy_notes_for_rewrite(): Let caller provide commit message Johan Herland
2013-06-12 17:27                                               ` Junio C Hamano
2013-06-12  0:13                                             ` [PATCH 2/3] Move copy_note_for_rewrite + friends from builtin/notes.c to notes-utils.c Johan Herland
2013-06-12  0:32                                               ` Felipe Contreras
2013-06-12  7:10                                                 ` Johan Herland
2013-06-12 18:28                                                   ` Felipe Contreras
2013-06-12 19:14                                                     ` Johan Herland
2013-06-12 19:18                                                       ` Felipe Contreras
2013-06-13  6:45                                                     ` Andreas Krey
2013-06-13 13:13                                                       ` Felipe Contreras
2013-06-12 20:02                                               ` Junio C Hamano
2013-06-12  0:13                                             ` [PATCH 3/3] Move create_notes_commit() from notes-merge.c into notes-utils.c Johan Herland
2013-06-12 20:02                                             ` [PATCH 0/3] Refactor useful notes functions into notes-utils.[ch] Junio C Hamano
2013-06-12 20:11                                               ` Felipe Contreras
2013-06-13 17:24                                                 ` Junio C Hamano
2013-06-13 18:16                                                   ` Felipe Contreras
2013-06-13 18:50                                                     ` Felipe Contreras
2013-06-11 18:17                                       ` [PATCH] build: get rid of the notion of a git library Junio C Hamano
2013-06-11 19:01                                         ` Felipe Contreras
2013-06-11 19:24                                           ` Junio C Hamano
2013-06-11 19:49                                             ` Felipe Contreras
2013-06-11  4:04                           ` Felipe Contreras
2013-06-09 15:41       ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130610214504.GG13333@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=artagnon@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=john@keeping.me.uk \
    --cc=jrnieder@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=vfr@lyx.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).