Subject: Re: [PATCH 7/8] meson: compile compatibility sources separately

From: Phillip Wood <[email-masked]>
Date: Fri, 13 Mar 2026 10:33:20 +0000

On 12/03/2026 06:22, Patrick Steinhardt wrote:
> On Wed, Mar 11, 2026 at 02:56:24PM +0000, Phillip Wood wrote:
>>
>> I notice the reftable sources don't seem to include "git-compat-util.h", do
>> they need special handling here as well?
> 
> I don't see a strong reason to do so. The reason why we need to be
> careful with "compat/" is that we redefine a bunch of standard symbols
> there, and that requires us to play a couple of tricks with preprocessor
> macros (see e.g. "compat/fopen.c").
> 
> We don't do anything like that in the reftable library, and we already
> include "compat/posix.h". So in practice, it shouldn't have much of a
> consueqence if we start to include "git-compat-util.h" implicitly over
> there.

It does mean we're using different includes when compiling with 
pre-compiled headers compared to compiling without them though which 
means contributors using per-compiled headers could accidentally depend 
on functions that are not included when compiling without them. Wasn't 
the idea behind "compat/posix.h" to avoid including "git-compat-util.h" 
in the reftable code? The commit message for 75a044f748f 
(git-compat-util.h: split out POSIX-emulating bits, 2025-02-18) says

     This intermixing is a bit of a problem for the reftable library as
     we don't want to recreate the POSIX-like interface there. But
     neither do we want to pull in the Git-specific functionality, as it
     is otherwise quite easy to start depending on the Git codebase
     again.

We could precompile "compat/posix.h" for the code that does not want 
"git-compat-util.h"

Thanks

Phillip

> But if it ever does we can treat it the same as the compat library.
> 
> Patrick
>