Skip to content

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

Merged
merged 12 commits into from
Dec 3, 2021
Merged

fix: vs2022 compilation, issue #3477 #3497

merged 12 commits into from
Dec 3, 2021

Conversation

Boris-Rasin
Copy link
Contributor

@Boris-Rasin Boris-Rasin commented Nov 22, 2021

Description

Tweaks to support Microsoft Visual Studio 2022.

Suggested changelog entry:

Tweaks to support Microsoft Visual Studio 2022.

@henryiii
Copy link
Collaborator

Would you mind turning on a 2022 build? See #3480.

@henryiii
Copy link
Collaborator

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.

@henryiii
Copy link
Collaborator

I still like gating the include <crtdefs.h> for MSVC 2022+. Other than those two things, then I think this is good to go.

@Boris-Rasin
Copy link
Contributor Author

How do I "disable setuptools_helper test on 3.5"?

@Boris-Rasin
Copy link
Contributor Author

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.

@henryiii
Copy link
Collaborator

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 yvals.h doesn't include much else.

@@ -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]
Copy link
Collaborator

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)?

Copy link
Collaborator

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

Copy link
Collaborator

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).

Copy link
Collaborator

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.

Copy link
Collaborator

@henryiii henryiii Nov 30, 2021

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.

Copy link
Collaborator

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.

@rwgk rwgk mentioned this pull request Nov 24, 2021
@Boris-Rasin
Copy link
Contributor Author

Boris-Rasin commented Nov 24, 2021

@henryiii the single failed test seems to be completely unrelated. Can you take a look? Otherwise, I think this is ready.

@rwgk
Copy link
Collaborator

rwgk commented Nov 24, 2021

Yes, that's a known flake, safe to ignore.

Did you see my review from 3 hours ago?

rwgk added a commit to rwgk/pybind11 that referenced this pull request Nov 28, 2021
Copy link
Collaborator

@rwgk rwgk left a 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.

rwgk added a commit to rwgk/pybind11 that referenced this pull request Nov 30, 2021
@@ -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
Copy link
Collaborator

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?

Copy link
Collaborator

@rwgk rwgk left a 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!

@rwgk
Copy link
Collaborator

rwgk commented Dec 3, 2021

Re-testing after git rebase master.

@rwgk
Copy link
Collaborator

rwgk commented Dec 3, 2021

pypy-2.7 • macos-latest • x64 seems to be stuck on Post Cache wheels
Ignoring.
I'll merge this now, to get the lengthy process going -> smart_holder -> Google.

@rwgk rwgk merged commit a224d0c into pybind:master Dec 3, 2021
@github-actions github-actions bot added the needs changelog Possibly needs a changelog entry label Dec 3, 2021
@henryiii henryiii removed the needs changelog Possibly needs a changelog entry label Dec 21, 2021
YannickJadoul added a commit to YannickJadoul/Parselmouth that referenced this pull request Apr 3, 2022
YannickJadoul added a commit to YannickJadoul/Parselmouth that referenced this pull request Apr 3, 2022
YannickJadoul added a commit to YannickJadoul/Parselmouth that referenced this pull request Jul 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants