TST: enable --fatal-meson-warnings for all tests

[dnicolodi]

The test packages also work as examples. I think it is better to make sure that they are as correct as possible.

[dnicolodi]

@freakboy3742 Can you please verify that this is correct? I have no experience with building for iOS. Thanks!

[freakboy3742]

This will be a valid invocation for strip; but I've never needed to call strip on any iOS program, so I'm not sure where I'd be looking to verify this works. Have you got an example in mind that would be using this?

[dnicolodi]

Thanks! Maybe calling strip in this way and checking that the resulting binary is still working would be a way to verify that this does something that at least is not harmful. The reason I'm adding this is that, without it, meson emits a warning https://github.com/mesonbuild/meson-python/actions/runs/15653996265/job/44102572727#step:10:1105

[freakboy3742]

Understood - I'll investigate and report back shortly (likely tomorrow my time, at this point)

[dnicolodi]

I think the correct way to get to the strip utility is to run something like xcrun --sdk iphoneos -f strip. The system strip may not work for iOS binaries.

[freakboy3742]

They didn't. Those binaries are a shim provided as part of a Python distribution for iOS, specifically to avoid issues with having definitions for variables like CC that have a space in them. In a lot of older build tools, there's an implied assumption that you can split a compile command at the first space... which isn't true if you're using xcrun. Those shims also do a bunch of handling around IPHONEOS_DEPLOYMENT_TARGET handling, etc.

As for pre-calling xcrun and caching the result - that could work. The value returned will change over time, but not over the lifespan of a single build, so caching on a per-build basis should be fine. xcrun should always be on the path (as long as the user has Xcode installed), so that part should be reliable enough.

[dnicolodi]

They didn't. Those binaries are a shim provided as part of a Python distribution for iOS

I didn't pick up on this. Maybe this should be noted in a comment somewhere. Would it be sensible to extend these shims to provide strip too? In this way, all the logic for finding the build tools would be maintained in the same place and only one place would need to be updated if the SDK changes.

[freakboy3742]

It couldn't hurt to add a shim for strip. The complication is that I'm not sure if we'll be able to backport that shim to Python 3.13, since it would be a new feature... but I can manually add it to the support package build (as those aren't currently maintained by CPython itself), so in practice, it would be available.

[dnicolodi]

It does not really matter if it is not available even if we say its should be in the cross file, as long as no one is using it 🙂 Adding it to the support package build would be my preferred solution, unless you see an issue with this.

[eli-schwartz]

WARNING: Cross file does not specify strip binary, result will not be stripped.

As noted by the warning, the consequences of it not being available are not earth-shattering.

Quite likely, an appstore upload will do server-side stripping anyway.

[dnicolodi]

There are still test failures. These are the tests where we set the RPATH via explicit linker arguments. We stop doing that in #724 thus I don't think it is necessary to find a way to allow these warnings to do not make the tests fail.