Meson does not find `python` for x86 with gvsbuild on Windows

[doadin]

using github actions + actions/setup-python@v4 with: update-environment: true

I am using https://github.com/wingtk/gvsbuild to build https://github.com/pygobject/pycairo/blob/main/meson.build which has

pymod = import('python')
python = pymod.find_installation(get_option('python'), pure: false)

in the build error I get: "Need python for x86, but found x86_64"

if I delete all other python folder from the action runner in a step before the build process I get: Program python3 found: NO meson.build:16:15: ERROR: python3 not found

full action log can be found here: first error https://github.com/doadin/gvsbuild-release/actions/runs/8443809356/job/23128136908 second error https://github.com/doadin/gvsbuild-release/actions/runs/8446242953/job/23134712079

in the log for the first error you can see in the trace that x86 python is what is executing the command yet meson says "Need python for x86, but found x86_64". This seems to be a meson issue? however im not familiar with meson build system if this is a build file issue sorry.

[dnicolodi]

Something is wrong with your setup or with gvsbuild. Here https://github.com/doadin/gvsbuild-release/actions/runs/8443809356/job/23128136908#step:3:1 you install Python 3.10 for x86, but the meson setup fails find Python 3.12 for x86_64, here https://github.com/doadin/gvsbuild-release/actions/runs/8443809356/job/23128136908#step:7:22120

[dnicolodi]

in the log for the first error you can see in the trace that x86 python is what is executing the command

Where do you see that this?

[doadin]

@dnicolodi https://github.com/doadin/gvsbuild-release/actions/runs/8443809356/job/23128136908#step:7:22154 https://github.com/doadin/gvsbuild-release/actions/runs/8443809356/job/23128136908#step:7:22154

[doadin]

@dnicolodi like the very last line. " Command 'C:\hostedtoolcache\windows\Python\3.10.11\x86\python.exe "

[dnicolodi]

We would need to have a look at C:\gtk-build\build\Win32\release\pycairo\_gvsbuild-meson\meson-logs\meson-log.txt too see which Python environments Meson is considering and eventually why it is discarding the x86 one. For now this looks like a problem with build environment setup

[dnicolodi]

Also, meson-python has nothing to do with this.

[doadin]

@dnicolodi unless I am miss understanding the error it says the command being run starts with it calling Python\3.10.11\x86\python.exe which is the correct version. I supposed there could be a weird situation where python 3.12 is being used to start a Python\3.10.11\x86\python.exe process but even then Python\3.10.11\x86\python.exe is the process calling the meson build so that python should be the one found.

[doadin]

@dnicolodi sorry, was not sure where to report this but its a meson and python issue I thought maybe meson-python would be the place to report, I am not really familiar with meson in general.

[dnicolodi]

Python\3.10.11\x86\python.exe is the process calling the meson build so that python should be the one found.

There isn't a direct correspondence between the python used to run Meson and the python returned by import('python').find_installation().

[doadin]

@dnicolodi https://mesonbuild.com/Python-module.html "pymod.find_installation(name_or_path, ...) Find a python installation matching name_or_path.

That argument is optional, if not provided then the returned python installation will be the one used to run Meson."

Is this not what should be happening? Maybe I am way off here I don't know.

[dnicolodi]

The documentation tells a somehow simplified story. Anyhow, what's going on is very likely explained in the detailed log file.

[rgommers]

"Need python for x86, but found x86_64"

This is because you have a 32-bit Python installed on 64-bit Windows. If that's by accident, please remove it and install 64-bit Python. If it's on purpose that you're using 32-bit Python, then you need to activate 32-bit MSVC (see for example https://github.com/numpy/numpy/issues/24704#issuecomment-1719003257).

I've been meaning to improve this error message in Meson to include what is actually happening and how to fix it.

[doadin]

"Need python for x86, but found x86_64"

This is because you have a 32-bit Python installed on 64-bit Windows. If that's by accident, please remove it and install 64-bit Python. If it's on purpose that you're using 32-bit Python, then you need to activate 32-bit MSVC (see for example numpy/numpy#24704 (comment)).

I've been meaning to improve this error message in Meson to include what is actually happening and how to fix it.

"C compiler for the host machine: cl (msvc 19.29.30154 "Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30154 for x86") Host machine cpu family: x86 Host machine cpu: x86"

does this not mean that 32-bit MSVC is active?

[doadin]

@rgommers that very link shows you had the error but it pointed to 19.35.32217.1 for x64, mine does not.

Also in googleing I found your post prior to this and that step did not help....again I think because 32 is already active, hence the "C compiler for the host machine: cl (msvc 19.29.30154 "Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30154 for x86"

[rgommers]

Oops, you are right - it's the opposite error, sorry for the noise.

In that case, it's probably something like "wrong meson and meson-python version, not installed in the current build env, and hence picking up the wrong python.exe"

Your build command is gvsbuild build rather than invoking pip or build. You're installing meson and ninja manually inside gvsbuild it looks like, and aren't installing meson-python. meson-python uses a Meson "native file" to explicitly select the correct Python interpreter. Without that, meson may just grab some random one. It looks like it's finding a 64-bit python.exe, which may or may not be expected here.

[dnicolodi]

@rgommers In the build logs I don't see meson-python involved in any way.

[rgommers]

@rgommers In the build logs I don't see meson-python involved in any way.

Yes indeed, I agree. If that is intended (no idea, because I know nothing about gvsbuild) then what I was pointing out is that the likelihood of picking up the wrong interpreter goes up a lot. meson is just finding one at random here probably.

[rgommers]

(added the invalid label only because meson-python isn't involved at all, not because there is nothing to improve here)