Re: [PATCH 8/8] meson: precompile "git-compat-util.h"

[Patrick Steinhardt <ps@pks.im>]

On Wed, Mar 11, 2026 at 02:32:36PM +0000, Phillip Wood wrote:
> On 10/03/2026 17:52, Patrick Steinhardt wrote:
> > Every compilation unit in Git is expected to include "git-compat-util.h"
> > first, either directly or indirectly via "builtin.h". This header papers
> > over differences between platforms so that we can expect the typical
> > POSIX functions to exist. Furthermore, it provides functionality that we
> > end up using everywhere.
> > 
> > This header is thus quite heavy as a consequence. Preprocessing it as a
> > standalone unit via `clang -E git-compat-util.h` yields over 23,000
> > lines of code overall. Naturally, it takes quite some time to compile
> > all of this.
> > 
> > Luckily, this is exactly the kind of use case that precompiled headers
> > aim to solve: instead of recompiling it every single time, we compile it
> > once and then link the result into the executable. If include guards are
> > set up properly it means that the file won't need to be reprocessed.
> > 
> > Set up such a precompiled header for "git-compat-util.h" and wire it up
> > via Meson. This leads to a significant speedup when performing full
> > builds:
> > 
> >    Benchmark 1: ninja (rev = HEAD~)
> >    Time (mean ± σ):     14.467 s ±  0.126 s    [User: 248.133 s, System: 31.298 s]
> >    Range (min … max):   14.195 s … 14.633 s    10 runs
> > 
> >    Benchmark 2: ninja (rev = HEAD)
> >      Time (mean ± σ):     10.307 s ±  0.111 s    [User: 173.290 s, System: 23.998 s]
> >      Range (min … max):   10.030 s … 10.433 s    10 runs
> > 
> >    Summary
> >      ninja (rev = HEAD) ran
> >        1.40 ± 0.02 times faster than ninja (rev = HEAD~)
> 
> This is a nice speedup for a full build. I'm not sure about dumping the
> precompiled header in tools/ though, it seems like an odd location for a
> header file. It is a requirement of meson that the source for the
> precompiled header lives in a separate directory to the rest of the sources
> but it might be better to adopt the suggestion in the documentation of a
> "pch" (or maybe "precompiled"?) directory rather than mixing it in with our
> build scripts.

Yeah, it's a bit on the odd side. The reason I decided on "tools/"
though is that it now contains our build infra and developer tooling, so
it's an okayish fit. And I didn't feel like creating a directory for a
single file, only.

Patrick