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

[Patrick Steinhardt <ps@pks.im>]

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