Hi,

this patch series contains a couple of improvements for Meson:

  - Clean build times are sped up, going from ~6.8 seconds to ~5.0
    seconds for a full build.

  - A test issue is fixed that causes shell completion tests to fail
    because the scripts are not properly updated.

  - Our subproject wrappers are updated to current versions.

  - A fix for GitLab's msvc-meson jobs that are broken right now due to
    a change in our runner images. See [1] for the now-working
    msvc-meson jobs. Note though that the MinGW-based jobs are still
    broken, but Dscho has been sending fixes for that already.

Thanks!

Patrick

---
Patrick Steinhardt (7):
      meson: avoid recompiling HTTP sources several times
      meson: don't recompile git-remote-http(1) multiple times for tests
      meson: use precompiled headers for our test-helper
      meson: use precompiled headers for unit tests
      meson: fix outdated completion helpers
      meson: update wrappers
      gitlab-ci: fix hanging MSVC jobs

 ci/install-dependencies.ps1    |  8 ++++++++
 contrib/completion/meson.build | 38 +++++++++++++++-----------------------
 meson.build                    | 16 ++++++++++------
 subprojects/curl.wrap          | 19 ++++++++++---------
 subprojects/expat.wrap         | 21 +++++++++++----------
 subprojects/openssl.wrap       | 23 +++++++++++------------
 subprojects/pcre2.wrap         | 24 +++++++++++-------------
 subprojects/zlib.wrap          | 21 +++++++++++----------
 t/helper/meson.build           |  1 +
 t/meson.build                  | 10 ++++++++--
 10 files changed, 96 insertions(+), 85 deletions(-)

--- base-commit: 0f8e75abebff0877cae681a3d5ff31ac47f54220 change-id: 20260924-pks-meson-improvements-b7ed9a48ed4e

We only link curl into a subset of our subcommands. Consequently, as both "http.c" and "http-walker.c" depend on curl, we don't compile these into "libgit.a" but instead only link those into the commands that depend on curl.

In Meson, we wire these dependencies into the target executables by using the `sources:` keyword. But this has the consequence that we're recompiling those multiple several times, once for every different command they are linked into. In fact, each of these sources is compiled seven times, which of course has an impact on compilation speed.

Fix this issue by instead linking these into a static library so that they only need to be compiled once. This gives us an almost 10% speedup in a clean build:

  Benchmark 1: meson compile (version = HEAD~)
    Time (mean ± σ):      6.781 s ±  0.052 s    [User: 100.775 s, System: 22.954 s]
    Range (min … max):    6.709 s …  6.867 s    10 runs

  Benchmark 2: meson compile (version = HEAD)
    Time (mean ± σ):      6.274 s ±  0.021 s    [User: 91.882 s, System: 22.092 s]
    Range (min … max):    6.242 s …  6.306 s    10 runs

  Summary
    meson compile (version = HEAD) ran
      1.08 ± 0.01 times faster than meson compile (version = HEAD~)

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 meson.build | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

When running our tests, we expect git-remote-http(1) and a couple of other binaries to be available to the test suite. In our Makefile, we achieve this by simply hardlinking the file into place in our source directory. We cannot easily do that in Meson though because there is no available command to create such a hardlink.

We could of course create a custom target that uses a script for that, but that feels quite awkward. Instead, we build the executable several times, which is of course less efficient. Even worse though, similar as in the preceding commit, we're building "remote-curl.c" once for each of these targets, which makes this even more expensive.

Fix this by reusing the already-compiled objects from git-remote-http(1) so that we only have to perform the linking step several times. This leads to a mild speedup:

  Benchmark 1: meson compile (version = HEAD~)
    Time (mean ± σ):      6.250 s ±  0.040 s    [User: 90.881 s, System: 21.912 s]
    Range (min … max):    6.197 s …  6.344 s    10 runs

  Benchmark 2: meson compile (version = HEAD)
    Time (mean ± σ):      6.218 s ±  0.029 s    [User: 90.633 s, System: 22.022 s]
    Range (min … max):    6.166 s …  6.262 s    10 runs

  Summary
    meson compile (version = HEAD) ran
      1.01 ± 0.01 times faster than meson compile (version = HEAD~)

Honestly, a 1% speedup isn't really worth it. But the change makes sense anyway, as we're doing the same when we build git-receive-pack(1) et al. So while the speed improvement is negligible, it brings more consistency into our build instructions.

For the record: I also had a look at using a custom target that hardlinks the files into place. But the improvement it had on our build times were not that mindblowing either, saving roundabout ~100ms in wall time. So sticking with the status quo felt like the better solution as it is native to Meson.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 meson.build | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

In 671df48df8 (meson: precompile "git-compat-util.h", 2026-03-19) we have introduced support for precompiled headers into Meson. At that time though we only converted "libgit.a" to make use of those.

Nowadays though, our test-helper also consists of a bunch of code files, and all of these include "git-compat-util.h" via "test-tool.h" as the first header. So they're a natural target to also use precompiled headers.

Adapt the test-tool executable to make use of them, which results in a surprisingly large speedup for clean builds:

  Benchmark 1: meson compile (version = HEAD~)
    Time (mean ± σ):      6.363 s ±  0.033 s    [User: 92.858 s, System: 22.500 s]
    Range (min … max):    6.311 s …  6.418 s    10 runs

  Benchmark 2: meson compile (version = HEAD)
    Time (mean ± σ):      5.327 s ±  0.021 s    [User: 75.135 s, System: 20.373 s]
    Range (min … max):    5.299 s …  5.362 s    10 runs

  Summary
    meson compile (version = HEAD) ran
      1.19 ± 0.01 times faster than meson compile (version = HEAD~)

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 t/helper/meson.build | 1 +
 1 file changed, 1 insertion(+)

Same as in the preceding commit, our unit tests don't use precompiled headers yet. In this case though it's a tiny bit more complicated to make use of them, as we do not want to include "git-compat-util.h" for "clar.c", as that code file is a third-party implementation that is independent of the Git codebase.

But there's an easy workaround: instead of linking that file into the executable directly, we can easily adapt it to be built into a static library first. Like that we can trivially have separate build flags for that one file.

Do so and adapt the remaining sources to use precompiled headers. This results in a small but noticeable build speedup:

  Benchmark 1: meson compile (version = HEAD~)
    Time (mean ± σ):      5.343 s ±  0.019 s    [User: 75.478 s, System: 20.382 s]
    Range (min … max):    5.308 s …  5.376 s    10 runs

  Benchmark 2: meson compile (version = HEAD)
    Time (mean ± σ):      5.077 s ±  0.017 s    [User: 70.557 s, System: 19.999 s]
    Range (min … max):    5.047 s …  5.103 s    10 runs

  Summary
    meson compile (version = HEAD) ran
      1.05 ± 0.01 times faster than meson compile (version = HEAD~)

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 t/meson.build | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

When using Meson 1.3.0 or newer, we use `fs.copyfile()` to put our completion helpers into the expected location so that our test suite can find these scripts. Naturally, we thus also add these scripts to our test dependencies so that we know to build them before executing tests. But there's an issue here: we include the "contrib/completion" subdir after we have already wired up our tests, so any dependencies we add here are not being honored correctly. This has the consequence that we don't know to copy around these completion helpers when we execute tests, and one has to manually `meson compile` beforehand.

The interesting part here is that the code path we use with older versions of Meson don't suffer from the same problem as they use `configure_file()`, and that function will always run whenever the source file changes. It's conceptually correct to use `fs.copyfile()` instead, but given that it's mostly creating problems for us it does not really seem sensible to continue using it.

Adapt the build instructions to unconditionally use `configure_file()` to fix this issue.

A better fix would arguably be to promote our shell completion helpers out of "contrib/" -- they are an important part of Git nowadays, and these helpers get installed on lots of platforms. If so, we could also fix the order of subdir includes so that test dependencies are properly honored. But that feels like a bigger change, so that's left for a future patch series.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 contrib/completion/meson.build | 38 +++++++++++++++-----------------------
 1 file changed, 15 insertions(+), 23 deletions(-)

Our subproject wrappers are used on platforms that do not have the respective dependencies available. Most importantly, this can be used on Windows to have an almost-dependency-free build of Git.

Update these wrappers via `meson wrap update`.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 subprojects/curl.wrap    | 19 ++++++++++---------
 subprojects/expat.wrap   | 21 +++++++++++----------
 subprojects/openssl.wrap | 23 +++++++++++------------
 subprojects/pcre2.wrap   | 24 +++++++++++-------------
 subprojects/zlib.wrap    | 21 +++++++++++----------
 5 files changed, 54 insertions(+), 54 deletions(-)

Starting with GitLab Runner 19.x, the runner executes `git credential reject` in its cleanup stage. This has bad interactions with our build environment because we install our own version of PortableGit, and the runner picks up that version of Git. The consequence is that we invoke PortableGit's default credential manager, which is Git Credential Manager for Windows. GCM then tries to use Windows Credential Manager, but it cannot and thus the job hangs in its cleanup phase forever.

Fix this hang by unsetting the credential helper after installing PortableGit. This means that `git credential reject` becomes a no-op, and thus the cleanup succeeds again.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/install-dependencies.ps1 | 8 ++++++++
 1 file changed, 8 insertions(+)

Patrick Steinhardt <ps@pks.im> writes:

So there are 7 locations which mark `libgit_curl` as a dependency, earlier this would have recompiled the two sources here each time for each of the 7 locations.

Now we build a static library and declare the dependency to be linked with the static library. Looks good.

Patrick Steinhardt <ps@pks.im> writes:

Seems like a straightforward win. Nice to see.

Patrick Steinhardt <ps@pks.im> writes:

Okay, I've verified this locally and it matches.

[snip]

FPatrick Steinhardt <ps@pks.im> writes:

Nice, for reference the runner team also has a fix on their end to disable credential.helper on their side too [1].

[1]: gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/7470

Patrick Steinhardt <ps@pks.im> writes:

The patches look good. The speedup is much appreciated.

On Wed, Sep 30, 2026 at 05:26:17AM -0700, Karthik Nayak wrote:

Yeah, I've seen that already, but thanks for pointing this out to the mailing list. I guess it makes sense to apply this patch anyway so that we don't have this issue anymore with the current-broken version of the runner.

Thanks!

Patrick

On 9/24/26 19:39, Patrick Steinhardt wrote:

s/multiple several/multiple/

Rest of the patch look good to me.

On 9/24/26 19:39, Patrick Steinhardt wrote:

Compiling this separately as a static library is cool but now clar.c does not get the libgit_c_args it was getting through the dependencies of the unit-tests executable. Is this something that we need to correct?

On 9/24/26 19:39, Patrick Steinhardt wrote:

 > [ snip ]

 > [ snip ]

 > diff --git a/subprojects/openssl.wrap b/subprojects/openssl.wrap> 
index 873d55106e..e775bb104f 100644

 > [ snip ]> -wrapdb_version = 3.0.8-3
 > [ snip ]> +wrapdb_version = 3.0.10-1

We are using the latest versions from the wrap DB for the above but the versions available via wrap DB itself appears quite old. For instance,

- curl 8.12.1 was released on Feb/2025. The latest available
   is 8.22.0 (released Sep/2026)

- OpenSSL 3.0.10 was released on Aug/2023. The latest available are
   3.0.22 (released Aug/2026) and 4.0.1 (released Jun/2026).

Is this version gap something we need to document / think about?

On 9/24/26 19:39, Patrick Steinhardt wrote:

The only other sub-directory that does not yet include the precompiled header is 'compat' and leaving it out seems to be the right choice. Including it would trigger recursive compilation issues as git-compat-util.h itself depends on compat/posix.h. Trying to reshuffle the build code to fix this seems not worthwhile given the amount of code is a bit less there.

A few other similar targets that were not touched by this series are non-worthwhile such as 'common-main', 'git-curl' etc.

Apart from the few other comments in other threads, this series looks good to me.

On Mon, Oct 05, 2026 at 03:04:16PM +0530, Kaartic Sivaraam wrote:

That's true. But I wonder whether that is maybe even an improvement. After all, the libgit_c_args contain stuff that is relevant to Git, only. And given that "clar.c" is a vendored dependency, it does not really make sense to expose e.g. "-DWITH_BREAKING_CHANGES".

Now there are a small handful of arguments that _might_ be relevant, but these are only -W-style warning flags. I don't think we really care about those either, as again, this is a vendored dependency.

So overall I think that this is fine, but I should've maybe called this out in the commit mesage.

Patrick

On Mon, Oct 05, 2026 at 03:12:34PM +0530, Kaartic Sivaraam wrote:

Maybe, but I think the proper way to fix this would be to update the wrap DB if we really care about this. For now we only use this so that we can have a mostly dependencyless Windows build with GitLab CI. I don't think anybody uses this for a production-facing build.

So I'd leave this as-is for now, but agree that we should maybe iterate a bit on this going forward and collaborate with upstream.

Thanks!

Patrick