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.

[dnicolodi]

I think meson-python releases can happen more easily than CPython releases, thus applying fixes does not seem an issue, as long as we are informed of them. Another advantage is performance: not having the wrappers spares forking one extra sh processes which stays around for the duration of the execution (because the wrappers do not use exec) for each compilation command. Actually using xcrun to query the path to the compiler binaries two forks could be spared. Although, in practice this may be a pretty small performance penalty.

@rgommers What do yo think?

[rgommers]

It looks to me like the performance difference is going to be very small compared to the overall time it takes to build a wheel. So I'd go with the simplest solution, which is invoking the shims directly. Fixing a bug that may show up in a version of CPython that doesn't get bug fix releases anymore is years away, and if such a bug fix is needed, the unwrapping can then still be done.

[dnicolodi]

Yes, the performance considerations are moot. Still, a shim for strip does not yet exist and if we invoke xcrun directly for strip I don't see why we cannot do the same for all other compilation tools. I don't know what happens if meson-python writes a cross file that specifies a strip binary that does not exist.

[rgommers]

We can, the CPython shims just look a lot more complex.

Anyway, I am fine with that solution too if you prefer, any choice is valid here. Just my $2c that I'd make the minimal change only for strip here (maybe I'm just lazy:)).

[rgommers]

This strip wrapper change is now merged in gh-772. I'll leave this thread unresolved, since it's potentially interesting content also in the future.

[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.

[rgommers]

Enabling --fatal-meson-warnings by default does seem like a good idea.

[dnicolodi]

I'm not entirely happy with adding this function, but I didn't find a better way.

[rgommers]

This seems okay to me, I also can't think of something cleaner.

[dnicolodi]

@rgommers I think we will keep testing adding RPATH entries with linker arguments, thus I added a way to disable fatal meson warnings for selected packages. This is ready for another review.

[rgommers]

Overall this looks good to me. Two comments:

1. minor: it may be useful to reorder the commits so that the commit that adds --no-fatal-warnings to one test case comes before the main commit that enables --fatal-warnings. That way the test doesn't fail in the intermediate state, which might be helpful for future bisecting.
2. I am getting a failed test for test_wheel.py::test_cmake_subproject, see below

The full output isn't particularly helpful:

--------------------------------------------------------------------------------- Captured stdout setup ----------------------------------------------------------------------------------
+ meson setup /Users/rgommers/code/meson-python/tests/packages/cmake-subproject /Users/rgommers/code/meson-python/tests/packages/cmake-subproject/.mesonpy-wr4vkqp0 -Dbuildtype=release -Db_ndebug=if-release -Db_vscrt=md --fatal-meson-warnings --native-file=/Users/rgommers/code/meson-python/tests/packages/cmake-subproject/.mesonpy-wr4vkqp0/meson-python-native-file.ini
The Meson build system
Version: 1.7.99
Source dir: /Users/rgommers/code/meson-python/tests/packages/cmake-subproject
Build dir: /Users/rgommers/code/meson-python/tests/packages/cmake-subproject/.mesonpy-wr4vkqp0
Build type: native build
Project name: cmake-subproject
Project version: 1
C compiler for the host machine: cc (clang 15.0.0 "Apple clang version 15.0.0 (clang-1500.3.9.4)")
C linker for the host machine: cc ld64 1053.12
C++ compiler for the host machine: c++ (clang 15.0.0 "Apple clang version 15.0.0 (clang-1500.3.9.4)")
C++ linker for the host machine: c++ ld64 1053.12
Cython compiler for the host machine: cython (cython 3.1.0)
Host machine cpu family: aarch64
Host machine cpu: aarch64
Found pkg-config: YES (/Users/rgommers/mambaforge/bin/pkg-config) 0.29.2
Found CMake: /Users/rgommers/mambaforge/bin/cmake (4.1.2)
WARNING: CMake Toolchain: Failed to determine CMake compilers state

../meson.build:14:10: ERROR: Fatal warnings enabled, aborting

A full log can be found at /Users/rgommers/code/meson-python/tests/packages/cmake-subproject/.mesonpy-wr4vkqp0/meson-logs/meson-log.txt

Looking into that a bit more by building the test package locally shows:

Finding framework path by running:  c++ -v -E - 

Looking for framework cmaketest in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks
CMake binary for host machine is not cached
CMake binary missing from cross or native file, or env var undefined.
Trying a default CMake fallback at cmake
Found CMake: /Users/rgommers/mambaforge/bin/cmake (4.1.2)
Extracting basic cmake information
CMake Toolchain: Calling CMake once to generate the compiler state
Calling CMake (['/Users/rgommers/mambaforge/bin/cmake']) in /Users/rgommers/code/meson-python/tests/packages/cmake-subproject/build/meson-private/__CMake_compiler_info__ with:
  - "--trace-expand"
  - "--trace-format=json-v1"
  - "--no-warn-unused-cli"
  - "--trace-redirect=cmake_trace.txt"
  - "-G"
  - "Ninja"
  - "-DCMAKE_TOOLCHAIN_FILE=/Users/rgommers/code/meson-python/tests/packages/cmake-subproject/build/meson-private/__CMake_compiler_info__/CMakeMesonTempToolchainFile.cmake"
  - "."
WARNING: CMake Toolchain: Failed to determine CMake compilers state

meson.build:14:10: ERROR: Fatal warnings enabled, aborting

The contents of CMakeMesonTempToolchainFile.cmake are:

set(CMAKE_SIZEOF_VOID_P "8")
set(CMAKE_C_COMPILER "/usr/bin/cc")
set(CMAKE_CXX_COMPILER "/usr/bin/c++")
set(CMAKE_CYTHON_COMPILER "/Users/rgommers/mambaforge/bin/cython")

Not particularly instructive. I tried with conda-forge compilers as well, they get picked up correctly but end with the same error.

This can have various causes, see for example mesonbuild/meson#9431 and mesonbuild/meson#11521.

Adding --no-fatal-meson-warnings also to the CMake test is the easiest solution here.

[rgommers]

I don't really feel like getting to the bottom of that warning right now; it doesn't cause any problems in practice, and it seems to be related to not having an ObjC or Rust compiler installed say the linked issues.

[dnicolodi]

1. minor: it may be useful to reorder the commits so that the commit that adds --no-fatal-warnings to one test case comes before the main commit that enables --fatal-warnings. That way the test doesn't fail in the intermediate state, which might be helpful for future bisecting.

This does not really help as --no-fatal-meson-warnings is purely a meson-python test suite invention. The test would fail when adding that option as the handling of it is not in place and passing it to Meson would fail. This is a drawback of this approach I didn't think about before: the test packages cannot be built outside the test infrastructure without commenting out this option (unless we add handling for it to meson-python proper and not only to the test infrastructure).