# [PATCH 0/9] meson: a couple of additions

35 messages from 2025-01-13 to 2025-01-22. Participants: Patrick Steinhardt, Junio C Hamano, Eli Schwartz, M Hickford.
Thread: https://gitlist.dev/t/62794

## Patrick Steinhardt, 2025-01-13 08:33

Subject: [PATCH 0/9] meson: a couple of additions
Message-ID: <20250113-b4-pks-meson-additions-v1-0-97f6a93f691d@pks.im>
URL: https://gitlist.dev/e/20250113-b4-pks-meson-additions-v1-0-97f6a93f691d%40pks.im

```
Hi,

this small patch series backfills in a couple of missing features into
Meson. It also improves test coverage of our Meson-based CI jobs so that
we compile with Meson with Visual Studio and compile fuzzers. CI runs
for GitLab and GitHub can be found at [1] and [2], respectively.

The series is built on top of fbe8d3079d (Git 2.48, 2025-01-10) with
ps/meson-weak-sha1-build at 6a0ee54f9a (meson: provide a summary of
configured backends, 2024-12-30) merged into it.

Thanks!

Patrick

[1]: https://gitlab.com/gitlab-org/git/-/merge_requests/280
[2]: https://github.com/git/git/pull/1870

---
Patrick Steinhardt (9):
      GIT-VERSION-GEN: simplify computing the dirty marker
      GIT-VERSION-GEN: move default version into a separate file
      meson: fix dependencies for generated headers
      meson: wire up development environments
      meson: wire up generation of distribution archive
      meson: wire up fuzzers
      meson: make the CSPRNG backend configurable
      meson: fix compilation with Visual Studio
      ci: wire up Visual Studio build with Meson

 .github/workflows/main.yml | 52 +++++++++++++++++++++++++++++++
 .gitlab-ci.yml             | 38 ++++++++++++++++++++++
 GIT-VERSION                |  1 +
 GIT-VERSION-GEN            | 17 +++++-----
 ci/run-build-and-tests.sh  |  3 +-
 meson.build                | 78 ++++++++++++++++++++++++++++++++++++----------
 meson_options.txt          |  4 +++
 oss-fuzz/meson.build       | 20 ++++++++++++
 8 files changed, 187 insertions(+), 26 deletions(-)


---
base-commit: 35a417ddf0eab983e4d5eb69e628aa198114bb05
change-id: 20250107-b4-pks-meson-additions-055c16b3052b


```

## Patrick Steinhardt, 2025-01-13 08:33

Subject: [PATCH 1/9] GIT-VERSION-GEN: simplify computing the dirty marker
Message-ID: <20250113-b4-pks-meson-additions-v1-1-97f6a93f691d@pks.im>
URL: https://gitlist.dev/e/20250113-b4-pks-meson-additions-v1-1-97f6a93f691d%40pks.im
In-Reply-To: <20250113-b4-pks-meson-additions-v1-0-97f6a93f691d@pks.im>

```
The GIT-VERSION-GEN script computes the version that Git is being built
from. When building from a commit with an unclean worktree it knows to
append "-dirty" to that version to indicate that there were custom
changes applied and that it isn't the exact same as that commit.

The dirtiness check is done manually via git-diff-index(1), which is
somewhat puzzling though: we already use git-describe(1) to compute the
version, which also knows to compute dirtiness via the "--dirty" flag.
But digging back in history explains why: the "-dirty" suffix was added
in 31e0b2ca81 (GIT 1.5.4.3, 2008-02-23), and git-describe(1) didn't yet
have support for "--dirty" back then.

Refactor the script to use git-describe(1). Despite being simpler, it
also results in a small speedup:

    Benchmark 1: git describe --dirty --match "v[0-9]*"
      Time (mean ± σ):      12.5 ms ±   0.3 ms    [User: 6.3 ms, System: 8.8 ms]
      Range (min … max):    12.0 ms …  13.5 ms    200 runs

    Benchmark 2: git describe --match "v[0-9]*" HEAD && git update-index -q --refresh && git diff-index --name-only HEAD --
      Time (mean ± σ):      17.9 ms ±   1.1 ms    [User: 8.8 ms, System: 14.4 ms]
      Range (min … max):    17.0 ms …  30.6 ms    148 runs

    Summary
      git describe --dirty --match "v[0-9]*" ran
        1.43 ± 0.09 times faster than git describe --match "v[0-9]*" && git update-index -q --refresh && git diff-index --name-only HEAD --

While the speedup doesn't really matter on Unix-based systems, where
filesystem operations are typically fast, they do matter on Windows
where the commands take a couple hundred milliseconds. A quick and dirty
check on that system shows a speedup from ~800ms to ~400ms.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 GIT-VERSION-GEN | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index f2af817feaeb384dee0ffd197f02a31cf2d31f87..754b8ca9eedaa2f7e3b61c83c1cc763538394fe6 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -39,13 +39,9 @@ then
 			test -d "${GIT_DIR:-.git}" ||
 			test -f "$SOURCE_DIR"/.git;
 		} &&
-		VN=$(git -C "$SOURCE_DIR" describe --match "v[0-9]*" HEAD 2>/dev/null) &&
+		VN=$(git -C "$SOURCE_DIR" describe --match --dirty "v[0-9]*" 2>/dev/null) &&
 		case "$VN" in
 		*$LF*) (exit 1) ;;
-		v[0-9]*)
-			git -C "$SOURCE_DIR" update-index -q --refresh
-			test -z "$(git -C "$SOURCE_DIR" diff-index --name-only HEAD --)" ||
-			VN="$VN-dirty" ;;
 		esac
 	then
 		VN=$(echo "$VN" | sed -e 's/-/./g');

-- 
2.48.0.257.gd3603152ad.dirty


```

## Patrick Steinhardt, 2025-01-13 08:33

Subject: [PATCH 2/9] GIT-VERSION-GEN: move default version into a separate file
Message-ID: <20250113-b4-pks-meson-additions-v1-2-97f6a93f691d@pks.im>
URL: https://gitlist.dev/e/20250113-b4-pks-meson-additions-v1-2-97f6a93f691d%40pks.im
In-Reply-To: <20250113-b4-pks-meson-additions-v1-0-97f6a93f691d@pks.im>

```
The Git version for Meson is currently wired up manually. It can thus
grow (and alread has grown) stale quite easily, as having multiple
sources of truth is never a good idea. This issue is mostly of cosmetic
nature as we don't use the project version anywhere, and instead use the
GIT-VERSION-GEN script to propagate the correct version into our build.
But it is somewhat puzzling when `meson setup` announces to build an old
Git release.

There are a couple of alternatives for how to solve this:

  - We can keep the version undefined, but this makes Meson output
    "undefined" for the version, as well.

  - We can adapt GIT-VERSION-GEN so that it knows to print a version to
    stdout with a specific invocation and then use `run_command()`. At
    the point of configuring the project we haven't yet figured out host
    details though, and thus we didn't yet set up the shell environment.
    While not an issue for Unix-based systems, this would be an issue in
    Windows, where the shell typically gets provided via Git for Windows
    and thus requires some special setup.

  - We can pull the default version out of GIT-VERSION-GEN and move it
    into its own file. This likely requires some adjustments for scripts
    that bump the version, but allows Meson to read the version from
    that file trivially.

The last option is a proper solution and quite trivial to implement, and
adapting scripts should be a one-time event. Refactor GIT-VERSION-GEN
accordingly.

This refactoring also prepares for a planned consolidation of all build
scripts into a separate folder. This should reduce clutter and make it
easier to find all scripts part of the build process.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 GIT-VERSION     | 1 +
 GIT-VERSION-GEN | 4 ++--
 meson.build     | 2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/GIT-VERSION b/GIT-VERSION
new file mode 100644
index 0000000000000000000000000000000000000000..ed39430ff189488182bc6d651bdb88a531498baa
--- /dev/null
+++ b/GIT-VERSION
@@ -0,0 +1 @@
+v2.48.0
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 754b8ca9eedaa2f7e3b61c83c1cc763538394fe6..95d7d41d233450774a6580c0de332e7b8f69eb4e 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -1,7 +1,5 @@
 #!/bin/sh
 
-DEF_VER=v2.48.0
-
 LF='
 '
 
@@ -21,6 +19,8 @@ then
 	exit 1
 fi
 
+DEF_VER=$(cat "$SOURCE_DIR"/GIT-VERSION)
+
 # Protect us from reading Git version information outside of the Git directory
 # in case it is not a repository itself, but embedded in an unrelated
 # repository.
diff --git a/meson.build b/meson.build
index 7361eb2eaad422e7a6c6ed95d275615836c21cdb..87755537d2aff84a9d8e86f0f5b025ef8dd23292 100644
--- a/meson.build
+++ b/meson.build
@@ -170,7 +170,7 @@
 
 project('git', 'c',
   meson_version: '>=0.61.0',
-  version: 'v2.47.GIT',
+  version: files('GIT-VERSION'),
 )
 
 fs = import('fs')

-- 
2.48.0.257.gd3603152ad.dirty


```

## Patrick Steinhardt, 2025-01-13 08:33

Subject: [PATCH 3/9] meson: fix dependencies for generated headers
Message-ID: <20250113-b4-pks-meson-additions-v1-3-97f6a93f691d@pks.im>
URL: https://gitlist.dev/e/20250113-b4-pks-meson-additions-v1-3-97f6a93f691d%40pks.im
In-Reply-To: <20250113-b4-pks-meson-additions-v1-0-97f6a93f691d@pks.im>

```
We generate a couple of headers from our documentation. These headers
are added to the libgit sources, but two of them aren't used by the
library, but instead by our builtins. This can cause parallel builds to
fail because the builtin object may be compiled before the header was
generated.

Fix the issue by adding both "config-list.h" and "hook-list.h" to the
list of builtin sources. While "command-list.h" is generated similarly,
it is used by "help.c" and thus part of the libgit sources indeed.

Reported-by: Evan Martin <evan.martin@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 meson.build | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/meson.build b/meson.build
index 87755537d2aff84a9d8e86f0f5b025ef8dd23292..e278ff207a7714fbb6b6cf8e1ec1fcca37360bd0 100644
--- a/meson.build
+++ b/meson.build
@@ -480,6 +480,13 @@ libgit_sources = [
   'xdiff/xutils.c',
 ]
 
+libgit_sources += custom_target(
+  input: 'command-list.txt',
+  output: 'command-list.h',
+  command: [shell, meson.current_source_dir() + '/generate-cmdlist.sh', meson.current_source_dir(), '@OUTPUT@'],
+  env: script_environment,
+)
+
 builtin_sources = [
   'builtin/add.c',
   'builtin/am.c',
@@ -607,14 +614,7 @@ builtin_sources = [
   'builtin/write-tree.c',
 ]
 
-libgit_sources += custom_target(
-  input: 'command-list.txt',
-  output: 'command-list.h',
-  command: [shell, meson.current_source_dir() + '/generate-cmdlist.sh', meson.current_source_dir(), '@OUTPUT@'],
-  env: script_environment,
-)
-
-libgit_sources += custom_target(
+builtin_sources += custom_target(
   output: 'config-list.h',
   command: [
     shell,
@@ -625,7 +625,7 @@ libgit_sources += custom_target(
   env: script_environment,
 )
 
-libgit_sources += custom_target(
+builtin_sources += custom_target(
   input: 'Documentation/githooks.txt',
   output: 'hook-list.h',
   command: [

-- 
2.48.0.257.gd3603152ad.dirty


```

## Patrick Steinhardt, 2025-01-13 08:33

Subject: [PATCH 4/9] meson: wire up development environments
Message-ID: <20250113-b4-pks-meson-additions-v1-4-97f6a93f691d@pks.im>
URL: https://gitlist.dev/e/20250113-b4-pks-meson-additions-v1-4-97f6a93f691d%40pks.im
In-Reply-To: <20250113-b4-pks-meson-additions-v1-0-97f6a93f691d@pks.im>

```
The Meson build system is able to wire up development environments. The
intent is to make build artifacts of the project available. This is
typically used to export e.g. paths to linkable libraries, which isn't
all that interesting in our context given that we don't have an official
library interface.

But what we can use this mechanism for is to expose the built Git
executables as well as the build directory. This allows users to play
around with the built Git version in the devenv, and allows them to
execute our test scripts directly with the built distribution.

Wire up this feature, which can then be used via `meson devenv` in the
build directory.

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

diff --git a/meson.build b/meson.build
index e278ff207a7714fbb6b6cf8e1ec1fcca37360bd0..0b559215e4f105ac87bd580d755f88c32b7b36ca 100644
--- a/meson.build
+++ b/meson.build
@@ -1932,6 +1932,14 @@ configure_file(
   configuration: build_options_config,
 )
 
+# Development environments can be used via `meson devenv -C <builddir>`. This
+# allows you to execute test scripts directly with the built Git version and
+# puts the built version of Git in your PATH.
+devenv = environment()
+devenv.set('GIT_BUILD_DIR', meson.current_build_dir())
+devenv.prepend('PATH', meson.current_build_dir() / 'bin-wrappers')
+meson.add_devenv(devenv)
+
 summary({
   'curl': curl.found(),
   'expat': expat.found(),

-- 
2.48.0.257.gd3603152ad.dirty


```

## Patrick Steinhardt, 2025-01-13 08:33

Subject: [PATCH 6/9] meson: wire up fuzzers
Message-ID: <20250113-b4-pks-meson-additions-v1-6-97f6a93f691d@pks.im>
URL: https://gitlist.dev/e/20250113-b4-pks-meson-additions-v1-6-97f6a93f691d%40pks.im
In-Reply-To: <20250113-b4-pks-meson-additions-v1-0-97f6a93f691d@pks.im>

```
Meson does not yet know to build our fuzzers. Introduce a new build
option "fuzzers" and wire up the fuzzers in case it is enabled. Adapt
our CI jobs so that they build the fuzzers by default.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/run-build-and-tests.sh |  3 ++-
 meson.build               |  4 ++++
 meson_options.txt         |  2 ++
 oss-fuzz/meson.build      | 20 ++++++++++++++++++++
 4 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 76667a1277720d74e09e8da227b5e0832003e0e2..6c828c3b755153dab179f73346e7124bda49c90e 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -53,7 +53,8 @@ case "$jobname" in
 *-meson)
 	group "Configure" meson setup build . \
 		--warnlevel 2 --werror \
-		--wrap-mode nofallback
+		--wrap-mode nofallback \
+		-Dfuzzers=true
 	group "Build" meson compile -C build --
 	if test -n "$run_tests"
 	then
diff --git a/meson.build b/meson.build
index 771bdded484a0c0e8638e7c6555e3f4e09e64025..5e1373f6a52a91beb527d00d8fd5c55d377c718b 100644
--- a/meson.build
+++ b/meson.build
@@ -1899,6 +1899,10 @@ if get_option('tests')
   subdir('t')
 endif
 
+if get_option('fuzzers')
+  subdir('oss-fuzz')
+endif
+
 subdir('bin-wrappers')
 if get_option('docs') != []
   subdir('Documentation')
diff --git a/meson_options.txt b/meson_options.txt
index 89b01bad042b533b23e0e2b4b780ce152ee688c8..34ba679cf931b67a794a9bb7e765bfb22106381e 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -95,3 +95,5 @@ option('tests', type: 'boolean', value: true,
   description: 'Enable building tests. This requires Perl, but is separate from the "perl" option such that you can build tests without Perl features enabled.')
 option('test_output_directory', type: 'string',
   description: 'Path to the directory used to store test outputs')
+option('fuzzers', type: 'boolean', value: false,
+  description: 'Enable building fuzzers.')
diff --git a/oss-fuzz/meson.build b/oss-fuzz/meson.build
new file mode 100644
index 0000000000000000000000000000000000000000..ed79665501655eae4948623c07114fab23a55393
--- /dev/null
+++ b/oss-fuzz/meson.build
@@ -0,0 +1,20 @@
+fuzz_programs = [
+  'fuzz-commit-graph.c',
+  'fuzz-config.c',
+  'fuzz-credential-from-url-gently.c',
+  'fuzz-date.c',
+  'fuzz-pack-headers.c',
+  'fuzz-pack-idx.c',
+  'fuzz-parse-attr-line.c',
+  'fuzz-url-decode-mem.c',
+]
+
+foreach fuzz_program : fuzz_programs
+  executable(fs.stem(fuzz_program),
+    sources: [
+      'dummy-cmd-main.c',
+      fuzz_program,
+    ],
+    dependencies: [libgit, common_main],
+  )
+endforeach

-- 
2.48.0.257.gd3603152ad.dirty


```

## Patrick Steinhardt, 2025-01-13 08:33

Subject: [PATCH 5/9] meson: wire up generation of distribution archive
Message-ID: <20250113-b4-pks-meson-additions-v1-5-97f6a93f691d@pks.im>
URL: https://gitlist.dev/e/20250113-b4-pks-meson-additions-v1-5-97f6a93f691d%40pks.im
In-Reply-To: <20250113-b4-pks-meson-additions-v1-0-97f6a93f691d@pks.im>

```
Meson knows to generate distribution archives via `meson dist`. Despite
generating the archive itself, this target also knows to compile and
execute tests from that archive, which helps to ensure that the result
is an adequate drop-in replacement for the versioned project.

While this already works as-is, one omission is that we don't propagate
the commit that this is built from into the resulting archive. This can
be fixed though by adding a distribution script that propagates the
version into the "version" file, which GIT-VERSION-GEN knows to read if
present.

Use GIT-VERSION-GEN itself to populate that file. There are two smallish
gotchas:

  - The script is executed in the build directory, not in the directory
    where we generate the archive. The target directory is propagated
    via the "MESON_DIST_ROOT" environment variable, but because we don't
    use a shell to execute GIT-VERSION-GEN we cannot populate the envvar
    into its arguments. We thus adapt GIT-VERSION-GEN to handle this for
    us.

  - We use the "GIT-VERSION-FILE.in" template to generate the version,
    which contains a "GIT_VERSION=" prefix that we need to strip after
    reading the "version" file. We could avoid this extra logic if we
    used a template that only had the `@GIT_VERSION@` placeholder, but
    it would require us to add one more template file.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 GIT-VERSION-GEN |  7 ++++++-
 meson.build     | 12 ++++++++++++
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 95d7d41d233450774a6580c0de332e7b8f69eb4e..1f0fb4098da392511f02a34cdcc84f3889771001 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -19,6 +19,11 @@ then
 	exit 1
 fi
 
+if test -n "$OUTPUT" && test -n "$MESON_DIST_ROOT"
+then
+    OUTPUT="$MESON_DIST_ROOT/$OUTPUT"
+fi
+
 DEF_VER=$(cat "$SOURCE_DIR"/GIT-VERSION)
 
 # Protect us from reading Git version information outside of the Git directory
@@ -33,7 +38,7 @@ then
 	# then try git-describe, then default.
 	if test -f "$SOURCE_DIR"/version
 	then
-		VN=$(cat "$SOURCE_DIR"/version) || VN="$DEF_VER"
+		VN=$(cat "$SOURCE_DIR"/version) && VN=${VN#GIT_VERSION=} || VN="$DEF_VER"
 	elif {
 			test -d "$SOURCE_DIR/.git" ||
 			test -d "${GIT_DIR:-.git}" ||
diff --git a/meson.build b/meson.build
index 0b559215e4f105ac87bd580d755f88c32b7b36ca..771bdded484a0c0e8638e7c6555e3f4e09e64025 100644
--- a/meson.build
+++ b/meson.build
@@ -1940,6 +1940,18 @@ devenv.set('GIT_BUILD_DIR', meson.current_build_dir())
 devenv.prepend('PATH', meson.current_build_dir() / 'bin-wrappers')
 meson.add_devenv(devenv)
 
+# Generate the 'version' file in the distribution tarball. This is used via
+# `meson dist -C <builddir>` to populate the source archive with the Git
+# version that the archive is being generated from. GIT-VERSION-GEN knows to
+# pick up this file.
+meson.add_dist_script(
+  shell,
+  meson.current_source_dir() / 'GIT-VERSION-GEN',
+  meson.current_source_dir(),
+  meson.current_source_dir() / 'GIT-VERSION-FILE.in',
+  'version',
+)
+
 summary({
   'curl': curl.found(),
   'expat': expat.found(),

-- 
2.48.0.257.gd3603152ad.dirty


```

## Patrick Steinhardt, 2025-01-13 08:33

Subject: [PATCH 7/9] meson: make the CSPRNG backend configurable
Message-ID: <20250113-b4-pks-meson-additions-v1-7-97f6a93f691d@pks.im>
URL: https://gitlist.dev/e/20250113-b4-pks-meson-additions-v1-7-97f6a93f691d%40pks.im
In-Reply-To: <20250113-b4-pks-meson-additions-v1-0-97f6a93f691d@pks.im>

```
The CSPRNG backend is not configurable in Meson and isn't quite
discoverable, either. Make it configurable and add the actual backend
used to the summary.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 meson.build       | 26 +++++++++++++++++++-------
 meson_options.txt |  2 ++
 2 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/meson.build b/meson.build
index 5e1373f6a52a91beb527d00d8fd5c55d377c718b..cb352ce6fd50616e3281a776104692c5b2bfa5b2 100644
--- a/meson.build
+++ b/meson.build
@@ -1325,6 +1325,7 @@ if not meson.is_cross_build() and fs.exists('/dev/tty')
   libgit_c_args += '-DHAVE_DEV_TTY'
 endif
 
+csprng_backend = get_option('csprng_backend')
 https_backend = get_option('https_backend')
 sha1_backend = get_option('sha1_backend')
 sha1_unsafe_backend = get_option('sha1_unsafe_backend')
@@ -1336,7 +1337,7 @@ if https_backend == 'auto' and security_framework.found()
   https_backend = 'CommonCrypto'
 endif
 
-openssl_required = 'openssl' in [https_backend, sha1_backend, sha1_unsafe_backend, sha256_backend]
+openssl_required = 'openssl' in [csprng_backend, https_backend, sha1_backend, sha1_unsafe_backend, sha256_backend]
 openssl = dependency('openssl', required: openssl_required, default_options: ['default_library=static'])
 if https_backend == 'auto' and openssl.found()
   https_backend = 'openssl'
@@ -1421,18 +1422,28 @@ else
   error('Unhandled SHA256 backend ' + sha256_backend)
 endif
 
-if compiler.has_header_symbol('stdlib.h', 'arc4random_buf')
+if csprng_backend in ['auto', 'arc4random'] and compiler.has_header_symbol('stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random')
   libgit_c_args += '-DHAVE_ARC4RANDOM'
-elif compiler.has_header_symbol('bsd/stdlib.h', 'arc4random_buf')
+  csprng_backend = 'arc4random'
+elif csprng_backend in ['auto', 'arc4random_bsd'] and compiler.has_header_symbol('bsd/stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random_bsd')
   libgit_c_args += '-DHAVE_ARC4RANDOM_BSD'
-elif compiler.has_function('getrandom', prefix: '#include <sys/random.h>')
+  csprng_backend = 'arc4random_bsd'
+elif csprng_backend in ['auto', 'getrandom'] and compiler.has_function('getrandom', prefix: '#include <sys/random.h>', required: csprng_backend == 'getrandom')
   libgit_c_args += '-DHAVE_GETRANDOM'
-elif compiler.has_function('getentropy', prefix: '#include <unistd.h>')
+  csprng_backend = 'getrandom'
+elif csprng_backend in ['auto', 'getentropy'] and compiler.has_function('getentropy', prefix: '#include <unistd.h>', required: csprng_backend == 'getentropy')
   libgit_c_args += '-DHAVE_GETENTROPY'
-elif compiler.has_function('RtlGenRandom', prefix: '#include <windows.h>\n#include <ntsecapi.h>')
+  csprng_backend = 'getentropy'
+elif csprng_backend in ['auto', 'rtlgenrandom'] and compiler.has_function('RtlGenRandom', prefix: '#include <windows.h>\n#include <ntsecapi.h>', required: csprng_backend == 'rtlgenrandom')
   libgit_c_args += '-DHAVE_RTLGENRANDOM'
-elif openssl.found()
+  csprng_backend = 'rtlgenrandom'
+elif csprng_backend in ['auto', 'openssl'] and openssl.found()
   libgit_c_args += '-DHAVE_OPENSSL_CSPRNG'
+  csprng_backend = 'openssl'
+elif csprng_backend in ['auto', 'urandom']
+  csprng_backend = 'urandom'
+else
+  error('Unsupported CSPRNG backend: ' + csprng_backend)
 endif
 
 if get_option('runtime_prefix')
@@ -1969,6 +1980,7 @@ summary({
 }, section: 'Auto-detected features')
 
 summary({
+  'csprng': csprng_backend,
   'https': https_backend,
   'sha1': sha1_backend,
   'sha1_unsafe': sha1_unsafe_backend,
diff --git a/meson_options.txt b/meson_options.txt
index 34ba679cf931b67a794a9bb7e765bfb22106381e..5429022f30621105cd6974e4260cca60e5f24324 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -47,6 +47,8 @@ option('regex', type: 'feature', value: 'auto',
   description: 'Use the system-provided regex library instead of the bundled one.')
 
 # Backends.
+option('csprng_backend', type: 'combo', value: 'auto', choices: ['auto', 'arc4random', 'arc4random_bsd', 'getrandom', 'getentropy', 'rtlgenrandom', 'openssl', 'urandom'],
+  description: 'The backend to use for generating cryptographically-secure pseudo-random numbers.')
 option('https_backend', type: 'combo', value: 'auto', choices: ['auto', 'openssl', 'CommonCrypto', 'none'],
   description: 'The HTTPS backend to use when connecting to remotes.')
 option('sha1_backend', type: 'combo', choices: ['openssl', 'block', 'sha1dc', 'CommonCrypto'], value: 'sha1dc',

-- 
2.48.0.257.gd3603152ad.dirty


```

## Patrick Steinhardt, 2025-01-13 08:33

Subject: [PATCH 8/9] meson: fix compilation with Visual Studio
Message-ID: <20250113-b4-pks-meson-additions-v1-8-97f6a93f691d@pks.im>
URL: https://gitlist.dev/e/20250113-b4-pks-meson-additions-v1-8-97f6a93f691d%40pks.im
In-Reply-To: <20250113-b4-pks-meson-additions-v1-0-97f6a93f691d@pks.im>

```
The Visual Studio compiler defaults to C89 unless explicitly asked to
use a different version of the C standard. We don't specify any C
standard at all though in our Meson build, and consequently compiling
Git fails:

    ...\git\git-compat-util.h(14): fatal error C1189: #error:  "Required C99 support is in a test phase.  Please see git-compat-util.h for more details."

Fix the issue by specifying the project's C standard. Funny enough,
specifying C99 does not work because apparently, `__STDC_VERSION__` is
not getting defined in that version at all. Instead, we have to specify
C11 as the project's C standard, which is also done in our CMake build
instructions.

We don't want to generally enforce C11 though, as our requiremets only
state that a C99 compiler is required. In fact, we don't even require
plain C99, but rather the GNU variant thereof.

Meson allows us to handle this case rather easily by specifying
"gnu99,c11", which will cause it to fall back to C11 in case GNU C99 is
unsupported. This feature has only been introduced with Meson 1.3.0
though, and we support 0.61.0 and newer. In case we use such an oldish
version though we fall back to requiring GNU99 unconditionally. This
means that Windows essentially requires Meson 1.3.0 and newer when using
Visual Studio, but I doubt that this is ever going to be a real problem.

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

diff --git a/meson.build b/meson.build
index cb352ce6fd50616e3281a776104692c5b2bfa5b2..831da1d43cafe85a8c9ac872e141476adbc08188 100644
--- a/meson.build
+++ b/meson.build
@@ -171,6 +171,14 @@
 project('git', 'c',
   meson_version: '>=0.61.0',
   version: files('GIT-VERSION'),
+  default_options: [
+    # Git requires C99 with GNU extensions, which of course isn't supported by
+    # MSVC. Funny enough, C99 doesn't work with MSVC either, as it has only
+    # learned to define __STDC_VERSION__ with C11 and later. We thus require
+    # GNU C99 and fall back to C11. Meson only learned to handle the fallback
+    # with version 1.3.0, so on older versions we use GNU C99 unconditionally.
+    'c_std=' + (meson.version().version_compare('>=1.3.0') ? 'gnu99,c11' : 'gnu99'),
+  ]
 )
 
 fs = import('fs')

-- 
2.48.0.257.gd3603152ad.dirty


```

## Patrick Steinhardt, 2025-01-13 08:33

Subject: [PATCH 9/9] ci: wire up Visual Studio build with Meson
Message-ID: <20250113-b4-pks-meson-additions-v1-9-97f6a93f691d@pks.im>
URL: https://gitlist.dev/e/20250113-b4-pks-meson-additions-v1-9-97f6a93f691d%40pks.im
In-Reply-To: <20250113-b4-pks-meson-additions-v1-0-97f6a93f691d@pks.im>

```
Add a new job to GitHub Actions and GitLab CI that builds and tests
Meson-based builds with Visual Studio.

A couple notes:

  - While the build job is mandatory, the test job is marked as "manual"
    on GitLab so that it doesn't run by default. We already have a bunch
    of Windows-based jobs, and the computational overhead that these
    cause is simply out of proportion to run the test suite twice.

    The same isn't true for GitHub as I could not find a way to make a
    subset of jobs manually triggered.

  - We disable Perl. This is because we pick up Perl from Git for
    Windows, which outputs different paths ("/c/" instead of "C:\") than
    what we expect in our tests.

  - We don't use the Git for Windows SDK. Instead, the build only
    depends on Visual Studio, Meson and Git for Windows. All the other
    dependencies like curl, pcre2 and zlib get pulled in and compiled
    automatically by Meson and thus do not have to be provided by the
    system.

  - We open-code "ci/run-test-slice.sh". This is because we only have
    direct access to PowerShell, so we manually implement the logic.
    There is an upstream pull request for the Meson build system [1] to
    implement test slicing in Meson directly.

  - We don't process test artifacts for failed CI jobs. This is done to
    keep down prerequisites to a minimum.

All tests are passing.

[1]: https://github.com/mesonbuild/meson/pull/14092

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 52 ++++++++++++++++++++++++++++++++++++++++++++++
 .gitlab-ci.yml             | 38 +++++++++++++++++++++++++++++++++
 2 files changed, 90 insertions(+)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 900be9957a23fcaa64e1aefd0c8638c5f84b7997..7f55f8b3a91d6caf95934af308a2bd35a19a62f1 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -248,6 +248,58 @@ jobs:
       with:
         name: failed-tests-windows-vs-${{ matrix.nr }}
         path: ${{env.FAILED_TEST_ARTIFACTS}}
+
+  windows-meson-build:
+    name: win+Meson build
+    needs: ci-config
+    if: needs.ci-config.outputs.enabled == 'yes'
+    runs-on: windows-latest
+    concurrency:
+      group: windows-meson-build-${{ github.ref }}
+      cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }}
+    steps:
+    - uses: actions/checkout@v4
+    - uses: actions/setup-python@v5
+    - name: Set up dependencies
+      shell: pwsh
+      run: pip install meson ninja
+    - name: Setup
+      shell: pwsh
+      run: meson setup build -Dperl=disabled
+    - name: Compile
+      shell: pwsh
+      run: meson compile -C build
+    - name: Upload build artifacts
+      uses: actions/upload-artifact@v4
+      with:
+        name: windows-meson-artifacts
+        path: build
+  windows-meson-test:
+    name: win+Meson test
+    runs-on: windows-latest
+    needs: [ci-config, windows-meson-build]
+    strategy:
+      fail-fast: false
+      matrix:
+        nr: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
+    concurrency:
+      group: windows-meson-test-${{ matrix.nr }}-${{ github.ref }}
+      cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }}
+    steps:
+    - uses: actions/checkout@v4
+    - uses: actions/setup-python@v5
+    - name: Set up dependencies
+      shell: pwsh
+      run: pip install meson ninja
+    - name: Download build artifacts
+      uses: actions/download-artifact@v4
+      with:
+        name: windows-meson-artifacts
+        path: build
+    - name: Test
+      shell: pwsh
+      run: meson test -C build --list | Select-Object -Skip 1 | Select-String .* | Group-Object -Property { $_.LineNumber % 10 } | Where-Object Name -EQ ${{ matrix.nr }} | ForEach-Object { meson test -C build --no-rebuild --print-errorlogs $_.Group }
+
   regular:
     name: ${{matrix.vector.jobname}} (${{matrix.vector.pool}})
     needs: ci-config
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 9254e01583306e67dc12b6b9e0015183e1108655..4976e18a0503298f38230f5ba7348675baf48664 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -149,6 +149,44 @@ test:mingw64:
     - git-sdk/usr/bin/bash.exe -l -c 'ci/print-test-failures.sh'
   parallel: 10
 
+.msvc-meson:
+  tags:
+    - saas-windows-medium-amd64
+  before_script:
+    - choco install -y git meson ninja openssl
+    - Import-Module $env:ChocolateyInstall\helpers\chocolateyProfile.psm1
+    - refreshenv
+    # The certificate store for Python on Windows is broken and fails to fetch
+    # certificates, see https://bugs.python.org/issue36011. This seems to
+    # mostly be an issue with how the GitLab image is set up as it is a
+    # non-issue on GitHub Actions. Work around the issue by importing
+    # cetrificates manually.
+    - Invoke-WebRequest https://curl.haxx.se/ca/cacert.pem -OutFile cacert.pem
+    - openssl pkcs12 -export -nokeys -in cacert.pem -out certs.pfx -passout "pass:"
+    - Import-PfxCertificate -CertStoreLocation Cert:\LocalMachine\Root -FilePath certs.pfx
+
+build:msvc-meson:
+  extends: .msvc-meson
+  stage: build
+  script:
+    - meson setup build -Dperl=disabled
+    - meson compile -C build
+  artifacts:
+    paths:
+      - build
+
+test:msvc-meson:
+  extends: .msvc-meson
+  stage: test
+  when: manual
+  timeout: 6h
+  needs:
+    - job: "build:msvc-meson"
+      artifacts: true
+  script:
+    - meson test -C build --list | Select-Object -Skip 1 | Select-String .* | Group-Object -Property { $_.LineNumber % $Env:CI_NODE_TOTAL + 1 } | Where-Object Name -EQ $Env:CI_NODE_INDEX | ForEach-Object { meson test -C build --no-rebuild --print-errorlogs $_.Group }
+  parallel: 10
+
 test:fuzz-smoke-tests:
   image: ubuntu:latest
   stage: test

-- 
2.48.0.257.gd3603152ad.dirty


```

## Patrick Steinhardt, 2025-01-13 09:25

Subject: Re: [PATCH 7/9] meson: make the CSPRNG backend configurable
Message-ID: <Z4TcBRt6CX6Q3a5i@pks.im>
URL: https://gitlist.dev/e/Z4TcBRt6CX6Q3a5i%40pks.im
In-Reply-To: <20250113-b4-pks-meson-additions-v1-7-97f6a93f691d@pks.im>

```
On Mon, Jan 13, 2025 at 09:33:40AM +0100, Patrick Steinhardt wrote:
> diff --git a/meson.build b/meson.build
> index 5e1373f6a52a91beb527d00d8fd5c55d377c718b..cb352ce6fd50616e3281a776104692c5b2bfa5b2 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1325,6 +1325,7 @@ if not meson.is_cross_build() and fs.exists('/dev/tty')
> @@ -1421,18 +1422,28 @@ else
>    error('Unhandled SHA256 backend ' + sha256_backend)
>  endif
>  
> -if compiler.has_header_symbol('stdlib.h', 'arc4random_buf')
> +if csprng_backend in ['auto', 'arc4random'] and compiler.has_header_symbol('stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random')
>    libgit_c_args += '-DHAVE_ARC4RANDOM'
> -elif compiler.has_header_symbol('bsd/stdlib.h', 'arc4random_buf')
> +  csprng_backend = 'arc4random'
> +elif csprng_backend in ['auto', 'arc4random_bsd'] and compiler.has_header_symbol('bsd/stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random_bsd')
>    libgit_c_args += '-DHAVE_ARC4RANDOM_BSD'
> -elif compiler.has_function('getrandom', prefix: '#include <sys/random.h>')
> +  csprng_backend = 'arc4random_bsd'
> +elif csprng_backend in ['auto', 'getrandom'] and compiler.has_function('getrandom', prefix: '#include <sys/random.h>', required: csprng_backend == 'getrandom')
>    libgit_c_args += '-DHAVE_GETRANDOM'
> -elif compiler.has_function('getentropy', prefix: '#include <unistd.h>')
> +  csprng_backend = 'getrandom'
> +elif csprng_backend in ['auto', 'getentropy'] and compiler.has_function('getentropy', prefix: '#include <unistd.h>', required: csprng_backend == 'getentropy')
>    libgit_c_args += '-DHAVE_GETENTROPY'
> -elif compiler.has_function('RtlGenRandom', prefix: '#include <windows.h>\n#include <ntsecapi.h>')
> +  csprng_backend = 'getentropy'
> +elif csprng_backend in ['auto', 'rtlgenrandom'] and compiler.has_function('RtlGenRandom', prefix: '#include <windows.h>\n#include <ntsecapi.h>', required: csprng_backend == 'rtlgenrandom')
>    libgit_c_args += '-DHAVE_RTLGENRANDOM'
> -elif openssl.found()
> +  csprng_backend = 'rtlgenrandom'
> +elif csprng_backend in ['auto', 'openssl'] and openssl.found()
>    libgit_c_args += '-DHAVE_OPENSSL_CSPRNG'
> +  csprng_backend = 'openssl'
> +elif csprng_backend in ['auto', 'urandom']
> +  csprng_backend = 'urandom'
> +else
> +  error('Unsupported CSPRNG backend: ' + csprng_backend)
>  endif
>  
>  if get_option('runtime_prefix')

I just noticed that this generates warnings because we use features not
yet in Meson v0.61.0, which is our minimum required version. I'll convert
these to instead use `compiler.has_header_symbol()` consistently, which
is nicer to read anyway, and will add another patch on top that makes us
use `--fatal-meson-warnings` in CI so that warnings will cause us to
abort the build.

Patrick

```

## Junio C Hamano, 2025-01-13 17:42

Subject: Re: [PATCH 2/9] GIT-VERSION-GEN: move default version into a separate file
Message-ID: <xmqqa5bua9vy.fsf@gitster.g>
URL: https://gitlist.dev/e/xmqqa5bua9vy.fsf%40gitster.g
In-Reply-To: <20250113-b4-pks-meson-additions-v1-2-97f6a93f691d@pks.im>

```
Patrick Steinhardt <ps@pks.im> writes:

>   - We can pull the default version out of GIT-VERSION-GEN and move it
>     into its own file. This likely requires some adjustments for scripts
>     that bump the version, but allows Meson to read the version from
>     that file trivially.
>
> The last option is a proper solution and quite trivial to implement, and
> adapting scripts should be a one-time event. Refactor GIT-VERSION-GEN
> accordingly.

It is not clear what "proper" is.  It smells like we are bending an
established work flow element to placate a tool that is not willing
to cooperate, which is very much unwelcome.

Compared to that, grepping for "^DEF_VER=" in the file may be less
yucky.

```

## Junio C Hamano, 2025-01-13 17:48

Subject: Re: [PATCH 6/9] meson: wire up fuzzers
Message-ID: <xmqq5xmia9m0.fsf@gitster.g>
URL: https://gitlist.dev/e/xmqq5xmia9m0.fsf%40gitster.g
In-Reply-To: <20250113-b4-pks-meson-additions-v1-6-97f6a93f691d@pks.im>

```
Patrick Steinhardt <ps@pks.im> writes:

> Meson does not yet know to build our fuzzers. Introduce a new build
> option "fuzzers" and wire up the fuzzers in case it is enabled. Adapt
> our CI jobs so that they build the fuzzers by default.

Nice.  We have shipped a feature release with bunch of meson.build
files, but it has known holes we need to fill, and this is one of
the missing things.  Let's make it a goal to achieve feature parity
within two releases---if we can do so in one release cycle, that
would be great ;-)

Thanks.

```

## Eli Schwartz, 2025-01-13 17:51

Subject: Re: [PATCH 2/9] GIT-VERSION-GEN: move default version into a separate file
Message-ID: <c36dc170-2792-41e2-b128-04c7c5e7ab55@gentoo.org>
URL: https://gitlist.dev/e/c36dc170-2792-41e2-b128-04c7c5e7ab55%40gentoo.org
In-Reply-To: <xmqqa5bua9vy.fsf@gitster.g>

```
On 1/13/25 12:42 PM, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
>>   - We can pull the default version out of GIT-VERSION-GEN and move it
>>     into its own file. This likely requires some adjustments for scripts
>>     that bump the version, but allows Meson to read the version from
>>     that file trivially.
>>
>> The last option is a proper solution and quite trivial to implement, and
>> adapting scripts should be a one-time event. Refactor GIT-VERSION-GEN
>> accordingly.
> 
> It is not clear what "proper" is.  It smells like we are bending an
> established work flow element to placate a tool that is not willing
> to cooperate, which is very much unwelcome.


If I understand correctly, the constraint is that it should work on
Windows, which means there is a bootstrap issue regarding detection of
an "sh" command for running ./GIT-VERSION-GEN

Proper simply means it works reliably on all supported targets.


> Compared to that, grepping for "^DEF_VER=" in the file may be less
> yucky.


Or for the sake of Windows portability, grep_version.py?


-- 
Eli Schwartz

```

## Junio C Hamano, 2025-01-13 17:55

Subject: Re: [PATCH 5/9] meson: wire up generation of distribution archive
Message-ID: <xmqqv7ui8uoh.fsf@gitster.g>
URL: https://gitlist.dev/e/xmqqv7ui8uoh.fsf%40gitster.g
In-Reply-To: <20250113-b4-pks-meson-additions-v1-5-97f6a93f691d@pks.im>

```
Patrick Steinhardt <ps@pks.im> writes:

> Meson knows to generate distribution archives via `meson dist`. Despite
> generating the archive itself, this target also knows to compile and
> execute tests from that archive, which helps to ensure that the result
> is an adequate drop-in replacement for the versioned project.

My reading hiccupped at "Despite" that does not seem to say anything
contradicting to what follows.  Did you mean the same thing as "In
addition to" there?

> diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
> index 95d7d41d233450774a6580c0de332e7b8f69eb4e..1f0fb4098da392511f02a34cdcc84f3889771001 100755
> --- a/GIT-VERSION-GEN
> +++ b/GIT-VERSION-GEN
> @@ -19,6 +19,11 @@ then
>  	exit 1
>  fi
>  
> +if test -n "$OUTPUT" && test -n "$MESON_DIST_ROOT"
> +then
> +    OUTPUT="$MESON_DIST_ROOT/$OUTPUT"
> +fi
> +
>  DEF_VER=$(cat "$SOURCE_DIR"/GIT-VERSION)
>  
>  # Protect us from reading Git version information outside of the Git directory
> @@ -33,7 +38,7 @@ then
>  	# then try git-describe, then default.
>  	if test -f "$SOURCE_DIR"/version
>  	then
> -		VN=$(cat "$SOURCE_DIR"/version) || VN="$DEF_VER"
> +		VN=$(cat "$SOURCE_DIR"/version) && VN=${VN#GIT_VERSION=} || VN="$DEF_VER"

It used to be that the contents in the "version" file was the
ultimate truth to be used as-is, but now somebody may write it with
or without GIT_VERSION= prefix, and this one place is now prepared
to strip the extra prefix, but everybody else who has been happily
reading the "version" file is now broken until it is adjusted in the
same way?


```

## Junio C Hamano, 2025-01-13 17:59

Subject: Re: [PATCH 7/9] meson: make the CSPRNG backend configurable
Message-ID: <xmqqr0568uhy.fsf@gitster.g>
URL: https://gitlist.dev/e/xmqqr0568uhy.fsf%40gitster.g
In-Reply-To: <20250113-b4-pks-meson-additions-v1-7-97f6a93f691d@pks.im>

```
Patrick Steinhardt <ps@pks.im> writes:

> The CSPRNG backend is not configurable in Meson and isn't quite
> discoverable, either. Make it configurable and add the actual backend
> used to the summary.

Makes sense.  Thanks.

> +if csprng_backend in ['auto', 'arc4random'] and compiler.has_header_symbol('stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random')
>    libgit_c_args += '-DHAVE_ARC4RANDOM'
> -elif compiler.has_header_symbol('bsd/stdlib.h', 'arc4random_buf')
> +  csprng_backend = 'arc4random'
> +elif csprng_backend in ['auto', 'arc4random_bsd'] and compiler.has_header_symbol('bsd/stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random_bsd')
>    libgit_c_args += '-DHAVE_ARC4RANDOM_BSD'
> -elif compiler.has_function('getrandom', prefix: '#include <sys/random.h>')
> +  csprng_backend = 'arc4random_bsd'
> +elif csprng_backend in ['auto', 'getrandom'] and compiler.has_function('getrandom', prefix: '#include <sys/random.h>', required: csprng_backend == 'getrandom')
>    libgit_c_args += '-DHAVE_GETRANDOM'
> -elif compiler.has_function('getentropy', prefix: '#include <unistd.h>')
> +  csprng_backend = 'getrandom'
> +elif csprng_backend in ['auto', 'getentropy'] and compiler.has_function('getentropy', prefix: '#include <unistd.h>', required: csprng_backend == 'getentropy')
>    libgit_c_args += '-DHAVE_GETENTROPY'
> -elif compiler.has_function('RtlGenRandom', prefix: '#include <windows.h>\n#include <ntsecapi.h>')
> +  csprng_backend = 'getentropy'
> +elif csprng_backend in ['auto', 'rtlgenrandom'] and compiler.has_function('RtlGenRandom', prefix: '#include <windows.h>\n#include <ntsecapi.h>', required: csprng_backend == 'rtlgenrandom')
>    libgit_c_args += '-DHAVE_RTLGENRANDOM'
> -elif openssl.found()
> +  csprng_backend = 'rtlgenrandom'
> +elif csprng_backend in ['auto', 'openssl'] and openssl.found()
>    libgit_c_args += '-DHAVE_OPENSSL_CSPRNG'
> +  csprng_backend = 'openssl'
> +elif csprng_backend in ['auto', 'urandom']
> +  csprng_backend = 'urandom'
> +else
> +  error('Unsupported CSPRNG backend: ' + csprng_backend)
>  endif

IIRC, the precedence order of CPP macros related to csprng backends
were chosen to reflect our preference for more secure and faster
ones over the ones that are less so.  Does the above list recreate
the same order, and do we want to somehow make sure future
developers would not break that order without knowing our intention,
saying "when all things are equal, we should sort in alphabetical
order" or something?

Thanks.

```

## M Hickford, 2025-01-13 21:12

Subject: Re: [PATCH 8/9] meson: fix compilation with Visual Studio
Message-ID: <6df239ab-eb04-41d0-898d-7cafe925b13a@gmail.com>
URL: https://gitlist.dev/e/6df239ab-eb04-41d0-898d-7cafe925b13a%40gmail.com
In-Reply-To: <20250113-b4-pks-meson-additions-v1-8-97f6a93f691d@pks.im>

```
On 2025-01-13 08:33, Patrick Steinhardt wrote:
> The Visual Studio compiler defaults to C89 unless explicitly asked to
> use a different version of the C standard. We don't specify any C
> standard at all though in our Meson build, and consequently compiling
> Git fails:
> 
>      ...\git\git-compat-util.h(14): fatal error C1189: #error:  "Required C99 support is in a test phase.  Please see git-compat-util.h for more details."
> 
> Fix the issue by specifying the project's C standard. Funny enough,
> specifying C99 does not work because apparently, `__STDC_VERSION__` is
> not getting defined in that version at all. Instead, we have to specify
> C11 as the project's C standard, which is also done in our CMake build
> instructions.
> 
> We don't want to generally enforce C11 though, as our requiremets only
> state that a C99 compiler is required. In fact, we don't even require
> plain C99, but rather the GNU variant thereof.
> 
> Meson allows us to handle this case rather easily by specifying
> "gnu99,c11", which will cause it to fall back to C11 in case GNU C99 is
> unsupported. This feature has only been introduced with Meson 1.3.0
> though, and we support 0.61.0 and newer. In case we use such an oldish
> version though we fall back to requiring GNU99 unconditionally. This
> means that Windows essentially requires Meson 1.3.0 and newer when using
> Visual Studio, but I doubt that this is ever going to be a real problem.
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>

Thanks. This fixes the problem for me.

Tested-by: M Hickford <mirth.hickford@gmail.com>

> ---
>   meson.build | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/meson.build b/meson.build
> index cb352ce6fd50616e3281a776104692c5b2bfa5b2..831da1d43cafe85a8c9ac872e141476adbc08188 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -171,6 +171,14 @@
>   project('git', 'c',
>     meson_version: '>=0.61.0',
>     version: files('GIT-VERSION'),
> +  default_options: [
> +    # Git requires C99 with GNU extensions, which of course isn't supported by
> +    # MSVC. Funny enough, C99 doesn't work with MSVC either, as it has only
> +    # learned to define __STDC_VERSION__ with C11 and later. We thus require
> +    # GNU C99 and fall back to C11. Meson only learned to handle the fallback
> +    # with version 1.3.0, so on older versions we use GNU C99 unconditionally.
> +    'c_std=' + (meson.version().version_compare('>=1.3.0') ? 'gnu99,c11' : 'gnu99'),
> +  ]
>   )
>   
>   fs = import('fs')
> 


```

## Patrick Steinhardt, 2025-01-14 09:13

Subject: Re: [PATCH 7/9] meson: make the CSPRNG backend configurable
Message-ID: <Z4YqtlfxIh4p6qPx@pks.im>
URL: https://gitlist.dev/e/Z4YqtlfxIh4p6qPx%40pks.im
In-Reply-To: <xmqqr0568uhy.fsf@gitster.g>

```
On Mon, Jan 13, 2025 at 09:59:53AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > +if csprng_backend in ['auto', 'arc4random'] and compiler.has_header_symbol('stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random')
> >    libgit_c_args += '-DHAVE_ARC4RANDOM'
> > -elif compiler.has_header_symbol('bsd/stdlib.h', 'arc4random_buf')
> > +  csprng_backend = 'arc4random'
> > +elif csprng_backend in ['auto', 'arc4random_bsd'] and compiler.has_header_symbol('bsd/stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random_bsd')
> >    libgit_c_args += '-DHAVE_ARC4RANDOM_BSD'
> > -elif compiler.has_function('getrandom', prefix: '#include <sys/random.h>')
> > +  csprng_backend = 'arc4random_bsd'
> > +elif csprng_backend in ['auto', 'getrandom'] and compiler.has_function('getrandom', prefix: '#include <sys/random.h>', required: csprng_backend == 'getrandom')
> >    libgit_c_args += '-DHAVE_GETRANDOM'
> > -elif compiler.has_function('getentropy', prefix: '#include <unistd.h>')
> > +  csprng_backend = 'getrandom'
> > +elif csprng_backend in ['auto', 'getentropy'] and compiler.has_function('getentropy', prefix: '#include <unistd.h>', required: csprng_backend == 'getentropy')
> >    libgit_c_args += '-DHAVE_GETENTROPY'
> > -elif compiler.has_function('RtlGenRandom', prefix: '#include <windows.h>\n#include <ntsecapi.h>')
> > +  csprng_backend = 'getentropy'
> > +elif csprng_backend in ['auto', 'rtlgenrandom'] and compiler.has_function('RtlGenRandom', prefix: '#include <windows.h>\n#include <ntsecapi.h>', required: csprng_backend == 'rtlgenrandom')
> >    libgit_c_args += '-DHAVE_RTLGENRANDOM'
> > -elif openssl.found()
> > +  csprng_backend = 'rtlgenrandom'
> > +elif csprng_backend in ['auto', 'openssl'] and openssl.found()
> >    libgit_c_args += '-DHAVE_OPENSSL_CSPRNG'
> > +  csprng_backend = 'openssl'
> > +elif csprng_backend in ['auto', 'urandom']
> > +  csprng_backend = 'urandom'
> > +else
> > +  error('Unsupported CSPRNG backend: ' + csprng_backend)
> >  endif
> 
> IIRC, the precedence order of CPP macros related to csprng backends
> were chosen to reflect our preference for more secure and faster
> ones over the ones that are less so.  Does the above list recreate
> the same order, and do we want to somehow make sure future
> developers would not break that order without knowing our intention,
> saying "when all things are equal, we should sort in alphabetical
> order" or something?

Yup, it's the exact same order as we have in our Makefile and as in
"wrapper.c". And yes, good idea, I'll add a comment.

Patrick

```

## Patrick Steinhardt, 2025-01-14 09:13

Subject: Re: [PATCH 2/9] GIT-VERSION-GEN: move default version into a separate file
Message-ID: <Z4YqzsP7yJ1OcmZ-@pks.im>
URL: https://gitlist.dev/e/Z4YqzsP7yJ1OcmZ-%40pks.im
In-Reply-To: <c36dc170-2792-41e2-b128-04c7c5e7ab55@gentoo.org>

```
On Mon, Jan 13, 2025 at 12:51:59PM -0500, Eli Schwartz wrote:
> On 1/13/25 12:42 PM, Junio C Hamano wrote:
> > Patrick Steinhardt <ps@pks.im> writes:
> > 
> >>   - We can pull the default version out of GIT-VERSION-GEN and move it
> >>     into its own file. This likely requires some adjustments for scripts
> >>     that bump the version, but allows Meson to read the version from
> >>     that file trivially.
> >>
> >> The last option is a proper solution and quite trivial to implement, and
> >> adapting scripts should be a one-time event. Refactor GIT-VERSION-GEN
> >> accordingly.
> > 
> > It is not clear what "proper" is.  It smells like we are bending an
> > established work flow element to placate a tool that is not willing
> > to cooperate, which is very much unwelcome.
> 
> 
> If I understand correctly, the constraint is that it should work on
> Windows, which means there is a bootstrap issue regarding detection of
> an "sh" command for running ./GIT-VERSION-GEN
> 
> Proper simply means it works reliably on all supported targets.

Yeah, exactly, that's the issue. We could of course try to use
GIT-VERSION-GEN anyway and just fall back to an empty string if the
command wasn't found. We don't use the project version anyway, so it's
only a cosmetic problem. And it's more accurate than extracting DEF_VER,
too.

> > Compared to that, grepping for "^DEF_VER=" in the file may be less
> > yucky.
> 
> Or for the sake of Windows portability, grep_version.py?

I don't want to make Python an explicit dependency for building Git, and
due to Muon it isn't even with the Meson build infra.

Patrick

```

## Patrick Steinhardt, 2025-01-14 09:14

Subject: Re: [PATCH 5/9] meson: wire up generation of distribution archive
Message-ID: <Z4Yq2uxzOz_6vuQ7@pks.im>
URL: https://gitlist.dev/e/Z4Yq2uxzOz_6vuQ7%40pks.im
In-Reply-To: <xmqqv7ui8uoh.fsf@gitster.g>

```
On Mon, Jan 13, 2025 at 09:55:58AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Meson knows to generate distribution archives via `meson dist`. Despite
> > generating the archive itself, this target also knows to compile and
> > execute tests from that archive, which helps to ensure that the result
> > is an adequate drop-in replacement for the versioned project.
> 
> My reading hiccupped at "Despite" that does not seem to say anything
> contradicting to what follows.  Did you mean the same thing as "In
> addition to" there?

Yup, will fix.

> > diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
> > index 95d7d41d233450774a6580c0de332e7b8f69eb4e..1f0fb4098da392511f02a34cdcc84f3889771001 100755
> > --- a/GIT-VERSION-GEN
> > +++ b/GIT-VERSION-GEN
> > @@ -19,6 +19,11 @@ then
> >  	exit 1
> >  fi
> >  
> > +if test -n "$OUTPUT" && test -n "$MESON_DIST_ROOT"
> > +then
> > +    OUTPUT="$MESON_DIST_ROOT/$OUTPUT"
> > +fi
> > +
> >  DEF_VER=$(cat "$SOURCE_DIR"/GIT-VERSION)
> >  
> >  # Protect us from reading Git version information outside of the Git directory
> > @@ -33,7 +38,7 @@ then
> >  	# then try git-describe, then default.
> >  	if test -f "$SOURCE_DIR"/version
> >  	then
> > -		VN=$(cat "$SOURCE_DIR"/version) || VN="$DEF_VER"
> > +		VN=$(cat "$SOURCE_DIR"/version) && VN=${VN#GIT_VERSION=} || VN="$DEF_VER"
> 
> It used to be that the contents in the "version" file was the
> ultimate truth to be used as-is, but now somebody may write it with
> or without GIT_VERSION= prefix, and this one place is now prepared
> to strip the extra prefix, but everybody else who has been happily
> reading the "version" file is now broken until it is adjusted in the
> same way?

I think it would be fine and that other callers don't have to get
adjusted as long as they haven't been writing files like this. But
this snippet is going away in v2 anyway as I approach the problem a bit
differently now.

Patrick

```

## Patrick Steinhardt, 2025-01-14 10:31

Subject: Re: [PATCH 6/9] meson: wire up fuzzers
Message-ID: <Z4Y88UW7j_GRvbta@pks.im>
URL: https://gitlist.dev/e/Z4Y88UW7j_GRvbta%40pks.im
In-Reply-To: <xmqq5xmia9m0.fsf@gitster.g>

```
On Mon, Jan 13, 2025 at 09:48:07AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Meson does not yet know to build our fuzzers. Introduce a new build
> > option "fuzzers" and wire up the fuzzers in case it is enabled. Adapt
> > our CI jobs so that they build the fuzzers by default.
> 
> Nice.  We have shipped a feature release with bunch of meson.build
> files, but it has known holes we need to fill, and this is one of
> the missing things.  Let's make it a goal to achieve feature parity
> within two releases---if we can do so in one release cycle, that
> would be great ;-)

Yeah, I already had a couple of features planned for this release cycle
anyway, most importantly static analysis. I'll have to take a look at
which other features are still missing -- hints are welcome.

One of the known omissions is most of "contrib/" and "gitk/". I'm not
sure whether these should be included or not. For the former I'm leaning
into the direction of not doing it, but can do so if others disagree
with me. For the latter I'd leave it up to Johannes to decide (cc'd).

Patrick

```

## Junio C Hamano, 2025-01-14 19:13

Subject: Re: [PATCH 7/9] meson: make the CSPRNG backend configurable
Message-ID: <xmqqv7uh2op8.fsf@gitster.g>
URL: https://gitlist.dev/e/xmqqv7uh2op8.fsf%40gitster.g
In-Reply-To: <Z4YqtlfxIh4p6qPx@pks.im>

```
Patrick Steinhardt <ps@pks.im> writes:

> Yup, it's the exact same order as we have in our Makefile and as in
> "wrapper.c". And yes, good idea, I'll add a comment.

Yeah, a comment is a good starting point.  We should say something
along the lines of "if you are tempted to change this, change the
other one to match" or something.

If we can keep a single source of truth and derive these two places
that should stay in sync, that would be ideal, but that can be left
outside the topic for now, I think.

Thanks.

```

## Patrick Steinhardt, 2025-01-22 12:05

Subject: [PATCH v3 00/11] meson: a couple of additions
Message-ID: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>
URL: https://gitlist.dev/e/20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd%40pks.im
In-Reply-To: <20250113-b4-pks-meson-additions-v1-0-97f6a93f691d@pks.im>

```
Hi,

this small patch series backfills in a couple of missing features into
Meson. It also improves test coverage of our Meson-based CI jobs so that
we compile with Meson with Visual Studio and compile fuzzers. CI runs
for GitLab and GitHub can be found at [1] and [2], respectively.

The series is built on top of fbe8d3079d (Git 2.48, 2025-01-10) with
ps/meson-weak-sha1-build at 6a0ee54f9a (meson: provide a summary of
configured backends, 2024-12-30) merged into it.

Changes in v2:
  - Consistently use `meson.has_header_symbol()` to fix warnings for
    features not yet available in Meson 0.61, which is our minimum
    required version.
  - Add another patch that makes use use `--fatal-meson-warnings` so
    that such warnings will cause the build to fail.
  - Fix a bug that made GIT-VERSION-GEN always return tags as version.
  - Adapt the approach we use to populate the project and distribution
    tarball versions.
  - Link to v1: https://lore.kernel.org/r/20250113-b4-pks-meson-additions-v1-0-97f6a93f691d@pks.im

Changes in v3:
  - Fix a commit message typo.
  - Revamp how the distribution tarball is created so that we don't have
    to adapt `GIT-VERSION-GEN` for it.
  - Link to v2: https://lore.kernel.org/r/20250114-b4-pks-meson-additions-v2-0-8d7ec676cfd9@pks.im

Thanks!

Patrick

[1]: https://gitlab.com/gitlab-org/git/-/merge_requests/280
[2]: https://github.com/git/git/pull/1870

---
Patrick Steinhardt (11):
      GIT-VERSION-GEN: simplify computing the dirty marker
      GIT-VERSION-GEN: allow running without input and output files
      meson: populate project version via GIT-VERSION-GEN
      meson: fix dependencies for generated headers
      meson: wire up development environments
      meson: wire up generation of distribution archive
      meson: wire up fuzzers
      meson: make the CSPRNG backend configurable
      meson: fix compilation with Visual Studio
      ci: raise error when Meson generates warnings
      ci: wire up Visual Studio build with Meson

 .github/workflows/main.yml | 52 +++++++++++++++++++++++++++
 .gitlab-ci.yml             | 38 ++++++++++++++++++++
 GIT-VERSION-GEN            | 50 +++++++++++++++-----------
 ci/run-build-and-tests.sh  |  4 ++-
 meson.build                | 88 +++++++++++++++++++++++++++++++++++++---------
 meson_options.txt          |  4 +++
 oss-fuzz/meson.build       | 20 +++++++++++
 7 files changed, 218 insertions(+), 38 deletions(-)

Range-diff versus v2:

 1:  55d804eaaf =  1:  60298f9c26 GIT-VERSION-GEN: simplify computing the dirty marker
 2:  617527f489 =  2:  91d302da94 GIT-VERSION-GEN: allow running without input and output files
 3:  d1566ba566 !  3:  806c05dfb1 meson: populate project version via GIT-VERSION-GEN
    @@ Commit message
         meson: populate project version via GIT-VERSION-GEN
     
         The Git version for Meson is currently wired up manually. It can thus
    -    grow (and alread has grown) stale quite easily, as having multiple
    +    grow (and already has grown) stale quite easily, as having multiple
         sources of truth is never a good idea. This issue is mostly of cosmetic
         nature as we don't use the project version anywhere, and instead use the
         GIT-VERSION-GEN script to propagate the correct version into our build.
 4:  bf3063ff51 =  4:  dd3abd3dca meson: fix dependencies for generated headers
 5:  5ba393fa8e =  5:  cb78c1d7d3 meson: wire up development environments
 6:  f4e076bed7 <  -:  ---------- meson: wire up generation of distribution archive
 -:  ---------- >  6:  715da14a23 meson: wire up generation of distribution archive
 7:  4e30bf0bb6 =  7:  9c5b82dd45 meson: wire up fuzzers
 8:  af5ec69b3a =  8:  393ea8a671 meson: make the CSPRNG backend configurable
 9:  82ff90ff8b =  9:  6d1a2b1978 meson: fix compilation with Visual Studio
10:  f9d2f1b9f6 = 10:  3142fdab0b ci: raise error when Meson generates warnings
11:  c9d480ddc6 = 11:  6c339cd012 ci: wire up Visual Studio build with Meson

---
base-commit: 35a417ddf0eab983e4d5eb69e628aa198114bb05
change-id: 20250107-b4-pks-meson-additions-055c16b3052b


```

## Patrick Steinhardt, 2025-01-22 12:05

Subject: [PATCH v3 01/11] GIT-VERSION-GEN: simplify computing the dirty marker
Message-ID: <20250122-b4-pks-meson-additions-v3-1-5a51eb5d3dcd@pks.im>
URL: https://gitlist.dev/e/20250122-b4-pks-meson-additions-v3-1-5a51eb5d3dcd%40pks.im
In-Reply-To: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>

```
The GIT-VERSION-GEN script computes the version that Git is being built
from. When building from a commit with an unclean worktree it knows to
append "-dirty" to that version to indicate that there were custom
changes applied and that it isn't the exact same as that commit.

The dirtiness check is done manually via git-diff-index(1), which is
somewhat puzzling though: we already use git-describe(1) to compute the
version, which also knows to compute dirtiness via the "--dirty" flag.
But digging back in history explains why: the "-dirty" suffix was added
in 31e0b2ca81 (GIT 1.5.4.3, 2008-02-23), and git-describe(1) didn't yet
have support for "--dirty" back then.

Refactor the script to use git-describe(1). Despite being simpler, it
also results in a small speedup:

    Benchmark 1: git describe --dirty --match "v[0-9]*"
      Time (mean ± σ):      12.5 ms ±   0.3 ms    [User: 6.3 ms, System: 8.8 ms]
      Range (min … max):    12.0 ms …  13.5 ms    200 runs

    Benchmark 2: git describe --match "v[0-9]*" HEAD && git update-index -q --refresh && git diff-index --name-only HEAD --
      Time (mean ± σ):      17.9 ms ±   1.1 ms    [User: 8.8 ms, System: 14.4 ms]
      Range (min … max):    17.0 ms …  30.6 ms    148 runs

    Summary
      git describe --dirty --match "v[0-9]*" ran
        1.43 ± 0.09 times faster than git describe --match "v[0-9]*" && git update-index -q --refresh && git diff-index --name-only HEAD --

While the speedup doesn't really matter on Unix-based systems, where
filesystem operations are typically fast, they do matter on Windows
where the commands take a couple hundred milliseconds. A quick and dirty
check on that system shows a speedup from ~800ms to ~400ms.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 GIT-VERSION-GEN | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index f2af817fea..b8b683b933 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -39,13 +39,9 @@ then
 			test -d "${GIT_DIR:-.git}" ||
 			test -f "$SOURCE_DIR"/.git;
 		} &&
-		VN=$(git -C "$SOURCE_DIR" describe --match "v[0-9]*" HEAD 2>/dev/null) &&
+		VN=$(git -C "$SOURCE_DIR" describe --dirty --match="v[0-9]*" 2>/dev/null) &&
 		case "$VN" in
 		*$LF*) (exit 1) ;;
-		v[0-9]*)
-			git -C "$SOURCE_DIR" update-index -q --refresh
-			test -z "$(git -C "$SOURCE_DIR" diff-index --name-only HEAD --)" ||
-			VN="$VN-dirty" ;;
 		esac
 	then
 		VN=$(echo "$VN" | sed -e 's/-/./g');

-- 
2.48.1.321.gbf1f004a4a.dirty


```

## Patrick Steinhardt, 2025-01-22 12:05

Subject: [PATCH v3 02/11] GIT-VERSION-GEN: allow running without input and output files
Message-ID: <20250122-b4-pks-meson-additions-v3-2-5a51eb5d3dcd@pks.im>
URL: https://gitlist.dev/e/20250122-b4-pks-meson-additions-v3-2-5a51eb5d3dcd%40pks.im
In-Reply-To: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>

```
The GIT-VERSION-GEN script requires an input file containing formatting
directives to be replaced as well as an output file that will get
overwritten in case the file contents have changed. When computing the
project version for Meson we don't want to have either though:

  - We only want to compute the version without anything else, but don't
    have an input file that would match that exact format. While we
    could of course introduce a new file just for that usecase, it feels
    suboptimal to add another file every time we want to have a slightly
    different format for versioned data.

  - The computed version needs to be read from stdout so that Meson can
    wire it up for the project.

Extend the script to handle both usecases by recognizing `--format=` as
alternative to providing an input path and by writing to stdout in case
no output file was given.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 GIT-VERSION-GEN | 44 +++++++++++++++++++++++++++++---------------
 1 file changed, 29 insertions(+), 15 deletions(-)

diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index b8b683b933..9d201a98fd 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -5,21 +5,29 @@ DEF_VER=v2.48.0
 LF='
 '
 
-if test "$#" -ne 3
+if test "$#" -lt 2 || test "$#" -gt 3
 then
-    echo >&2 "USAGE: $0 <SOURCE_DIR> <INPUT> <OUTPUT>"
+    echo >&2 "USAGE: $0 <SOURCE_DIR> (--format=<STRING>|<INPUT>) [<OUTPUT>]"
     exit 1
 fi
 
 SOURCE_DIR="$1"
-INPUT="$2"
-OUTPUT="$3"
 
-if ! test -f "$INPUT"
-then
-	echo >&2 "Input is not a file: $INPUT"
-	exit 1
-fi
+case "$2" in
+--format=*)
+	INPUT="${2#--format=}"
+	;;
+*)
+	if ! test -f "$2"
+	then
+		echo >&2 "Input is not a file: $2"
+		exit 1
+	fi
+	INPUT=$(cat "$2")
+	;;
+esac
+
+OUTPUT="$3"
 
 # Protect us from reading Git version information outside of the Git directory
 # in case it is not a repository itself, but embedded in an unrelated
@@ -74,19 +82,25 @@ read GIT_MAJOR_VERSION GIT_MINOR_VERSION GIT_MICRO_VERSION GIT_PATCH_LEVEL trail
 $(echo "$GIT_VERSION" 0 0 0 0 | tr '.a-zA-Z-' ' ')
 EOF
 
-sed -e "s|@GIT_VERSION@|$GIT_VERSION|" \
+REPLACED=$(printf "%s" "$INPUT" | sed -e "s|@GIT_VERSION@|$GIT_VERSION|" \
 	-e "s|@GIT_MAJOR_VERSION@|$GIT_MAJOR_VERSION|" \
 	-e "s|@GIT_MINOR_VERSION@|$GIT_MINOR_VERSION|" \
 	-e "s|@GIT_MICRO_VERSION@|$GIT_MICRO_VERSION|" \
 	-e "s|@GIT_PATCH_LEVEL@|$GIT_PATCH_LEVEL|" \
 	-e "s|@GIT_BUILT_FROM_COMMIT@|$GIT_BUILT_FROM_COMMIT|" \
 	-e "s|@GIT_USER_AGENT@|$GIT_USER_AGENT|" \
-	-e "s|@GIT_DATE@|$GIT_DATE|" \
-	"$INPUT" >"$OUTPUT".$$+
+	-e "s|@GIT_DATE@|$GIT_DATE|"
+)
 
-if ! test -f "$OUTPUT" || ! cmp "$OUTPUT".$$+ "$OUTPUT" >/dev/null
+if test -z "$OUTPUT"
 then
-	mv "$OUTPUT".$$+ "$OUTPUT"
+	printf "%s\n" "$REPLACED"
 else
-	rm "$OUTPUT".$$+
+	printf "%s\n" "$REPLACED" >"$OUTPUT".$$+
+	if ! test -f "$OUTPUT" || ! cmp "$OUTPUT".$$+ "$OUTPUT" >/dev/null
+	then
+		mv "$OUTPUT".$$+ "$OUTPUT"
+	else
+		rm "$OUTPUT".$$+
+	fi
 fi

-- 
2.48.1.321.gbf1f004a4a.dirty


```

## Patrick Steinhardt, 2025-01-22 12:05

Subject: [PATCH v3 03/11] meson: populate project version via GIT-VERSION-GEN
Message-ID: <20250122-b4-pks-meson-additions-v3-3-5a51eb5d3dcd@pks.im>
URL: https://gitlist.dev/e/20250122-b4-pks-meson-additions-v3-3-5a51eb5d3dcd%40pks.im
In-Reply-To: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>

```
The Git version for Meson is currently wired up manually. It can thus
grow (and already has grown) stale quite easily, as having multiple
sources of truth is never a good idea. This issue is mostly of cosmetic
nature as we don't use the project version anywhere, and instead use the
GIT-VERSION-GEN script to propagate the correct version into our build.
But it is somewhat puzzling when `meson setup` announces to build an old
Git release.

There are a couple of alternatives for how to solve this:

  - We can keep the version undefined, but this makes Meson output
    "undefined" for the version, as well.

  - We can use GIT-VERSION-GEN to generate the version for us. At the
    point of configuring the project we haven't yet figured out host
    details though, and thus we didn't yet set up the shell environment.
    While not an issue for Unix-based systems, this would be an issue in
    Windows, where the shell typically gets provided via Git for Windows
    and thus requires some special setup.

  - We can pull the default version out of GIT-VERSION-GEN and move it
    into its own file. This likely requires some adjustments for scripts
    that bump the version, but allows Meson to read the version from
    that file trivially.

Pick the second option and use GIT-VERSION-GEN as it gives us the most
accurate version. In order to fix the bootstrapping issue on Windows
systems we simply set the version to 'unknown' in case no shell was
found. As the version is only of cosmetic value this isn't really much
of an issue.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 meson.build | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 7361eb2eaa..213998986e 100644
--- a/meson.build
+++ b/meson.build
@@ -170,7 +170,14 @@
 
 project('git', 'c',
   meson_version: '>=0.61.0',
-  version: 'v2.47.GIT',
+  # The version is only of cosmetic nature, so if we cannot find a shell yet we
+  # simply don't set up a version at all. This may be the case for example on
+  # Windows systems, where we first have to bootstrap the host environment.
+  version: find_program('sh', required: false).found() ? run_command(
+    'GIT-VERSION-GEN', meson.current_source_dir(), '--format=@GIT_VERSION@',
+    capture: true,
+    check: true,
+  ).stdout().strip() : 'unknown',
 )
 
 fs = import('fs')

-- 
2.48.1.321.gbf1f004a4a.dirty


```

## Patrick Steinhardt, 2025-01-22 12:05

Subject: [PATCH v3 04/11] meson: fix dependencies for generated headers
Message-ID: <20250122-b4-pks-meson-additions-v3-4-5a51eb5d3dcd@pks.im>
URL: https://gitlist.dev/e/20250122-b4-pks-meson-additions-v3-4-5a51eb5d3dcd%40pks.im
In-Reply-To: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>

```
We generate a couple of headers from our documentation. These headers
are added to the libgit sources, but two of them aren't used by the
library, but instead by our builtins. This can cause parallel builds to
fail because the builtin object may be compiled before the header was
generated.

Fix the issue by adding both "config-list.h" and "hook-list.h" to the
list of builtin sources. While "command-list.h" is generated similarly,
it is used by "help.c" and thus part of the libgit sources indeed.

Reported-by: Evan Martin <evan.martin@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 meson.build | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/meson.build b/meson.build
index 213998986e..4053024dad 100644
--- a/meson.build
+++ b/meson.build
@@ -487,6 +487,13 @@ libgit_sources = [
   'xdiff/xutils.c',
 ]
 
+libgit_sources += custom_target(
+  input: 'command-list.txt',
+  output: 'command-list.h',
+  command: [shell, meson.current_source_dir() + '/generate-cmdlist.sh', meson.current_source_dir(), '@OUTPUT@'],
+  env: script_environment,
+)
+
 builtin_sources = [
   'builtin/add.c',
   'builtin/am.c',
@@ -614,14 +621,7 @@ builtin_sources = [
   'builtin/write-tree.c',
 ]
 
-libgit_sources += custom_target(
-  input: 'command-list.txt',
-  output: 'command-list.h',
-  command: [shell, meson.current_source_dir() + '/generate-cmdlist.sh', meson.current_source_dir(), '@OUTPUT@'],
-  env: script_environment,
-)
-
-libgit_sources += custom_target(
+builtin_sources += custom_target(
   output: 'config-list.h',
   command: [
     shell,
@@ -632,7 +632,7 @@ libgit_sources += custom_target(
   env: script_environment,
 )
 
-libgit_sources += custom_target(
+builtin_sources += custom_target(
   input: 'Documentation/githooks.txt',
   output: 'hook-list.h',
   command: [

-- 
2.48.1.321.gbf1f004a4a.dirty


```

## Patrick Steinhardt, 2025-01-22 12:05

Subject: [PATCH v3 05/11] meson: wire up development environments
Message-ID: <20250122-b4-pks-meson-additions-v3-5-5a51eb5d3dcd@pks.im>
URL: https://gitlist.dev/e/20250122-b4-pks-meson-additions-v3-5-5a51eb5d3dcd%40pks.im
In-Reply-To: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>

```
The Meson build system is able to wire up development environments. The
intent is to make build artifacts of the project available. This is
typically used to export e.g. paths to linkable libraries, which isn't
all that interesting in our context given that we don't have an official
library interface.

But what we can use this mechanism for is to expose the built Git
executables as well as the build directory. This allows users to play
around with the built Git version in the devenv, and allows them to
execute our test scripts directly with the built distribution.

Wire up this feature, which can then be used via `meson devenv` in the
build directory.

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

diff --git a/meson.build b/meson.build
index 4053024dad..ab4f229436 100644
--- a/meson.build
+++ b/meson.build
@@ -1939,6 +1939,14 @@ configure_file(
   configuration: build_options_config,
 )
 
+# Development environments can be used via `meson devenv -C <builddir>`. This
+# allows you to execute test scripts directly with the built Git version and
+# puts the built version of Git in your PATH.
+devenv = environment()
+devenv.set('GIT_BUILD_DIR', meson.current_build_dir())
+devenv.prepend('PATH', meson.current_build_dir() / 'bin-wrappers')
+meson.add_devenv(devenv)
+
 summary({
   'curl': curl.found(),
   'expat': expat.found(),

-- 
2.48.1.321.gbf1f004a4a.dirty


```

## Patrick Steinhardt, 2025-01-22 12:05

Subject: [PATCH v3 06/11] meson: wire up generation of distribution archive
Message-ID: <20250122-b4-pks-meson-additions-v3-6-5a51eb5d3dcd@pks.im>
URL: https://gitlist.dev/e/20250122-b4-pks-meson-additions-v3-6-5a51eb5d3dcd%40pks.im
In-Reply-To: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>

```
Meson knows to generate distribution archives via `meson dist`. In
addition to generating the archive itself, this target also knows to
compile and execute tests from that archive, which helps to ensure that
the result is an adequate drop-in replacement for the versioned project.

While this already works as-is, one omission is that we don't propagate
the commit that this is built from into the resulting archive. This can
be fixed though by adding a distribution script that propagates the
version into the "version" file, which GIT-VERSION-GEN knows to read if
present.

Use GIT-VERSION-GEN to populate that file. As the script is executed in
the build directory, not in the directory where we generate the archive,
we have to use a shell to resolve the "MESON_DIST_ROOT" environment
variable.

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

diff --git a/meson.build b/meson.build
index ab4f229436..a59072edf5 100644
--- a/meson.build
+++ b/meson.build
@@ -1947,6 +1947,19 @@ devenv.set('GIT_BUILD_DIR', meson.current_build_dir())
 devenv.prepend('PATH', meson.current_build_dir() / 'bin-wrappers')
 meson.add_devenv(devenv)
 
+# Generate the 'version' file in the distribution tarball. This is used via
+# `meson dist -C <builddir>` to populate the source archive with the Git
+# version that the archive is being generated from.
+meson.add_dist_script(
+  shell,
+  '-c',
+  '"$1" "$2" "$3" --format="@GIT_VERSION@" "$MESON_DIST_ROOT/version"',
+  'GIT-VERSION-GEN',
+  shell,
+  meson.current_source_dir() / 'GIT-VERSION-GEN',
+  meson.current_source_dir(),
+)
+
 summary({
   'curl': curl.found(),
   'expat': expat.found(),

-- 
2.48.1.321.gbf1f004a4a.dirty


```

## Patrick Steinhardt, 2025-01-22 12:05

Subject: [PATCH v3 07/11] meson: wire up fuzzers
Message-ID: <20250122-b4-pks-meson-additions-v3-7-5a51eb5d3dcd@pks.im>
URL: https://gitlist.dev/e/20250122-b4-pks-meson-additions-v3-7-5a51eb5d3dcd%40pks.im
In-Reply-To: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>

```
Meson does not yet know to build our fuzzers. Introduce a new build
option "fuzzers" and wire up the fuzzers in case it is enabled. Adapt
our CI jobs so that they build the fuzzers by default.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/run-build-and-tests.sh |  3 ++-
 meson.build               |  4 ++++
 meson_options.txt         |  2 ++
 oss-fuzz/meson.build      | 20 ++++++++++++++++++++
 4 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 76667a1277..6c828c3b75 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -53,7 +53,8 @@ case "$jobname" in
 *-meson)
 	group "Configure" meson setup build . \
 		--warnlevel 2 --werror \
-		--wrap-mode nofallback
+		--wrap-mode nofallback \
+		-Dfuzzers=true
 	group "Build" meson compile -C build --
 	if test -n "$run_tests"
 	then
diff --git a/meson.build b/meson.build
index a59072edf5..052bd80ac4 100644
--- a/meson.build
+++ b/meson.build
@@ -1906,6 +1906,10 @@ if get_option('tests')
   subdir('t')
 endif
 
+if get_option('fuzzers')
+  subdir('oss-fuzz')
+endif
+
 subdir('bin-wrappers')
 if get_option('docs') != []
   subdir('Documentation')
diff --git a/meson_options.txt b/meson_options.txt
index 89b01bad04..34ba679cf9 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -95,3 +95,5 @@ option('tests', type: 'boolean', value: true,
   description: 'Enable building tests. This requires Perl, but is separate from the "perl" option such that you can build tests without Perl features enabled.')
 option('test_output_directory', type: 'string',
   description: 'Path to the directory used to store test outputs')
+option('fuzzers', type: 'boolean', value: false,
+  description: 'Enable building fuzzers.')
diff --git a/oss-fuzz/meson.build b/oss-fuzz/meson.build
new file mode 100644
index 0000000000..ed79665501
--- /dev/null
+++ b/oss-fuzz/meson.build
@@ -0,0 +1,20 @@
+fuzz_programs = [
+  'fuzz-commit-graph.c',
+  'fuzz-config.c',
+  'fuzz-credential-from-url-gently.c',
+  'fuzz-date.c',
+  'fuzz-pack-headers.c',
+  'fuzz-pack-idx.c',
+  'fuzz-parse-attr-line.c',
+  'fuzz-url-decode-mem.c',
+]
+
+foreach fuzz_program : fuzz_programs
+  executable(fs.stem(fuzz_program),
+    sources: [
+      'dummy-cmd-main.c',
+      fuzz_program,
+    ],
+    dependencies: [libgit, common_main],
+  )
+endforeach

-- 
2.48.1.321.gbf1f004a4a.dirty


```

## Patrick Steinhardt, 2025-01-22 12:05

Subject: [PATCH v3 08/11] meson: make the CSPRNG backend configurable
Message-ID: <20250122-b4-pks-meson-additions-v3-8-5a51eb5d3dcd@pks.im>
URL: https://gitlist.dev/e/20250122-b4-pks-meson-additions-v3-8-5a51eb5d3dcd%40pks.im
In-Reply-To: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>

```
The CSPRNG backend is not configurable in Meson and isn't quite
discoverable, either. Make it configurable and add the actual backend
used to the summary.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 meson.build       | 28 +++++++++++++++++++++-------
 meson_options.txt |  2 ++
 2 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/meson.build b/meson.build
index 052bd80ac4..22dcd4aeee 100644
--- a/meson.build
+++ b/meson.build
@@ -1332,6 +1332,7 @@ if not meson.is_cross_build() and fs.exists('/dev/tty')
   libgit_c_args += '-DHAVE_DEV_TTY'
 endif
 
+csprng_backend = get_option('csprng_backend')
 https_backend = get_option('https_backend')
 sha1_backend = get_option('sha1_backend')
 sha1_unsafe_backend = get_option('sha1_unsafe_backend')
@@ -1343,7 +1344,7 @@ if https_backend == 'auto' and security_framework.found()
   https_backend = 'CommonCrypto'
 endif
 
-openssl_required = 'openssl' in [https_backend, sha1_backend, sha1_unsafe_backend, sha256_backend]
+openssl_required = 'openssl' in [csprng_backend, https_backend, sha1_backend, sha1_unsafe_backend, sha256_backend]
 openssl = dependency('openssl', required: openssl_required, default_options: ['default_library=static'])
 if https_backend == 'auto' and openssl.found()
   https_backend = 'openssl'
@@ -1428,18 +1429,30 @@ else
   error('Unhandled SHA256 backend ' + sha256_backend)
 endif
 
-if compiler.has_header_symbol('stdlib.h', 'arc4random_buf')
+# Backends are ordered to reflect our preference for more secure and faster
+# ones over the ones that are less so.
+if csprng_backend in ['auto', 'arc4random'] and compiler.has_header_symbol('stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random')
   libgit_c_args += '-DHAVE_ARC4RANDOM'
-elif compiler.has_header_symbol('bsd/stdlib.h', 'arc4random_buf')
+  csprng_backend = 'arc4random'
+elif csprng_backend in ['auto', 'arc4random_bsd'] and compiler.has_header_symbol('bsd/stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random_bsd')
   libgit_c_args += '-DHAVE_ARC4RANDOM_BSD'
-elif compiler.has_function('getrandom', prefix: '#include <sys/random.h>')
+  csprng_backend = 'arc4random_bsd'
+elif csprng_backend in ['auto', 'getrandom'] and compiler.has_header_symbol('sys/random.h', 'getrandom', required: csprng_backend == 'getrandom')
   libgit_c_args += '-DHAVE_GETRANDOM'
-elif compiler.has_function('getentropy', prefix: '#include <unistd.h>')
+  csprng_backend = 'getrandom'
+elif csprng_backend in ['auto', 'getentropy'] and compiler.has_header_symbol('unistd.h', 'getentropy', required: csprng_backend == 'getentropy')
   libgit_c_args += '-DHAVE_GETENTROPY'
-elif compiler.has_function('RtlGenRandom', prefix: '#include <windows.h>\n#include <ntsecapi.h>')
+  csprng_backend = 'getentropy'
+elif csprng_backend in ['auto', 'rtlgenrandom'] and compiler.has_header_symbol('ntsecapi.h', 'RtlGenRandom', prefix: '#include <windows.h>', required: csprng_backend == 'rtlgenrandom')
   libgit_c_args += '-DHAVE_RTLGENRANDOM'
-elif openssl.found()
+  csprng_backend = 'rtlgenrandom'
+elif csprng_backend in ['auto', 'openssl'] and openssl.found()
   libgit_c_args += '-DHAVE_OPENSSL_CSPRNG'
+  csprng_backend = 'openssl'
+elif csprng_backend in ['auto', 'urandom']
+  csprng_backend = 'urandom'
+else
+  error('Unsupported CSPRNG backend: ' + csprng_backend)
 endif
 
 if get_option('runtime_prefix')
@@ -1977,6 +1990,7 @@ summary({
 }, section: 'Auto-detected features')
 
 summary({
+  'csprng': csprng_backend,
   'https': https_backend,
   'sha1': sha1_backend,
   'sha1_unsafe': sha1_unsafe_backend,
diff --git a/meson_options.txt b/meson_options.txt
index 34ba679cf9..5429022f30 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -47,6 +47,8 @@ option('regex', type: 'feature', value: 'auto',
   description: 'Use the system-provided regex library instead of the bundled one.')
 
 # Backends.
+option('csprng_backend', type: 'combo', value: 'auto', choices: ['auto', 'arc4random', 'arc4random_bsd', 'getrandom', 'getentropy', 'rtlgenrandom', 'openssl', 'urandom'],
+  description: 'The backend to use for generating cryptographically-secure pseudo-random numbers.')
 option('https_backend', type: 'combo', value: 'auto', choices: ['auto', 'openssl', 'CommonCrypto', 'none'],
   description: 'The HTTPS backend to use when connecting to remotes.')
 option('sha1_backend', type: 'combo', choices: ['openssl', 'block', 'sha1dc', 'CommonCrypto'], value: 'sha1dc',

-- 
2.48.1.321.gbf1f004a4a.dirty


```

## Patrick Steinhardt, 2025-01-22 12:05

Subject: [PATCH v3 09/11] meson: fix compilation with Visual Studio
Message-ID: <20250122-b4-pks-meson-additions-v3-9-5a51eb5d3dcd@pks.im>
URL: https://gitlist.dev/e/20250122-b4-pks-meson-additions-v3-9-5a51eb5d3dcd%40pks.im
In-Reply-To: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>

```
The Visual Studio compiler defaults to C89 unless explicitly asked to
use a different version of the C standard. We don't specify any C
standard at all though in our Meson build, and consequently compiling
Git fails:

    ...\git\git-compat-util.h(14): fatal error C1189: #error:  "Required C99 support is in a test phase.  Please see git-compat-util.h for more details."

Fix the issue by specifying the project's C standard. Funny enough,
specifying C99 does not work because apparently, `__STDC_VERSION__` is
not getting defined in that version at all. Instead, we have to specify
C11 as the project's C standard, which is also done in our CMake build
instructions.

We don't want to generally enforce C11 though, as our requiremets only
state that a C99 compiler is required. In fact, we don't even require
plain C99, but rather the GNU variant thereof.

Meson allows us to handle this case rather easily by specifying
"gnu99,c11", which will cause it to fall back to C11 in case GNU C99 is
unsupported. This feature has only been introduced with Meson 1.3.0
though, and we support 0.61.0 and newer. In case we use such an oldish
version though we fall back to requiring GNU99 unconditionally. This
means that Windows essentially requires Meson 1.3.0 and newer when using
Visual Studio, but I doubt that this is ever going to be a real problem.

Tested-by: M Hickford <mirth.hickford@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 meson.build | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/meson.build b/meson.build
index 22dcd4aeee..af7ca042b9 100644
--- a/meson.build
+++ b/meson.build
@@ -178,6 +178,14 @@ project('git', 'c',
     capture: true,
     check: true,
   ).stdout().strip() : 'unknown',
+  default_options: [
+    # Git requires C99 with GNU extensions, which of course isn't supported by
+    # MSVC. Funny enough, C99 doesn't work with MSVC either, as it has only
+    # learned to define __STDC_VERSION__ with C11 and later. We thus require
+    # GNU C99 and fall back to C11. Meson only learned to handle the fallback
+    # with version 1.3.0, so on older versions we use GNU C99 unconditionally.
+    'c_std=' + (meson.version().version_compare('>=1.3.0') ? 'gnu99,c11' : 'gnu99'),
+  ],
 )
 
 fs = import('fs')

-- 
2.48.1.321.gbf1f004a4a.dirty


```

## Patrick Steinhardt, 2025-01-22 12:05

Subject: [PATCH v3 10/11] ci: raise error when Meson generates warnings
Message-ID: <20250122-b4-pks-meson-additions-v3-10-5a51eb5d3dcd@pks.im>
URL: https://gitlist.dev/e/20250122-b4-pks-meson-additions-v3-10-5a51eb5d3dcd%40pks.im
In-Reply-To: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>

```
Meson prints warnings in several cases, like for example when using a
feature supported by the current version of Meson, but not yet supported
by the minimum required version as declared by the project. These
warnings will not cause the setup to fail by default, which makes it
quite easy to miss them.

Improve this by passing `--fatal-meson-warnings` to `meson setup` so
that our CI jobs will fail on warnings.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 ci/run-build-and-tests.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index 6c828c3b75..964322055f 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -52,6 +52,7 @@ esac
 case "$jobname" in
 *-meson)
 	group "Configure" meson setup build . \
+		--fatal-meson-warnings \
 		--warnlevel 2 --werror \
 		--wrap-mode nofallback \
 		-Dfuzzers=true

-- 
2.48.1.321.gbf1f004a4a.dirty


```

## Patrick Steinhardt, 2025-01-22 12:05

Subject: [PATCH v3 11/11] ci: wire up Visual Studio build with Meson
Message-ID: <20250122-b4-pks-meson-additions-v3-11-5a51eb5d3dcd@pks.im>
URL: https://gitlist.dev/e/20250122-b4-pks-meson-additions-v3-11-5a51eb5d3dcd%40pks.im
In-Reply-To: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>

```
Add a new job to GitHub Actions and GitLab CI that builds and tests
Meson-based builds with Visual Studio.

A couple notes:

  - While the build job is mandatory, the test job is marked as "manual"
    on GitLab so that it doesn't run by default. We already have a bunch
    of Windows-based jobs, and the computational overhead that these
    cause is simply out of proportion to run the test suite twice.

    The same isn't true for GitHub as I could not find a way to make a
    subset of jobs manually triggered.

  - We disable Perl. This is because we pick up Perl from Git for
    Windows, which outputs different paths ("/c/" instead of "C:\") than
    what we expect in our tests.

  - We don't use the Git for Windows SDK. Instead, the build only
    depends on Visual Studio, Meson and Git for Windows. All the other
    dependencies like curl, pcre2 and zlib get pulled in and compiled
    automatically by Meson and thus do not have to be provided by the
    system.

  - We open-code "ci/run-test-slice.sh". This is because we only have
    direct access to PowerShell, so we manually implement the logic.
    There is an upstream pull request for the Meson build system [1] to
    implement test slicing in Meson directly.

  - We don't process test artifacts for failed CI jobs. This is done to
    keep down prerequisites to a minimum.

All tests are passing.

[1]: https://github.com/mesonbuild/meson/pull/14092

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 .github/workflows/main.yml | 52 ++++++++++++++++++++++++++++++++++++++++++++++
 .gitlab-ci.yml             | 38 +++++++++++++++++++++++++++++++++
 2 files changed, 90 insertions(+)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 900be9957a..7f55f8b3a9 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -248,6 +248,58 @@ jobs:
       with:
         name: failed-tests-windows-vs-${{ matrix.nr }}
         path: ${{env.FAILED_TEST_ARTIFACTS}}
+
+  windows-meson-build:
+    name: win+Meson build
+    needs: ci-config
+    if: needs.ci-config.outputs.enabled == 'yes'
+    runs-on: windows-latest
+    concurrency:
+      group: windows-meson-build-${{ github.ref }}
+      cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }}
+    steps:
+    - uses: actions/checkout@v4
+    - uses: actions/setup-python@v5
+    - name: Set up dependencies
+      shell: pwsh
+      run: pip install meson ninja
+    - name: Setup
+      shell: pwsh
+      run: meson setup build -Dperl=disabled
+    - name: Compile
+      shell: pwsh
+      run: meson compile -C build
+    - name: Upload build artifacts
+      uses: actions/upload-artifact@v4
+      with:
+        name: windows-meson-artifacts
+        path: build
+  windows-meson-test:
+    name: win+Meson test
+    runs-on: windows-latest
+    needs: [ci-config, windows-meson-build]
+    strategy:
+      fail-fast: false
+      matrix:
+        nr: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
+    concurrency:
+      group: windows-meson-test-${{ matrix.nr }}-${{ github.ref }}
+      cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }}
+    steps:
+    - uses: actions/checkout@v4
+    - uses: actions/setup-python@v5
+    - name: Set up dependencies
+      shell: pwsh
+      run: pip install meson ninja
+    - name: Download build artifacts
+      uses: actions/download-artifact@v4
+      with:
+        name: windows-meson-artifacts
+        path: build
+    - name: Test
+      shell: pwsh
+      run: meson test -C build --list | Select-Object -Skip 1 | Select-String .* | Group-Object -Property { $_.LineNumber % 10 } | Where-Object Name -EQ ${{ matrix.nr }} | ForEach-Object { meson test -C build --no-rebuild --print-errorlogs $_.Group }
+
   regular:
     name: ${{matrix.vector.jobname}} (${{matrix.vector.pool}})
     needs: ci-config
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 9254e01583..4976e18a05 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -149,6 +149,44 @@ test:mingw64:
     - git-sdk/usr/bin/bash.exe -l -c 'ci/print-test-failures.sh'
   parallel: 10
 
+.msvc-meson:
+  tags:
+    - saas-windows-medium-amd64
+  before_script:
+    - choco install -y git meson ninja openssl
+    - Import-Module $env:ChocolateyInstall\helpers\chocolateyProfile.psm1
+    - refreshenv
+    # The certificate store for Python on Windows is broken and fails to fetch
+    # certificates, see https://bugs.python.org/issue36011. This seems to
+    # mostly be an issue with how the GitLab image is set up as it is a
+    # non-issue on GitHub Actions. Work around the issue by importing
+    # cetrificates manually.
+    - Invoke-WebRequest https://curl.haxx.se/ca/cacert.pem -OutFile cacert.pem
+    - openssl pkcs12 -export -nokeys -in cacert.pem -out certs.pfx -passout "pass:"
+    - Import-PfxCertificate -CertStoreLocation Cert:\LocalMachine\Root -FilePath certs.pfx
+
+build:msvc-meson:
+  extends: .msvc-meson
+  stage: build
+  script:
+    - meson setup build -Dperl=disabled
+    - meson compile -C build
+  artifacts:
+    paths:
+      - build
+
+test:msvc-meson:
+  extends: .msvc-meson
+  stage: test
+  when: manual
+  timeout: 6h
+  needs:
+    - job: "build:msvc-meson"
+      artifacts: true
+  script:
+    - meson test -C build --list | Select-Object -Skip 1 | Select-String .* | Group-Object -Property { $_.LineNumber % $Env:CI_NODE_TOTAL + 1 } | Where-Object Name -EQ $Env:CI_NODE_INDEX | ForEach-Object { meson test -C build --no-rebuild --print-errorlogs $_.Group }
+  parallel: 10
+
 test:fuzz-smoke-tests:
   image: ubuntu:latest
   stage: test

-- 
2.48.1.321.gbf1f004a4a.dirty


```

## Junio C Hamano, 2025-01-22 21:42

Subject: Re: [PATCH v3 00/11] meson: a couple of additions
Message-ID: <xmqqsepav82v.fsf@gitster.g>
URL: https://gitlist.dev/e/xmqqsepav82v.fsf%40gitster.g
In-Reply-To: <20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im>

```
Patrick Steinhardt <ps@pks.im> writes:

> this small patch series backfills in a couple of missing features into
> Meson. It also improves test coverage of our Meson-based CI jobs so that
> we compile with Meson with Visual Studio and compile fuzzers. CI runs
> for GitLab and GitHub can be found at [1] and [2], respectively.
>
> The series is built on top of fbe8d3079d (Git 2.48, 2025-01-10) with
> ps/meson-weak-sha1-build at 6a0ee54f9a (meson: provide a summary of
> configured backends, 2024-12-30) merged into it.

This round (especially removal of some code from GIT-VERSION-GEN)
looked good to me.  As there is another topic in flight that builds
on this one, if there is nothing else that is glaringly wrong, let's
mark the topic for 'next' soonish.

Thanks.

```