MAINT: specify C17 as C standard in meson.build

[ngoldbaum]

Reference Issues/PRs

#28977

What does this implement/fix? Explain your changes.

Bumps the required C standard. Doing this as a PR to see how impactful it is in CI.

Any other comments?

[github-actions]

✔️ Linting Passed

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

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

[ngoldbaum]

Hmm, the pylatest_conda_mkl_no_openmp job failed with this error:

FAILED: sklearn/neighbors/_ball_tree.cpython-312-darwin.so.p/sklearn/neighbors/_ball_tree.pyx.c
  cython -M --fast-fail -3 '-X language_level=3' '-X boundscheck=False' '-X wraparound=False' '-X initializedcheck=False' '-X nonecheck=False' '-X cdivision=True' '-X profile=False' --include-dir /Users/runner/work/1/s/build/cp312 sklearn/neighbors/_ball_tree.pyx -o sklearn/neighbors/_ball_tree.cpython-312-darwin.so.p/sklearn/neighbors/_ball_tree.pyx.c

  Error compiling Cython file:
  ------------------------------------------------------------
  ...
  from libc.string cimport memcpy

  import numpy as np
  import warnings

  from ..metrics._dist_metrics cimport (
  ^
  ------------------------------------------------------------

  sklearn/neighbors/_binary_tree.pxi:148:0: 'sklearn/metrics/_dist_metrics.pxd' not found

Not sure why the C standard would matter for that. If that's familiar to anyone reading along as unrelated to this PR please let me know, otherwise I'll try to reproduce this...

[lesteve]

I re-triggered the failing run that should fix the CI. You are right that this is another instance of #28820 I need to take a closer look to fix this.

[lesteve]

LGTM if CI is green

[adrinjalali]

@jeremiedbb not sure if we need to have a similar change on the conda-forge side.

[jeremiedbb]

I don't think that we need it for 1.5 since 1.5 only supports python <= 3.12

[lesteve]

Turns out this broke Pyodide build (Pyodide build is not run in PRs unless explicitly asked for via a commit message) see #29013 for more details. Insights more than welcome!

This likely will affect Scipy inside Pyodide as well.

[ngoldbaum]

This likely will affect Scipy inside Pyodide as well.

Unless I'm misunderstanding the discussions about this, it looks like scipy currently doesn't build under pyodide because of missing fortran support. That must be why it was missed when scipy moved to C17.

[agriyakhetarpal]

SciPy does build under Pyodide, though: https://github.com/pyodide/pyodide/tree/main/packages/scipy (out-of-tree support isn't implemented yet, however)

[ngoldbaum]

Thanks for clarifying! I wasn't aware of the package in pyodide, just going off of issues on the scipy issue tracker.

It looks like pyodide is packaging scipy 1.12.0, but Ralf changed the C standard to C17 in the 1.14 dev cycle, so presumably the pyodide package would hit this whenever it gets updated or whenever someone tried to add pyodide CI to scipy.

[agriyakhetarpal]

Ah, I do have plans to add out-of-tree Pyodide support to SciPy, but given the complexity, it's the last on my list right now, and other Scientific Python packages are being prepared first. I am not sure how these C standard changes will be navigated, because an extensive amount of patching is required already for the in-tree builds...