Hi,

this patch series contains a couple of more-or-less random cleanups and
improvements for Meson that I have accumulated over the last two months.

Changes in v2:
  - Fix an off-by-one error for test slices used in GitHub Workflows.
  - Link to v1: https://lore.kernel.org/r/20250703-b4-pks-meson-cleanups-v1-0-2804c2932abe@pks.im

Thanks!

Patrick

To: git@vger.kernel.org
Cc: Ramsay Jones <ramsay@ramsayjones.plus.com>
Cc: irecca.kun@gmail.com
Cc: Eli Schwartz <eschwartz@gentoo.org>
Cc: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>

--- b4-submit-tracking ---
# This section is used internally by b4 prep for tracking purposes.
{
  "series": {
    "revision": 2,
    "change-id": "20250703-b4-pks-meson-cleanups-f53858d694f3",
    "prefixes": [],
    "history": {
      "v1": [
        "20250703-b4-pks-meson-cleanups-v1-0-2804c2932abe@pks.im"
      ]
    }
  }
}

When Python features are enabled we search both for a native and
non-native version of Python. This is wrong though: we don't use Python
in our build process, so there is no need to search for it in the first
place.

There is one location where we use the native version of Python, namely
when deciding whether or not we want to wire up git-p4(1). This check is
invalid though, as we shouldn't check for the build host to have Python,
but for the target host.

Fix this invalid check to use the non-native version of Python and stop
searching for a native version of Python altogether.

Signed-off-by: Patrick Steinhardt <ps@pks.im>

The value for the 'https' backend option is printed twice: once via the
summary of auto-detected features and once via our summary of backends.
Drop it from the former summary.

Signed-off-by: Patrick Steinhardt <ps@pks.im>

The summary of auto-detected features prints a boolean for every option
to tell the user whether or not the feature has been auto-enabled or
not. This summary can be improved though, as in some cases this boolean
is derived from a dependency. So if we pass in the dependency directly,
then Meson knows to both print a boolean and, if the dependency was
found, it also prints a version number.

Adapt the code accordingly and enable `bool_yn` so that actual booleans
are formatted similarly to dependencies. Before this change:

  Auto-detected features
    benchmarks      : true
    curl            : true
    expat           : true
    gettext         : true
    gitweb          : true
    iconv           : true
    pcre2           : true
    perl            : true
    python          : true

And after this change, we now see the version numbers as expected:

  Auto-detected features
    benchmarks      : YES
    curl            : YES 8.14.1
    expat           : YES 2.7.1
    gettext         : YES
    gitweb          : YES
    iconv           : YES
    pcre2           : YES 10.44
    perl            : YES
    python          : YES

Note that this change also enables colorization of the boolean options,
green for "YES" and red for "NO".

Signed-off-by: Patrick Steinhardt <ps@pks.im>

The `manpage_target` variable isn't used at all, and the `manpage_path`
variable is only used in a single location. Remove the former variable
and inline the latter.

Signed-off-by: Patrick Steinhardt <ps@pks.im>

In 4cba20f (meson: prefer shell at "/bin/sh", 2025-04-25) we have
addressed an issue where the shell path embedded into Git was looked up
via PATH, which easily led to unportable shell paths other than the
usual "/bin/sh" location. The fix was to simply add '/bin' to the search
path explicitly, which made us prefer that directory over the PATH-based
lookup.

This fix causes issues on MINGW64 though, which uses Windows-style
paths. "/bin" is not an absolute Windows-style path, but Meson expects
the directories to be absolute. This leads to the following error:

    meson.build:248:15: ERROR: Search directory /bin is not an absolute path.

Fix this by instead searching for both '/bin/sh' and 'sh', which also
causes us to prefer '/bin/sh' over a PATH-based lookup. Meson does
accept that path alright on MINGW64, even though it's not an absolute
Windows-style path, either.

Furthermore, this continues to work alright with cross-files, as well,
in case one wants to explicitly override the shell path:

    $ meson setup build
    ...
      Runtime executable paths
        perl       : /nix/store/gy10hw004rl2xfbfq41vnw0yb1w8rvbl-perl-5.40.0/bin/perl
        python     : /nix/store/sd81bvmch7njdpwx3lkjslixcbj5mivz-python3-3.13.4/bin/python3
        shell      : /bin/sh

    $ cat >cross.ini <<-EOF
    [binaries]
    sh = '/nix/store/94lg0shvsfc845zy8gnflvpqxxiyijbz-bash-interactive-5.2p37/bin/bash'
    EOF

    $ meson setup build --cross-file=cross.ini --wipe
    ...
      Runtime executable paths
        perl       : /nix/store/gy10hw004rl2xfbfq41vnw0yb1w8rvbl-perl-5.40.0/bin/perl
        python     : /nix/store/sd81bvmch7njdpwx3lkjslixcbj5mivz-python3-3.13.4/bin/python3
        shell      : /nix/store/94lg0shvsfc845zy8gnflvpqxxiyijbz-bash-interactive-5.2p37/bin/bash

Signed-off-by: Patrick Steinhardt <ps@pks.im>

In 837f637 (meson.build: correct setting of GIT_EXEC_PATH,
2025-05-19) we have fixed how we configure GIT_EXEC_PATH in some cases.
It was reported [1] though that this causes a new issue when overriding
libexecdir with `-Dlibexecdir=`:

    $ meson setup -Dprefix=/tmp/git -Dlibexecdir=libexec-different
    $ meson install
    $ /tmp/git/bin/git --exec-path
    /tmp/git/libexec-different
    $ /tmp/git/bin/git daemon
    git: 'daemon' is not a git command. See 'git --help'.

While we correctly propagate the libexecdir to Git's GIT_EXEC_PATH, we
forgot to append 'git-core'. Consequently, it cannot find its binaries
anymore.

Fix this issue by appending 'git-core' to libexecdir. With this, things
work as expected:

    $ meson install
    $ /tmp/git/bin/git --exec-path
    /tmp/git/libexec-different/git-core
    $ /tmp/git/bin/git daemon -h
    ...

[1]: <66fd343a-1351-4350-83eb-c797e47b7693@gmail.com>

Reported-by: irecca.kun@gmail.com
Based-on-patch-by: irecca.kun@gmail.com
Signed-off-by: Patrick Steinhardt <ps@pks.im>

Update subproject wrappers to newer versions by executing `meson wrap
update` in the project's root directory

Signed-off-by: Patrick Steinhardt <ps@pks.im>

As executing our test suite is notoriously slow on Windows we use matrix
jobs in our CI systems to slice up tests and run them via multiple jobs.
On Meson this is done with a comparatively complex PowerShell invocation
as Meson didn't yet have a native way to slice tests like this.

I have upstreamed a new `--slice` option [1] that addresses this use
case though, which has been merged and released with Meson 1.8. Both
GitLab and GitHub CI have Meson 1.8.2 available by now, so let's update
the jobs to use that new option.

[1]: mesonbuild/meson#14092

Signed-off-by: Patrick Steinhardt <ps@pks.im>