From: Calvin Wan <calvinwan@google.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
Junio C Hamano <gitster@pobox.com>,
rsbecker@nexbridge.com, Calvin Wan <calvinwan@google.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [RFD] Libification proposal: separate internal and external interfaces
Date: Tue, 9 Apr 2024 10:26:26 -0700 [thread overview]
Message-ID: <CAFySSZBMGx_Uvak7WEurwWk00=6o3SciJnN9zAGbvTTbBk=Axg@mail.gmail.com> (raw)
In-Reply-To: <ZhSNPTiaPbfekOrJ@tapette.crustytoothpaste.net>
On Mon, Apr 8, 2024 at 5:35 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On 2024-04-08 at 21:29:27, Junio C Hamano wrote:
> > I thought one of the yardstick to gauge the success of this
> > "libification" effort, if not the purpose of this effort, is to
> > allow Git to be its first client.
> >
> > I am not sure how it would supposed to work. Unless you are giving
> > parallel implementations of "main Git binaries", one with the native
> > code and the other replaced the native code with thin wrappers
> > around the library calls, that is.
>
> I think the plan as proposed in the original file was to have an
> internal and external library and to have the binaries use the internal
> library. However, perhaps I misunderstood the proposal, in which case
> clarification on the part of the proposers would be helpful.
We are still working on the specifics of how we would accomplish this
(part of the reason this is marked RFD). Thin wrappers make sense for
functions that should be slightly altered for external users (e.g.
anything with a die() should have their error codes bubbled up). On
the other hand, there are functions that are already suitable for
external users out of the box, so we could just provide a separate
header for those. But those functions may still need to be renamed
anyways to avoid symbol collision, so thin wrappers may end up being
the default going forward.
next prev parent reply other threads:[~2024-04-09 17:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 14:18 [RFD] Libification proposal: separate internal and external interfaces Calvin Wan
2024-04-07 21:33 ` brian m. carlson
2024-04-07 21:48 ` rsbecker
2024-04-08 1:09 ` brian m. carlson
2024-04-08 11:07 ` rsbecker
2024-04-08 21:29 ` Junio C Hamano
2024-04-09 0:35 ` brian m. carlson
2024-04-09 17:26 ` Calvin Wan [this message]
2024-04-09 9:40 ` Phillip Wood
2024-04-09 17:30 ` Calvin Wan
2024-04-22 16:26 ` Calvin Wan
2024-04-22 20:28 ` Junio C Hamano
2024-04-23 9:57 ` phillip.wood123
2024-05-09 1:00 ` Kyle Lippincott
2024-05-10 9:52 ` Phillip Wood
2024-05-10 21:35 ` Kyle Lippincott
2024-05-09 19:45 ` Kyle Lippincott
2024-05-09 20:14 ` Junio C Hamano
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='CAFySSZBMGx_Uvak7WEurwWk00=6o3SciJnN9zAGbvTTbBk=Axg@mail.gmail.com' \
--to=calvinwan@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=rsbecker@nexbridge.com \
--cc=sandals@crustytoothpaste.net \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).