threads / patch / 62794

patch, 9 partsmeson: a couple of additions

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

## tl;dr

35 messages between Jan 13, 2025 and Jan 22, 2025. Diffs are folded; open one to read it.

replies: 34people: 4as markdown or json

Patrick Steinhardt· Jan 13, 2025, 08:33 UTC · lore
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· Jan 13, 2025, 08:33 UTC · re: Patrick Steinhardt · lore

[PATCH 1/9] GIT-VERSION-GEN: simplify computing the dirty marker

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(-)
Show changes to GIT-VERSION-GEN +1 −5
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· Jan 13, 2025, 08:33 UTC · re: Patrick Steinhardt · lore

[PATCH 2/9] GIT-VERSION-GEN: move default version into a separate file

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(-)
Show changes to 3 files +4 −3

GIT-VERSION, GIT-VERSION-GEN, meson.build

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
Junio C Hamano· Jan 13, 2025, 17:42 UTC · re: Patrick Steinhardt · lore

Re: [PATCH 2/9] GIT-VERSION-GEN: move default version into a separate file

Patrick Steinhardt <ps@pks.im> writes:
Show 8 quoted lines
>   - 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.

Eli Schwartz· Jan 13, 2025, 17:51 UTC · re: Junio C Hamano · lore

Re: [PATCH 2/9] GIT-VERSION-GEN: move default version into a separate file

On 1/13/25 12:42 PM, Junio C Hamano wrote:
Show 14 quoted lines
> 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
Patrick Steinhardt· Jan 14, 2025, 09:13 UTC · re: Eli Schwartz · lore

Re: [PATCH 2/9] GIT-VERSION-GEN: move default version into a separate file

On Mon, Jan 13, 2025 at 12:51:59PM -0500, Eli Schwartz wrote:
Show 22 quoted lines
> 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· Jan 13, 2025, 08:33 UTC · re: Patrick Steinhardt · lore

[PATCH 3/9] meson: fix dependencies for generated headers

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(-)
Show changes to meson.build +9 −9
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· Jan 13, 2025, 08:33 UTC · re: Patrick Steinhardt · lore

[PATCH 4/9] meson: wire up development environments

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(+)
Show changes to meson.build +8 −0
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· Jan 13, 2025, 08:33 UTC · re: Patrick Steinhardt · lore

[PATCH 6/9] meson: wire up fuzzers

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(-)
Show changes to 4 files +28 −1

ci/run-build-and-tests.sh, meson.build, meson_options.txt, oss-fuzz/meson.build

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
Junio C Hamano· Jan 13, 2025, 17:48 UTC · re: Patrick Steinhardt · lore

Re: [PATCH 6/9] meson: wire up fuzzers

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.
Patrick Steinhardt· Jan 14, 2025, 10:31 UTC · re: Junio C Hamano · lore

Re: [PATCH 6/9] meson: wire up fuzzers

On Mon, Jan 13, 2025 at 09:48:07AM -0800, Junio C Hamano wrote:
Show 11 quoted lines
> 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
Patrick Steinhardt· Jan 13, 2025, 08:33 UTC · re: Patrick Steinhardt · lore

[PATCH 5/9] meson: wire up generation of distribution archive

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(-)
Show changes to 2 files +18 −1

GIT-VERSION-GEN, meson.build

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
Junio C Hamano· Jan 13, 2025, 17:55 UTC · re: Patrick Steinhardt · lore

Re: [PATCH 5/9] meson: wire up generation of distribution archive

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?

Show 22 quoted lines
> 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?

Patrick Steinhardt· Jan 14, 2025, 09:14 UTC · re: Junio C Hamano · lore

Re: [PATCH 5/9] meson: wire up generation of distribution archive

On Mon, Jan 13, 2025 at 09:55:58AM -0800, Junio C Hamano wrote:
Show 10 quoted lines
> 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.
Show 29 quoted lines
> > 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· Jan 13, 2025, 08:33 UTC · re: Patrick Steinhardt · lore

[PATCH 7/9] meson: make the CSPRNG backend configurable

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(-)
Show changes to 2 files +21 −7

meson.build, meson_options.txt

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· Jan 13, 2025, 09:25 UTC · re: Patrick Steinhardt · lore

Re: [PATCH 7/9] meson: make the CSPRNG backend configurable

On Mon, Jan 13, 2025 at 09:33:40AM +0100, Patrick Steinhardt wrote:
Show 40 quoted lines
> 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· Jan 13, 2025, 17:59 UTC · re: Patrick Steinhardt · lore

Re: [PATCH 7/9] meson: make the CSPRNG backend configurable

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.
Show 28 quoted lines
> +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.
Patrick Steinhardt· Jan 14, 2025, 09:13 UTC · re: Junio C Hamano · lore

Re: [PATCH 7/9] meson: make the CSPRNG backend configurable

On Mon, Jan 13, 2025 at 09:59:53AM -0800, Junio C Hamano wrote:
Show 37 quoted lines
> 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
Junio C Hamano· Jan 14, 2025, 19:13 UTC · re: Patrick Steinhardt · lore

Re: [PATCH 7/9] meson: make the CSPRNG backend configurable

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· Jan 13, 2025, 08:33 UTC · re: Patrick Steinhardt · lore

[PATCH 8/9] meson: fix compilation with Visual Studio

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(+)
Show changes to meson.build +8 −0
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
M Hickford· Jan 13, 2025, 21:12 UTC · re: Patrick Steinhardt · lore

Re: [PATCH 8/9] meson: fix compilation with Visual Studio

On 2025-01-13 08:33, Patrick Steinhardt wrote:
Show 26 quoted lines
> 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>
Show 24 quoted lines
> ---
>   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· Jan 13, 2025, 08:33 UTC · re: Patrick Steinhardt · lore

[PATCH 9/9] ci: wire up Visual Studio build with Meson

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(+)
Show changes to 2 files +90 −0

.github/workflows/main.yml, .gitlab-ci.yml

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· Jan 22, 2025, 12:05 UTC · re: Patrick Steinhardt · lore

[PATCH v3 00/11] meson: a couple of additions

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· Jan 22, 2025, 12:05 UTC · re: Patrick Steinhardt · lore

[PATCH v3 01/11] GIT-VERSION-GEN: simplify computing the dirty marker

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(-)
Show changes to GIT-VERSION-GEN +1 −5
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· Jan 22, 2025, 12:05 UTC · re: Patrick Steinhardt · lore

[PATCH v3 02/11] GIT-VERSION-GEN: allow running without input and output files

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(-)
Show changes to GIT-VERSION-GEN +29 −15
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· Jan 22, 2025, 12:05 UTC · re: Patrick Steinhardt · lore

[PATCH v3 03/11] meson: populate project version via GIT-VERSION-GEN

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(-)
Show changes to meson.build +8 −1
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· Jan 22, 2025, 12:05 UTC · re: Patrick Steinhardt · lore

[PATCH v3 04/11] meson: fix dependencies for generated headers

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(-)
Show changes to meson.build +9 −9
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· Jan 22, 2025, 12:05 UTC · re: Patrick Steinhardt · lore

[PATCH v3 05/11] meson: wire up development environments

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(+)
Show changes to meson.build +8 −0
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· Jan 22, 2025, 12:05 UTC · re: Patrick Steinhardt · lore

[PATCH v3 06/11] meson: wire up generation of distribution archive

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(+)
Show changes to meson.build +13 −0
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· Jan 22, 2025, 12:05 UTC · re: Patrick Steinhardt · lore

[PATCH v3 07/11] meson: wire up fuzzers

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(-)
Show changes to 4 files +28 −1

ci/run-build-and-tests.sh, meson.build, meson_options.txt, oss-fuzz/meson.build

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· Jan 22, 2025, 12:05 UTC · re: Patrick Steinhardt · lore

[PATCH v3 08/11] meson: make the CSPRNG backend configurable

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(-)
Show changes to 2 files +23 −7

meson.build, meson_options.txt

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· Jan 22, 2025, 12:05 UTC · re: Patrick Steinhardt · lore

[PATCH v3 09/11] meson: fix compilation with Visual Studio

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(+)
Show changes to meson.build +8 −0
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· Jan 22, 2025, 12:05 UTC · re: Patrick Steinhardt · lore

[PATCH v3 10/11] ci: raise error when Meson generates warnings

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(+)
Show changes to ci/run-build-and-tests.sh +1 −0
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· Jan 22, 2025, 12:05 UTC · re: Patrick Steinhardt · lore

[PATCH v3 11/11] ci: wire up Visual Studio build with Meson

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(+)
Show changes to 2 files +90 −0

.github/workflows/main.yml, .gitlab-ci.yml

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· Jan 22, 2025, 21:42 UTC · re: Patrick Steinhardt · lore

Re: [PATCH v3 00/11] meson: a couple of additions

Patrick Steinhardt <ps@pks.im> writes:
Show 8 quoted lines
> 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.

← back to recent threads