From: Phillip Wood <phillip.wood123@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
"brian m. carlson" <sandals@crustytoothpaste.net>
Cc: 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:40:17 +0100 [thread overview]
Message-ID: <5663500c-ea40-45a6-bb7d-c906aee4350c@gmail.com> (raw)
In-Reply-To: <xmqqr0ff8rwo.fsf@gitster.g>
On 08/04/2024 22:29, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
>> As mentioned in the original proposal, we don't have to support all
>> platforms in the libified code. The main Git binaries will continue to
>> function and be supported, but the new libified code will rely on newer
>> features. You will still be able to have all the Git binaries and
>> functionality, but if you want the new shared library to compile
>> against, you'll have to furnish a newer compiler.
>
> 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.
Indeed, the last set of patches allow git to be built with the same
library that external programs can use which I thought was very welcome.
This proposal seems to be backing away from that.
We could have a single version of the library with a set of external
headers that export a limited set of functions in a gitlib_ namespace
and are wrapped internally with definitions like
static inline int foo(int x)
{
return libgit_foo(x);
}
but that still leaves the problem of symbol visibility for the symbols
that are consumed internally but not exposed in the external headers.
Best Wishes
Phillip
next prev parent reply other threads:[~2024-04-09 9:40 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
2024-04-09 9:40 ` Phillip Wood [this message]
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=5663500c-ea40-45a6-bb7d-c906aee4350c@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=calvinwan@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=phillip.wood@dunelm.org.uk \
--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).