Additional windows problems

[mattip]

From the meson branch of NumPy, using the HEAD of this repo 2ad0423 in a virtualenv of the windows store CPython3.9 located in d:'\temp\cpython_39:

• When starting from a cmd shell without cl on the path, python dev.py build fails to set up MSVC in a way that ninja can call it. I need to do this (something kindly prints out the second line so I know what to call, then the second invocation of dev.py installs to build-install). A work-around is to activate MSVC before calling this command, but I think it should Just Work without that.

  python dev.py build
  D:\temp\cpython_39\Scripts\meson compile -C build
  python dev.py build
  

• running python dev.py test still fails. It seems to be calling the base-python rather than the one inside the virtualenv. We touched on this in the other issue. If I change this line to use sys.executable instead of "python" then it works.

[eli-schwartz]

• When starting from a cmd shell without cl on the path, python dev.py build fails to set up MSVC in a way that ninja can call it. I need to do this (something kindly prints out the second line so I know what to call

Meson's Ninja backend can print out that message for you:

if self.build.need_vsenv:
    mlog.log('Visual Studio environment is needed to run Ninja. It is recommended to use Meson wrapper:')

Running meson compile prints this out:

vsenv_active = setup_vsenv(b.need_vsenv)
if vsenv_active:
    mlog.log(mlog.green('INFO:'), 'automatically activated MSVC compiler environment')

Sadly, it's impossible set up VS permanently from Meson. We can detect it even not on PATH, but we can only set it up in child processes of Meson itself (that's why meson compile exists, mostly).

This is really a flaw in ninja, there's a ticket at ninja-build/ninja#1610 (comment) discussing it.

[stefanv]

@mattip Do you have a Windows machine to test on? If so, do you think you can make a PR? Looks like it should be a very small change.

[stefanv]

Also, I CI shouldn't be passing on Windows, sounds like?

[eli-schwartz]

https://github.com/scientific-python/devpy/actions/runs/3915502106/jobs/6693736610#step:7:4

The functional tests try to build software using C, I don't know why this is quitting in a single second while printing zero output though. Simply configuring Meson should take longer than that...

[mattip]

The change to use sys.executable is indeed a small change. But getting devpy to work around the meson/ninja limitation in activating MSVC is a blocker for successfully using devpy in windows, so that needs to be fixed to even start using a devpy-like workflow practical.

[stefanv]

So, what can I do in devpy to handle this situation. I.e., what command do I need to run before meson is invoked? From the above, I don't quite understand the problem, other than the compiler not being on the path?

[mattip]

It seems we will have to wait for a fix to ninja

[eli-schwartz]

The first step is to figure out why the Windows CI isn't even attempting to execute meson setup in the first place.

If it was just a matter of the compiler not being on the PATH, meson would run, print basic information about the build, and then print an error message saying it can't find a compiler on the PATH...

[stefanv]

The first step is to figure out why the Windows CI isn't even attempting to execute meson setup in the first place.

I made a fix; perhaps there's a better one, but the issue was Powershell not honoring #!/usr/bin/env ....

[eli-schwartz]

How fascinating. Powershell doesn't error out if it doesn't know how to run that file? 👀

Anyway, that fix is great, the issue is now debuggable and we can now tell exactly what is happening on Windows in CI:

C compiler for the host machine: ccache gcc (gcc 11.2.0 "gcc.exe (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) 11.2.0")
C linker for the host machine: gcc ld.bfd 2.37

This is certainly a thing that happened, but I'm not sure how else to describe it. A common problem with Github Actions, though. Lots of random software installed, including, somewhere, a mingw toolchain. I think this might be the Strawberry Perl one:
actions/runner-images#5459
actions/runner-images#6627

And ultimately:
StrawberryPerl/Perl-Dist-Strawberry#11

Meson will look for a compiler on PATH before looking for MSVC, on the assumption -- which is usually correct -- that if you installed one, you want it. If it doesn't find one, it sets up MSVC.

Projects such as SciPy make use of this by intentionally and knowingly installing a known-good toolchain from rtools (this, or something similar, is needed if you cannot use MSVC on Windows because you need a FOSS Fortran compiler):
https://github.com/scipy/scipy/blob/aee66adffc76a7b38c6bb466e072ad5f3c943266/.github/workflows/windows.yml#L39-L42
https://cran.r-project.org/bin/windows/Rtools/rtools43/rtools.html

[eli-schwartz]

meson setup --vsenv builddir/ will force Meson to configure MSVC, even if it detects another compiler already available. This is probably not the right opinionated choice for dev.py itself, but it would make the CI tests stop triggering on this broken github actions installation of mingw.

[stefanv]

Oh jeez, so maybe the correct solution is to reconstruct the PATH manually.

[stefanv]

I tried to remove Strawberry, but it's still picking up a GCC compiler 🤔

https://github.com/scientific-python/devpy/actions/runs/4020420199/jobs/6908329726#step:8:22

Since it's the same compiler as found above, I presume I didn't get it out of the system somehow.

[eli-schwartz]

Since Powershell apparently silently ignores programs that don't exist, maybe there's just no rm there? Such fun.

[stefanv]

Perhaps it takes it 1:40 to figure that out! Who knows.

[eli-schwartz]

Apparently there's (now?) two of them:

C:\ProgramData\Chocolatey\bin\gcc.exe
C:\Strawberry\c\bin\gcc.exe

So apparently they also have this:

https://github.com/actions/runner-images/blob/main/images/win/Windows2022-Readme.md

Tools

• Mingw-w64 11.2.0

Bit random... Seems like there truly is no way for build systems to know on Github Actions, whether the compiler is or is not supposed to be MSVC.

[stefanv]

OK, next up is clang: https://github.com/scientific-python/devpy/actions/runs/4027122004/jobs/6922467654#step:8:22

[stefanv]

An alternative is to go into the MSVC shell: https://dvdhrm.github.io/2021/04/21/meson-msvc-github-actions/

[eli-schwartz]

An alternative is to go into the MSVC shell: https://dvdhrm.github.io/2021/04/21/meson-msvc-github-actions/

But I thought this ticket is all about the fact that we wanted to simulate the condition where users running on a personal device don't have that set up?

[eli-schwartz]

OK, next up is clang: https://github.com/scientific-python/devpy/actions/runs/4027122004/jobs/6922467654#step:8:22

Baffling, because: https://github.com/actions/runner-images/blob/main/images/win/Windows2022-Readme.md#msys2

Note: MSYS2 is pre-installed on image but not added to PATH.

Which makes a ton of sense! Every other gcc should do the same! Github Actions hosted tools should be available if the user wants to activate them, not arbitrarily sprinkled into PATH. But it failed at least twice and maybe more than that, sigh.

...

Hold on, msys2 isn't the problem at all. LLVM 15.0.5 is installed too.

Clang is: C:\Program Files\LLVM\bin\clang.exe

[stefanv]

OK @eli-schwartz, "success": https://github.com/scientific-python/devpy/actions/runs/4028727077/jobs/6925908648#step:8:37

[stefanv]

@eli-schwartz So what is reasonable behavior for devpy here? Should we scrape the meson output and see if that MSVC warning is present, and then call meson compile?

[eli-schwartz]

Or just do so unconditionally on Windows, perhaps.

Ideally the Ninja fix will happen some day, but who knows... this is not a solution for today...

[stefanv]

@mattip I think #43 should work for you; mind giving it a try?