-
Notifications
You must be signed in to change notification settings - Fork 2.2k
fix: vs2022 compilation, issue #3477 #3497
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
Conversation
Would you mind turning on a 2022 build? See #3480. |
We can disable the setuptools_helper test on 3.5 - unless it's our fault (I don't think so), then this is just an incompatibility between setuptools & Python 3.5 & MSVC 2022 that I don't really care about. |
I still like gating the |
How do I "disable setuptools_helper test on 3.5"? |
This problem is not with vs2022 C++ compiler, it is with vs2022 C++ standard library, which could be used by different compilers, for example clang bundled with vs2022 (or clang for windows installed separately). Therefore, if we want to limit workaround for specific version, it should be version of msvc stdlib (_MSVC_STL_VERSION >= 143), not compiler version (_MSC_VER), which is in fact old on clang for windows. The problem in this case is, we need to include system header (yvals.h) anyway to get _MSVC_STL_VERSION value. |
When did they start bundling clang? Nice. Maybe lfortran will be more readily available? Anyway, at least this is much more controlled, and lets the reader know more about the issue. Hopefully |
@@ -23,7 +23,7 @@ jobs: | |||
strategy: | |||
fail-fast: false | |||
matrix: | |||
runs-on: [ubuntu-latest, windows-latest, macos-latest] | |||
runs-on: [ubuntu-latest, windows-2022, macos-latest] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC we're implicitly dropping windows-latest
. Mostly a question for @henryiii: could we simply add windows-2022
but keep windows-latest
(until it becomes the same)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@henryiii I simply tried it out: #3517 is the same as this PR but with windows-latest
added back. Here we have 73 checks, on the other PR 79. I verified that we actually have distinct builds (below). — Resource wise it's definitely not a problem to have both. I'm thinking: Why not?
$ grep ' -- The CXX compiler identification is' *.txt | grep windows-latest.*MSVC | sed 's/2021-11-30[^ ]*//' | sed 's/^[^_]*//' | uniq | sort
______2.7_____windows-latest_____x64.txt: -- The CXX compiler identification is MSVC 19.29.30137.0
______3.10_____windows-latest_____x64.txt: -- The CXX compiler identification is MSVC 19.29.30137.0
______3.5_____windows-latest_____x64.txt: -- The CXX compiler identification is MSVC 19.29.30137.0
______3.6_____windows-latest_____x64_-DPYBIND11_FINDPYTHON=ON.txt: -- The CXX compiler identification is MSVC 19.29.30137.0
______3.9_____windows-latest_____x64.txt: -- The CXX compiler identification is MSVC 19.29.30137.0
______pypy-3.7-v7.3.7_____windows-latest_____x64.txt: -- The CXX compiler identification is MSVC 19.29.30137.0
______pypy-3.8-v7.3.7_____windows-latest_____x64.txt: -- The CXX compiler identification is MSVC 19.29.30137.0
$ grep ' -- The CXX compiler identification is' *.txt | grep windows-2022.*MSVC | sed 's/2021-11-30[^ ]*//' | sed 's/^[^_]*//' | uniq | sort
______2.7_____windows-2022_____x64.txt: -- The CXX compiler identification is MSVC 19.30.30705.0
______3.10_____windows-2022_____x64.txt: -- The CXX compiler identification is MSVC 19.30.30705.0
______3.5_____windows-2022_____x64.txt: -- The CXX compiler identification is MSVC 19.30.30705.0
______3.6_____windows-2022_____x64.txt: -- The CXX compiler identification is MSVC 19.30.30705.0
______3.9_____windows-2022_____x64.txt: -- The CXX compiler identification is MSVC 19.30.30705.0
______pypy-3.7-v7.3.7_____windows-2022_____x64.txt: -- The CXX compiler identification is MSVC 19.30.30705.0
______pypy-3.8-v7.3.7_____windows-2022_____x64.txt: -- The CXX compiler identification is MSVC 19.30.30705.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's just add a few windows-2019 builds, but don't think we need the full set. Also, I think the difference is that 2022 has the MSVC 2022 compiler also, but we could select the 2019 or 2017 or even 2015 compilers as well on the newer images (not sure how far back they go, used to be 2015, 2017, and 2019). If we force the older compiler, we don't need older Windows images (the windows-2016 image is being removed in March).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What should we do on this PR?
My feeling: add windows-2022 here, then trim down in a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can inject a 2022 build and leave the bulk of them 2019, or we can inject a 2019 build and leave the bulk of them 2022. No need to explode the build matrix.
include:
...
- runs-on: windows-2019
python: 3.9
Something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me either way. The simpler the better (without losing coverage). When trading of human time (for more complicated config) vs. 3 or 4 extra jobs, I'd come down on the side of minimizing human effort.
@henryiii the single failed test seems to be completely unrelated. Can you take a look? Otherwise, I think this is ready. |
Yes, that's a known flake, safe to ignore. Did you see my review from 3 hours ago? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks!
I already tested with the smart_holder branch (good; just one flake).
Leaving this for @henryiii to merge, because of my windows-latest vs windows-2022 question.
.github/workflows/ci.yml
Outdated
@@ -50,6 +50,9 @@ jobs: | |||
-DPYBIND11_FINDPYTHON=ON | |||
- runs-on: macos-latest | |||
python: pypy-2.7 | |||
# Inject a Windows 2019 run | |||
- runs-on: windows-2019 | |||
python: 3.9 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I didn't know it's that easy.
While we're still advertising Python 2.7 support, could we add that in here, too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks perfect now, thanks Henry!
Re-testing after git rebase master. |
pypy-2.7 • macos-latest • x64 seems to be stuck on Post Cache wheels |
Description
Tweaks to support Microsoft Visual Studio 2022.
Suggested changelog entry: