-
-
Notifications
You must be signed in to change notification settings - Fork 22
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
Bump build tools version to v14.41 #83
Comments
Noting a workaround from conda-forge/admin-requests#1062 for reference: c_compiler: # [win]
- vs2022 # [win]
c_compiler_version: # [win]
- 19.40 # [win]
cxx_compiler: # [win]
- vs2022 # [win]
cxx_compiler_version: # [win]
- 19.40 # [win] |
The annoying thing is that azure pipelines still has agents with both 17.10 and 17.11 in operation, and it depends on chance which one you get. I cannot yet say which one is more common, but it's generally "solvable" with a couple restarts. |
thanks for your input. It's indeed annoying that it works that way. IMO, there should be a way to "just" obtain the correct VC and VC build tools versions directly from the environment set by Visual Studio. That said, I still am not convinced that the way Microsoft decided to set and handle the environment can be considered good in the first place, but there's not much we can do there, unfortunately. |
This has been unbelievably frustrating. There is no way to pin an image version for more stability, and the Azure team does not communicate their deployment plans to developers. I've been pleading with the Azure developers to better communicate with us, to very little effect (actions/runner-images#10448 (comment), actions/runner-images#10490 (comment)) |
This sounds similar to what I was asking about in #82 (comment). Unfortunately AFAICT there is no way to make our feedstock builds more robust to the version of Visual Studio that is installed in the Azure Windows image. |
Solution to issue cannot be found in the documentation.
Issue
Like in #73 (workaround in #76), the build tools version listed in the feedstock are (again) out of date compared to the version installed in the container. NOTE: #82 most likely attempted the same thing, but maybe failed cfr. this comment
This sounds like something that can be automated. #56 did not fix it.
Installed packages
Environment info
The text was updated successfully, but these errors were encountered: