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

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Apr 9, 2024, 09:40 UTC
Message-ID: <5663500c-ea40-45a6-bb7d-c906aee4350c@gmail.com>
In-Reply-To: <xmqqr0ff8rwo.fsf@gitster.g>

On 08/04/2024 22:29, Junio C Hamano wrote:

Show 12 quoted lines

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