✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

_{Generated for commit: f7b6895. Link to the linter CI: here}

Apologies for the force push; I wanted to modify the commit message to include the wheel builds and see if CI is green. No more amendments here.

I need to update the conda lock files to bump the Meson version there and fix the Azure Pipelines errors (pylatest_conda_forge_mkl and Ubuntu_Jammy_Jellyfish pymin_conda_forge_openblas_ubuntu_2204). Let me do that in a subsequent commit.

I bumped all the conda-related lockfiles with the command python build_tools/update_environments_and_lock_files.py and with conda-lock==2.5.6 in 4e4c710. I'll use pip-tools to bump the Meson version in the free-threaded lockfile, build_tools/azure/cpython_free_threaded_lock.txt, as well in a moment – I can't get the Docker command running properly for some reason, investigating the problem.

I found that the Docker command does not work on linux/arm64 – context: I am on an M-series macOS machine (it might be worth documenting that). I think the Deadsnakes PPA might not have aarch64 builds yet, and I haven't checked. I tried it with QEMU via --platform linux/amd64, which makes it work, but it doesn't add anything new to the lockfile either, even when I added meson as a dependency in the list of dependencies in build_tools/azure/cpython_free_threaded_requirements.txt – meson stays at 1.4.1 instead of getting bumped to 1.5.0. I'm not that all familiar with pip-tools, so, please let me know if it's okay to keep it as such for now – IMO it shouldn't be a problem; the fix was just for the Emscripten builds, and regular builds seem okay.

Thanks a lot for the PR, and great effort with the lock-files, even more though because lock-files are something that even scikit-learn maintainers are slightly afraid to touch sometimes 😉!

I have to say I am a bit reluctant to require the very latest version of meson as I imagine it has downsides and I am not sure about the upsides but I'd love to hear about the latter if there are some. My understanding of #28977 (comment) was that CPython is compiled with c11 so I think we should be fine with c11 until there is a CPython version that is compiled with c17.

The main downside I can think of is for Linux distribution packagers that may not have the very latest version of meson available or similarly people that use their system meson. For example Ubuntu 24.04 has Meson 1.3.2 according to this. Having said that I am actually not sure that they use their system meson to build the scikit-learn package, a quick look at Fedora and Ubuntu seems to indicate that they don't (i.e. there is no build dependency on meson)?

For completeness, right now we require meson >= 1.1.0 (released April 2023). 1.5.0 has been released in July 2024.

On build dependencies, we haven't cared much about system versions. For instance, we have required very recent cython versions at times to fix issues in the repo.

So I'm okay with requiring a very recent meson version here.

Thanks for the inputs! Part of why I wish to, and the only upside in bumping the meson version, is that it fixes the related error that was faced earlier for the Pyodide builds when bumping the C standard – which I tested by adding [pyodide] in 4e4c710's commit message, and the workflow passed. As a first-time contributor, I'm not aware of the problems downstream Linux packagers for scikit-learn may have faced in the past, but FWIW meson-python version 0.16.0 declares a dependency on meson from PyPI as noted here: https://github.com/mesonbuild/meson-python/blob/4f50bf27ef5282f8147c1df073d27859bda5e890/pyproject.toml#L35-L41. It should pick up the latest version of meson, i.e., version 1.5.0 automatically, but I'm not sure if the build system prefers a system-level installation of meson or this pip-installable one.

The associated page in the meson-python documentation suggests adding meson as a build-time dependency in pyproject.toml in addition to meson-python to ensure that the latest versions are picked, which I would be happy to do (and update the lockfiles again) and hopefully, nothing should break :)

I added meson>=1.5.0 as a build-time dependency and updated all sets of lockfiles. I had to add an explicit mention of meson>=1.5.0 in the free-threaded requirements file to make pip-tools not pick meson==1.4.1. This increments the minimum meson version requirement across all CI workflows.

f7b6895 triggers the wheel builder and the Pyodide CI job; let's see if they pass.

I guess my main question is "what do we gain by using c_std=c17" in meson.build? My feeling right now is "not much" but I would be curious to hear more details.

As such I feel there is no strong advantage and there are some potential use cases that are going to be affected negatively (because we need to require meson>=1.5.0 for Pyodide) even if how much these use cases exist is somewhat uncertain and probably not that likely.

Ah, I understand your question better now; thanks for the clarification, @lesteve. One straightforward benefit is that you can use the latest and greatest features across compiled code when writing it and aim to reduce technical debt, of course, and I've found that compiler versions in various Linux distros have support as well: Ubuntu 20.04 with GCC 9.4 + Clang 10; Ubuntu 22.04 with GCC 11.4 + Clang 14, Debian 10 with GCC 8.3 + Clang 7, Rocky Linux 8 with GCC 8.5 + Clang 16, NVIDIA Jetson Linux has GCC 9.3 (unsure about Clang there). Visual Studio 2019 (MSVC 16.8) and later support it for Windows.

As for the downsides or use cases that can be affected, I know that there can be some across Python packaging land, such as a probable bump to the macOS deployment target to 10.14 from the current 10.9, but this too depends on how much of the language features you use, and is not a problem anyway because these macOS versions will be outdated very soon if they haven't been already. But other than that, I'm not sure – it does look like it's relevant for the Py3.13t free-threaded builds based on the issue description in gh-28977 🤔 I'll tag @ngoldbaum as the author of said issue, who would know of the advantages and impacts more and better than I do :)

The reason this is related to free threading is technically a bug in Cython IMO but fixing it will be hard.

Recently CPython started using static_assert in internal headers. In some build configurations more easily triggered in the free-threading build, Cython will include these internal headers so downstream code will try to compile it. If they specify they use C99, they'll see a compiler error because C99 doesn't have static_assert.

This could be fixed by CPython using a different portable macro or by cython no longer including CPython internals. We've generally found the easiest thing to do is bump from C99 to C11 or C17. CPython itself uses C11 these days.

Thanks @ngoldbaum for the details, this matched my understanding that we needed c11 to match what CPython is doing. Using c11 is what we are already doing see

So with my worried maintainer hat on, not doing anything for now still feels like the most cost effective option: "if it's not broken don't fix it".

So far I haven't really seen any argument that using c17 is something that will bring enough advantages to justify doing any work about it. More than happy to hear other opinions though!

So with my worried maintainer hat on, not doing anything for now still feels like the most cost effective option: "if it's not broken don't fix it".

So far I haven't really seen any argument that using c17 is something that will bring enough advantages to justify doing any work about it. More than happy to hear other opinions though!

I agree with that. If c11 is enough for the free-threaded build I would stick with it, and reconsider later if it allows significant improvements in the existing code base or new features.

OK let's close this one and revisit if/when there is a good reason to require Meson>=1.5 or requiring c17.

And by the way looking back at this PR, the timeout in the no-OpenMP build with Meson 1.5 was already here, see #29546 for the ongoing investigation.

Thanks anyway for the PR @agriyakhetarpal even if we did not end up merging it, really appreciated 🙏!

No worries, thanks for all the context! I agree this should be done when C17 is required, and I'll be happy to contribute in other ways.