I commented on the issue. You should use --pre to get pre-build wheels for python3.12. This will improve the situation, but we do not yet have 32-bit wheels for 1.26-rc1. That was done in #24675 but the wheels are not generally available yet.

You may also need to set PIP_EXTRA_INDEX_URL.

The actual issue here is that MSVC for x86-64 is being used to try and build 32-bit Python extension modules:

C compiler for the host machine: cl (msvc 19.35.32217.1 "Microsoft (R) C/C++ Optimizing Compiler Version 19.35.32217.1 for x64")

To get past that problem, the 32-bit MSVC compiler must be activated so that it gets used for the whole build. The msdevshell GitHub Action is a convenient way of doing that, and is what we use in our own wheel build config:

This problem is specific to Windows + 32-bit Python, so I don't expect to see more of these issues once we upload win32 wheels.

I'll note that distutils didn't have this problem, because it could only worry about Python extension modules and hence default to the 32-bit compiler on a 64-bit OS when the user did not explicitly ask for that. Meson has many more languages to support, so compiler selection isn't going to be special-cased for the specific Python interpreter build you happen to be using.

Let's close this issue as soon as we have win32 wheels on PyPI for Python 3.12

This has been resolved. Thanks!

The actual issue here is that MSVC for x86-64 is being used to try and build 32-bit Python extension modules:

I just hit this trying to set up a 32 bit windows numpy development environment to run down an issue happening on CI.

I eventually found this thread via a google search but would have gotten here faster with a nicer error message.

@rgommers Is there a way for meson to detect that x64 MSVC is activated on x86 python and fail early?

also for anyone else trying to do this, I was able to build numpy with a 32 bit python in a VS command prompt after running vcvars32.bat.

The error message is pretty clear about the problem: Need python for x86_64, but found x86. The trouble is, it doesn't really tell you what you want to know here, which is how to avoid the problem. One way would be to amend the error message in Meson, if it can be made specific to Windows.

Since dependency('python') fails, there's not much we can do to introspect the found installation. One thing we could do is to check a symbol from Python.h first, e.g. there's this we could fish out:

/* The size of `uintptr_t', as computed by sizeof. */
#define SIZEOF_UINTPTR_T 8

Perhaps cc.sizeof('size_t') != SIZEOF_UINTPTR_T would work. The trouble is, to make sure we pick up the correct Python.h, we already need the py_dep object. Existing checks look like:

cc.sizeof('Py_intptr_t', dependencies: py_dep, prefix: '#include <Python.h>'))

So, doesn't look like there's anything we can check. I'll have a look at adding a sentence to the error message.

xref mesonbuild/meson#11435 for the most relevant upstream issue.