Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meson incorrectly detects MinGW environment when running under MSYS2 #12772

Open
dtromb opened this issue Jan 24, 2024 · 3 comments · May be fixed by #13147
Open

Meson incorrectly detects MinGW environment when running under MSYS2 #12772

dtromb opened this issue Jan 24, 2024 · 3 comments · May be fixed by #13147
Labels

Comments

@dtromb
Copy link

dtromb commented Jan 24, 2024

On a fresh install of MSYS2, in the default MSYS2 shell, after running pacman -S meson, meson emits the error:

ERROR: This python3 seems to be msys/python on MSYS2 Windows, but you are in a MinGW environment
ERROR: Please install and use mingw-w64-x86_64-python3 and/or mingw-w64-x86_64-meson with Pacman
ERROR: This python3 seems to be msys/python on MSYS2 Windows, but you are in a MinGW environment
ERROR: Please install and use mingw-w64-x86_64-python3 and/or mingw-w64-x86_64-meson with Pacman

The shell is not in the MinGW environment, it is MSYS2. If we are meant to use the mingw python when running meson under MSYS2, the error message should be changed to make sense for that case and also there needs to be some way to get a working python/meson into the MSYS2 environments (the recommended install command installs into the mingw environment, which I am not using.)

If on the other hand meson is incorrectly detecting the mingw environment present, that also needs a fix.

In short: meson should run properly after some set of install commands when run as 'meson' - this is breaking many builds on MSYS2.

I understand that this project does not have control over the MSYS2 repository, but it is meson that is exiting in error and giving a non-functional workaround here.

Finally, if running meson under the MSYS2 shell is not supported in any way is not supported and we need to use the mingw shell, that also needs to be made explicit and the error message changed.

@eli-schwartz
Copy link
Member

/cc @lazka

@dtromb
Copy link
Author

dtromb commented Jan 25, 2024

mesonmain.py:253

if sys.platform == 'cygwin' and os.environ.get('MSYSTEM', '') not in ['MSYS', '']:

The actual value of $MSYSTEM in my shell is UCRT64. To reliably detect the environment, it seems we can invert the logic - 'MINGW' /does/ seem to always appear in the value of MSYSTEM for the mingw shells. Perhaps:

if sys.platform == 'cygwin' and 'mingw' in os.environ.get('MSYSTEM','').lower():

Likely related info here: https://www.msys2.org/news/#2022-10-29-changing-the-default-environment-from-mingw64-to-ucrt64.

Although - assuming I'm not misunderstanding the intent of this completely - it might be altogether better to just pass the paths through pathlib, which can fix them to match the msdos/unix-ness of the system, rather than dumping out with an error if there's a flavor mismatch - IF the only issue with mingw and paths was the one sited near that line (#3635).

In any case, testing locally with that change seems OK so far (no pkg-config or python path errors)...

@lazka
Copy link
Contributor

lazka commented Jan 25, 2024

The detection is still correct, every non-MSYS environment is a "mingw" environment. The thing that is out of date is the error message suggesting "mingw-w64-x86_64-python3" which installs it for MINGW64, but with UCRT64 you need "mingw-w64-ucrt-x86_64-python" instead.

Maybe instead of the package names we could point to https://packages.msys2.org/base/mingw-w64-python ?

tristan957 added a commit to tristan957/meson that referenced this issue Apr 25, 2024
Suggested by @lazka in order to be clearer when delineating between
mingw-w64-x86_64-python and mingw-w64-ucrt-x86_64-python.

Fixes: mesonbuild#12772
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants