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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Junio C Hamano]

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.

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

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1137 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Junio C Hamano]

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?

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

[Patrick Steinhardt]

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

[PATCH 6/9] meson: wire up fuzzers

[Patrick Steinhardt]

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

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

[Junio C Hamano]

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.

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Junio C Hamano]

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.

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

[Patrick Steinhardt]

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

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

[Junio C Hamano]

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.

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

[Patrick Steinhardt]

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

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

[M Hickford]

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')
> 

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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                | 87 +++++++++++++++++++++++++++++++++++++---------
 meson_options.txt          |  4 +++
 oss-fuzz/meson.build       | 20 +++++++++++
 7 files changed, 219 insertions(+), 36 deletions(-)

Range-diff versus v1:

 1:  9cceb5db4d !  1:  a546dd43be GIT-VERSION-GEN: simplify computing the dirty marker
    @@ GIT-VERSION-GEN: then
      			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) &&
    ++		VN=$(git -C "$SOURCE_DIR" describe --dirty --match="v[0-9]*" 2>/dev/null) &&
      		case "$VN" in
      		*$LF*) (exit 1) ;;
     -		v[0-9]*)
 2:  00b9586887 <  -:  ---------- GIT-VERSION-GEN: move default version into a separate file
 -:  ---------- >  2:  3079bcc87a GIT-VERSION-GEN: allow running without input and output files
 -:  ---------- >  3:  aab1945e47 meson: populate project version via GIT-VERSION-GEN
 3:  a7712e6874 =  4:  782b9677c3 meson: fix dependencies for generated headers
 4:  0b30d76c7a =  5:  a9efaebe7b meson: wire up development environments
 5:  71081feccf !  6:  92913a6b20 meson: wire up generation of distribution archive
    @@ Metadata
      ## Commit message ##
         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.
    +    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
    @@ Commit message
         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.
    +    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 adapt it to honor the "MESON_DIST_ROOT" environment variable.
     
         Signed-off-by: Patrick Steinhardt <ps@pks.im>
     
      ## GIT-VERSION-GEN ##
    -@@ GIT-VERSION-GEN: then
    - 	exit 1
    - fi
    +@@ GIT-VERSION-GEN: case "$2" in
    + esac
      
    + OUTPUT="$3"
     +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
    -@@ GIT-VERSION-GEN: 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}" ||
    + # in case it is not a repository itself, but embedded in an unrelated
     
      ## meson.build ##
     @@ meson.build: devenv.set('GIT_BUILD_DIR', meson.current_build_dir())
    @@ meson.build: devenv.set('GIT_BUILD_DIR', meson.current_build_dir())
     +  shell,
     +  meson.current_source_dir() / 'GIT-VERSION-GEN',
     +  meson.current_source_dir(),
    -+  meson.current_source_dir() / 'GIT-VERSION-FILE.in',
    ++  '--format=@GIT_VERSION@',
     +  'version',
     +)
     +
 6:  5dd6be9be7 =  7:  4bde8aee4c meson: wire up fuzzers
 7:  88e2935e52 !  8:  2f33403322 meson: make the CSPRNG backend configurable
    @@ meson.build: else
      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')
    @@ meson.build: else
        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')
    ++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_function('getentropy', prefix: '#include <unistd.h>', required: csprng_backend == 'getentropy')
    ++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_function('RtlGenRandom', prefix: '#include <windows.h>\n#include <ntsecapi.h>', required: csprng_backend == 'rtlgenrandom')
    ++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'
 8:  f6ee13d6dc <  -:  ---------- meson: fix compilation with Visual Studio
 -:  ---------- >  9:  d56a24e15a meson: fix compilation with Visual Studio
 -:  ---------- > 10:  c624f1d554 ci: raise error when Meson generates warnings
 9:  946c31f452 = 11:  c7f7e2309a ci: wire up Visual Studio build with Meson

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

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

[Patrick Steinhardt]

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..b8b683b9337e5771e14a2cfb84022a11489bb432 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.0.257.gd3603152ad.dirty

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

[Patrick Steinhardt]

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 b8b683b9337e5771e14a2cfb84022a11489bb432..9d201a98fd2766911544225c62159cbfe8dff5fe 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.0.257.gd3603152ad.dirty

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

[Toon Claes]

Patrick Steinhardt <ps@pks.im> writes:

> 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 b8b683b9337e5771e14a2cfb84022a11489bb432..9d201a98fd2766911544225c62159cbfe8dff5fe 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.0.257.gd3603152ad.dirty

I was considering to suggest to have GIT-VERSION-GEN accept --stdin for
$INPUT and have it read from stdin instead of passing the format as an
argument, but looking at the following commits I agree with your
approach.

--
Toon

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

[Patrick Steinhardt]

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 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 7361eb2eaad422e7a6c6ed95d275615836c21cdb..213998986e8942cee080fc5b9b675860cf429ecc 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.0.257.gd3603152ad.dirty

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

[Toon Claes]

Patrick Steinhardt <ps@pks.im> writes:

> The Git version for Meson is currently wired up manually. It can thus
> grow (and alread has grown) stale quite easily, as having multiple

Small typo: alread -> already


-- 
Toon

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

[Patrick Steinhardt]

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 213998986e8942cee080fc5b9b675860cf429ecc..4053024dadeb0aafc067784b976ed3bd96171181 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.0.257.gd3603152ad.dirty

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

[Patrick Steinhardt]

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 4053024dadeb0aafc067784b976ed3bd96171181..ab4f229436d3070de692a24c3a196a79d214b46f 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.0.257.gd3603152ad.dirty

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

[Patrick Steinhardt]

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 adapt it to honor the "MESON_DIST_ROOT" environment variable.

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

diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 9d201a98fd2766911544225c62159cbfe8dff5fe..f6764555ce6fd46ca4ddbaebb3b48809707e60f8 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -28,6 +28,10 @@ case "$2" in
 esac
 
 OUTPUT="$3"
+if test -n "$OUTPUT" && test -n "$MESON_DIST_ROOT"
+then
+    OUTPUT="$MESON_DIST_ROOT/$OUTPUT"
+fi
 
 # 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
diff --git a/meson.build b/meson.build
index ab4f229436d3070de692a24c3a196a79d214b46f..5d074134195e5689d08da5597f0859d9623d014e 100644
--- a/meson.build
+++ b/meson.build
@@ -1947,6 +1947,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(),
+  '--format=@GIT_VERSION@',
+  'version',
+)
+
 summary({
   'curl': curl.found(),
   'expat': expat.found(),

-- 
2.48.0.257.gd3603152ad.dirty

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

[Toon Claes]

Patrick Steinhardt <ps@pks.im> writes:

> 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 adapt it to honor the "MESON_DIST_ROOT" environment variable.

I failed to understand why you couldn't pass the absolute path of the
output file to GIT-VERSION-GEN. So I looked at the previous version of
this patch, and it seems you explain better over there.

I was testing things locally and tried this line for the last argument
to the script:

  run_command(shell, '-c', 'echo $MESON_DIST_ROOT', capture: true, check: true).stdout().strip() / 'version',

And I think I understand it better now. Meson does not execute this when
you run `meson dist`, but when it (re)generates it's build files. At
that stage $MESON_DIST_ROOT is not set.

It's unfortunate we have to learn GIT-VERSION-GEN about the
$MESON_DIST_ROOT environment variable, but I don't see any other way.


--
Toon

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

[Patrick Steinhardt]

On Tue, Jan 21, 2025 at 01:37:23PM +0100, Toon Claes wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > 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 adapt it to honor the "MESON_DIST_ROOT" environment variable.
> 
> I failed to understand why you couldn't pass the absolute path of the
> output file to GIT-VERSION-GEN. So I looked at the previous version of
> this patch, and it seems you explain better over there.
> 
> I was testing things locally and tried this line for the last argument
> to the script:
> 
>   run_command(shell, '-c', 'echo $MESON_DIST_ROOT', capture: true, check: true).stdout().strip() / 'version',
> 
> And I think I understand it better now. Meson does not execute this when
> you run `meson dist`, but when it (re)generates it's build files. At
> that stage $MESON_DIST_ROOT is not set.
> 
> It's unfortunate we have to learn GIT-VERSION-GEN about the
> $MESON_DIST_ROOT environment variable, but I don't see any other way.

Hm. Thinking about it a bit more there is an alternative:

    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(),
    )

I think this is a much better solution as it doesn't require us to teach
the script about `MESON_DIST_ROOT`.

Patrick

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

[Patrick Steinhardt]

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 5d074134195e5689d08da5597f0859d9623d014e..95baada74af8f7731867e7075d9986b32a034ff4 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 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

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

[Patrick Steinhardt]

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 95baada74af8f7731867e7075d9986b32a034ff4..e50ccac5c9f6d310d8c9f83d893ea802b5827252 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')
@@ -1976,6 +1989,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

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

[Patrick Steinhardt]

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 e50ccac5c9f6d310d8c9f83d893ea802b5827252..30d7a894904dfe86bedb2a7a8de25529502403e5 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.0.257.gd3603152ad.dirty

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

[Patrick Steinhardt]

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 6c828c3b755153dab179f73346e7124bda49c90e..964322055f5db0eae0c794b543664e24ae4249f7 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.0.257.gd3603152ad.dirty

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

[Toon Claes]

Patrick Steinhardt <ps@pks.im> writes:

> 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 6c828c3b755153dab179f73346e7124bda49c90e..964322055f5db0eae0c794b543664e24ae4249f7 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.0.257.gd3603152ad.dirty

Cool, this would have caught me trying to use `fs.copyfile`:

    $ meson setup build --fatal-meson-warnings

    # ... [snip] ...

    ../meson.build:1466: WARNING: Project targets '>=0.61.0' but uses feature introduced in '0.64.0': fs.copyfile.

    ../meson.build:1466:3: ERROR: Fatal warnings enabled, aborting


(I missed that warning)

--
Toon

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

[Patrick Steinhardt]

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

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

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

>      -		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) &&
>     ++		VN=$(git -C "$SOURCE_DIR" describe --dirty --match="v[0-9]*" 2>/dev/null) &&

Ahh, you only said "found the issue" and it was building suspense
;-)

It turns out that I wasn't affected while testing because my build
infrastructure around "make" computes the version string by itself
independently from what "make/GIT-VERSION-GEN" does, and stuffs it
in the 'version' file, before running "make install".  And that is
why I didn't notice the breakage before Ramsay reported X-<.

This fix looks obviously good.

Thanks.

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Patrick Steinhardt]

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

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

[Junio C Hamano]

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.