BLD: check f2py version and add comments on use of f2py as executable

meson.build

@@ -21,6 +21,8 @@ project(
 py3 = import('python').find_installation(pure: false)
 py3_dep = py3.dependency()
 
+min_numpy_version = '1.23.5'  # keep in sync with pyproject.toml
+
 # Emit a warning for 32-bit Python installs on Windows; users are getting
 # unexpected from-source builds there because we no longer provide wheels.
 is_windows = host_machine.system() == 'windows'

pyproject.toml

@@ -45,7 +45,7 @@ maintainers = [
 # release branches, see:
 #     https://scipy.github.io/devdocs/dev/core-dev/index.html#version-ranges-for-numpy-and-other-dependencies
 requires-python = ">=3.10"
-dependencies = ["numpy>=1.23.5"]
+dependencies = ["numpy>=1.23.5"]  # keep in sync with `min_numpy_version` in meson.build
 readme = "README.rst"
 classifiers = [
     "Development Status :: 5 - Production/Stable",

scipy/meson.build

@@ -145,6 +145,19 @@ fortranobject_dep = declare_dependency(
 )
 
 f2py = find_program('f2py')
+# It should be quite rare for the `f2py` executable to not be the one from
+# `numpy` installed in the Python env we are building for (unless we are
+# cross-compiling). If it is from a different env, that is still fine as long
+# as it's not too old. We are only using f2py as a code generator, and the
+# output is not dependent on platform or Python version (see gh-20612 for more
+# details).
+# This should be robust enough. If not, we can make this more complex, using
+# a fallback to `python -m f2py` rather than erroring out.
+f2py_version = run_command([f2py, '-v'], check: true).stdout().strip()
+if f2py_version.version_compare('<'+min_numpy_version)
+  error(f'Found f2py executable is too old: @f2py_version@')
+endif
+
 # Note: cannot handle .pyf.src or targets with #include's (due to no
 #       `depend_files` - see feature request at meson#8295)
 f2py_gen = generator(generate_f2pymod,