Support building against free-threaded Python on Windows

[rgommers]

Free-threaded builds of Python (see PEP 703) are new for CPython 3.13. cibuildwheel just gained support for it, and as seen in numpy/numpy#26512, building wheels with cibuildwheel, Meson and meson-python works on Linux, but currently fails on Windows. The issue presents as (from pypa/cibuildwheel#1657 (comment)):

Program python found: YES (C:\Users\runneradmin\AppData\Local\Temp\build-env-_csx0kis\Scripts\python.exe)
  Could not find Python3 library 'C:\\Users\\runneradmin\\AppData\\Local\\pypa\\cibuildwheel\\Cache\\nuget-cpython\\python-freethreaded.3.13.0-b1\\tools\\libs\\python313.lib'
  Run-time dependency python found: NO (tried sysconfig)

The issue is that the library name on Windows changed from python313.lib to python313t.lib. The fix is for Meson to determine whether it's building for a free-threaded CPython, and then change the shared library name to include the t. Here to be exact:

meson/mesonbuild/dependencies/python.py

Line 286 in 8d92487

libpath = Path('libs') / f'python{vernum}.lib'

I have a fix in progress.

We should add CI for free-threaded CPython as well on Linux, Windows and macOS - but I assume only when a pre-built Python interpreter is available for some CI config. For Windows there are installers on python.org for 3.13.0b1, for macOS not yet. This looks like the right place to add a Windows CI job:

meson/.github/workflows/msys2.yml

Line 95 in 8d92487

- name: Install pypy3 on x86_64

If someone can confirm that it'd be desirable to have a CI job for this already and if so whether msys2.yml is the right place, that'd be great.

[eli-schwartz]

We have:

• GHA for Windows msys2 (using python from mingw itself)
• azure jobs for Windows MSVC, that use UsePythonVersion (currently installs 3.7)

The question I suppose is whether you want to test the mingw toolchain as provided by msys2, or test MSVC. In theory we can do both.

The real question, I guess, is whether we want to:

• run the entire meson testsuite including python module tests under the freethreaded build, in which case we should probably move one or more existing jobs over?
• only test building python modules against freethreaded builds, without necessarily testing that meson can run with free-threading, in which case we need to do one of two things:
  • make test cases/python/8 different python versions/ detect a differently named python executable on $PATH, which in the case of pypy is... -Dpython=pypy3
  • use path/to/freethreaded/python3 run_project_tests.py --only python/8

My intuition is that given freethreaded python is still in such an early stage (not in a released python version yet), it's not worth the time to aggressively test all of meson under it, and that we should just extend the matrix with another "path to python binary" test. What do you think?

[rgommers]

My intuition is that given freethreaded python is still in such an early stage (not in a released python version yet), it's not worth the time to aggressively test all of python under it, and that we should just extend the matrix with another "path to python binary" test. What do you think?

I agree with this. It's quite early, and given that Meson itself is written in pure Python everything is meant to work without changes - if it doesn't, it's most likely a bug in CPython rather than in Meson.

only test building python modules against freethreaded builds

That is what I had in mind indeed - that's the current need, and covers the missing feature that triggered opening this issue.

use path/to/freethreaded/python3 run_project_tests.py --only python/8

That sounds like the way to go to me.

The question I suppose is whether you want to test the mingw toolchain as provided by msys2, or test MSVC. In theory we can do both.

I suspect one is enough for now - I'd choose MSVC, since that's the more commonly used compiler by Python packages.

[QuLogic]

Was this closed by #13338 (and thus ready to start using since 1.5.0)?

Edit: I see the original comment there was to keep this open as tests weren't added yet, but I guess the latter question stands: it should work (at least potentially) in 1.5.0?

[rgommers]

@QuLogic the support for free-threaded Python on Windows is included in 1.5.0 (older versions work fine on all other platforms). I chose to leave this issue open because I need to still add a Windows CI job.

Also probably relevant for your needs: I still need to update the vendored Meson in NumPy before NumPy will build on Windows (xref numpy#15). EDIT: this was done, NumPy main works and nightlies are available at https://anaconda.org/scientific-python-nightly-wheels/numpy; numpy 2.1.3 and 2.2.0 will be the first releases to contain the fix.

[rgommers]

The question I suppose is whether you want to test the mingw toolchain as provided by msys2, or test MSVC. In theory we can do both.

I suspect one is enough for now - I'd choose MSVC, since that's the more commonly used compiler by Python packages.

gh-13851 reports and fixes a problem for MinGW, so let's see if we can do both flavors to avoid future regressions.