This repository has been archived by the owner on Feb 15, 2023. It is now read-only.
BUG: cl.exe used instead of clang-cl.exe for Windows pythran building #162
Comments
|
Hard coding the path to |
tylerjereddy
added a commit
to tylerjereddy/scipy-wheels
that referenced
this issue
Apr 21, 2022
* restore Pythran for Windows builds to see if we are good to go there (if so, we can close MacPythongh-162 as well) * bump `BUILD_COMMIT` to point to the latest relevant maintenance branch--this should also tell me if anything strange is happening with things that may be pinned since the `1.8.0` rel
tylerjereddy
added a commit
that referenced
this issue
May 8, 2022
* MAINT: wheels 1.8.1 prep * restore Pythran for Windows builds to see if we are good to go there (if so, we can close gh-162 as well) * bump `BUILD_COMMIT` to point to the latest relevant maintenance branch--this should also tell me if anything strange is happening with things that may be pinned since the `1.8.0` rel * MAINT: PR 167 revisions * try pinning setuptools for Linux jobs; the wheel versions seem wrong with bleeding edge setuptools * MAINT: PR 167 revisions * try pinning `DOCKER_TEST_IMAGE` to avoid the issues related to: https://github.blog/2022-04-12-git-security-vulnerability-announced/ * Revert "MAINT: PR 167 revisions" This reverts commit a090151. * MAINT: PR 167 revisions * try using this command: pypa/manylinux#1309 (comment) * to deal with this in newer manylinux images: https://github.blog/2022-04-12-git-security-vulnerability-announced/ * MAINT: PR 167 revisions * try to address some of the issues with `git config` commands showing up in CI * MAINT: PR 167 revisions * revert some `config.sh` changes that were not helping * MAINT: PR 167 revisions * try shimming the `git` commands in `clean_code()` based on feedback from Matti related to the new `git` vulnerability fix * DEBUG: narrow CI * disable most of the CI while I debug * MAINT: PR 167 revisions * try adding the safe directory command inside of `repo_dir`, which presumably will include running this command in each of the submodules * Try workaround in scipy/scipy#16139 * MAINT: simplify after git fix.
|
not a problem anymore after gh-167 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Ralf and I have seen this before in the main repo (in fact, we temporarily disabled Pythran on Azure Windows there IIRC).
Now I'm seeing the same thing for the
1.8.0rc3wheel builds: https://ci.appveyor.com/project/scipy/scipy-wheels/builds/42265533 (Looking at the3.10builds specifically in analysis below).The compile line switched from
clang-cl.exetoC:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x64\cl.exe, and the latter is causing a failed Pythran-related compile in the new RC build. (MSVC version paths do look the same before/after)Almost all dependency versions appear to be identical by looking at the logs.
oldest-supported-numpy-0.15was incremented up from0.14in the previously succeeding log, but that seems like stretch to cause the issue (NumPy version looks the same). We also already pinned the "usual suspects" between rc1 and rc2 so not surprising we're stable on the versions of most things.What to do about it?
One (short-term) thought, browsing through mostly-unrelated
pythranissue tracker discussions, is to identify the path toclang-cl.exeon the Appveyor image, then hard-code the path like here in.pythranrcserge-sans-paille/pythran#1921 (comment):The text was updated successfully, but these errors were encountered: