Re: [RFD] Libification proposal: separate internal and external interfaces

From: Calvin Wan <calvinwan@google.com>
Date: Apr 9, 2024, 17:26 UTC
Message-ID: <CAFySSZBMGx_Uvak7WEurwWk00=6o3SciJnN9zAGbvTTbBk=Axg@mail.gmail.com>
In-Reply-To: <ZhSNPTiaPbfekOrJ@tapette.crustytoothpaste.net>

On Mon, Apr 8, 2024 at 5:35 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 15 quoted lines

>
> 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.