Subject: Re: win+Meson test failures due to ps/build-meson-fixes-0130 topic?

From: Patrick Steinhardt <[email-masked]>
Date: Wed, 26 Feb 2025 10:15:50 +0100

On Wed, Feb 26, 2025 at 03:20:02AM -0500, Jeff King wrote:
> On Wed, Feb 26, 2025 at 02:46:53AM -0500, Jeff King wrote:
> 
> > I'd imagine that if I did a complete "rm -rf build && meson setup build"
> > it would work. But it's pretty lousy to have to do that preemptively
> > during a bisection.
> 
> Looks like this runs even deeper. On my Linux machine:
> 
>   $ git checkout origin/next
>   $ meson setup build
>   [...ok...]
>   $ meson compile -C build
>   [...ok...]
> 
>   $ git checkout origin/master
>   $ meson compile -C build
>   [...]
>   ../meson.build:215:35: ERROR: The `!=` operator of array does not accept objects of type str ()
>   FAILED: build.ninja
>   /usr/bin/meson --internal regenerate /home/peff/compile/git .
>   ninja: error: rebuilding 'build.ninja': subcommand failed
> 
>   $ rm -rf build
>   $ meson setup build
>   $ meson compile -C build
>   [...ok again...]
> 
> I'm hoping you can tell me I'm holding it wrong, and there's some way to
> do an incremental build when crossing these sorts of boundaries (without
> blowing away all of the build products).
> 
> I do at least use ccache which makes the "rm -rf" case a little less
> painful.

You're not holding it wrong. The problem is that this patch series
introduces a backwards-incompatible change to the "sane_tools_path"
option as it changes it from a string to an array, which makes Meson
hiccup. Once Meson is not considered to be experimental anymore we
should refrain from changing option types going forward, but until then
I consider it to be okayish to break things like this.

>From my point of view we can treat Meson as stable as soon as Git v2.49
is out. So from thereon, I will make sure to not include backwards
incompatible changes anymore.

Patrick