This PR introduces a workaround, which is similar to the one removed in #28796, required to work with the new windows-2022 image version 20231115 properly.
Tested on the following image versions:
Fixes #28901.
This change is required to work with the new windows-2022 image version
20231115 properly.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process.
Type | Reviewers |
---|---|
ACK | maflcko, TheCharlatan, pablomartin4btc |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Looks like this reverts 5bd1b8d4f1ab4dd947c5e93712ba47e14a0fe2da?
Different versions though.
This PR CI runs:
Do we know why this broke again?
The underlying issue is labeled “Under Investigation”.
I guess this is something we’ll just have to maintain forever?
Or until Microsoft fixes the issue.
That’s a shame, because it also adds ~30% runtime to this CI job.
I agree with you.
Do we know why this broke again? I guess this is something we’ll just have to maintain forever?
I’ve done a bit more research.
In GHA Windows images, it is an accepted practice to have different versions of MSVC toolsets being installed side-by-side.
For example, the current image 20231115 has the following toolsets installed:
The ilammy/msvc-dev-cmd
action chooses the latest compiler toolset version by default.
However, when building vcpkg dependencies in the manifest mode, MSVC uses another “default” toolset version, which causes link errors like “fatal error C1900”.
After switching building vcpkg dependencies from the manifest mode to the manual one, there is no link errors anymore. (the manual mode does not support package versioning, therefore, a few adjustments are needed) @sipsorcery
Do you have any insights regarding the correct usage of the manifest mode on systems with side-by-side version MSVC toolsets?
Do you have any insights regarding the correct usage of the manifest mode on systems with side-by-side version MSVC toolsets?
I don’t.
Whenever I encountered something similar I’d purge the vcpkg dependencies and rebuild so it would use the latest version of the msvc tools.
ChatGPT, on the other hand, has this to say on the matter:
In summary, using vcpkg with manifest mode in an environment with multiple MSVC toolsets requires careful configuration of your vcpkg manifest file, CMakeLists, and potentially custom triplets to ensure that the correct toolset and dependencies are used for your project.
With a bit more probing it does seem apparent that there’s no way to specify the compiler version for a vcpkg dependency. The custom triplets is a red herring and would require tweaking the config of every vcpkg installed library being used.
Even if there was a way to sepcify a compiler version with vcpkg it seems like this problem would still exist due to the MS bug linked above which chooses the wrong toolset for the compiler version.
I suspect this PR is as good as it gets until the bug is fixed.
utACK 91d5bd8ac9a28725c735f8e6900bc85673bb190a
With a bit more probing it does seem apparent that there’s no way to specify the compiler version for a vcpkg dependency. The custom triplets is a red herring and would require tweaking the config of every vcpkg installed library being used.
Did you see #28934?