-
-
Notifications
You must be signed in to change notification settings - Fork 272
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
What is the plan for migrating the win-64 builds to vs2022? #2138
Comments
From my personal POV, I don't mind moving on, especially as it does not affect the vast majority of users that are just downloading packages, only someone doing local development against old VS versions (which are also easy to upgrade, and I haven't heard from anyone who got stuck in this situation during the move to VS2019 for example). That said, #1732 was strongly motivated by CI providers dropping support for VS2017, key upstream projects starting to require VS2019, and substantial bitrot in VS2017 support even where nominally still compatible. We're not yet at that point with VS2019 by far. Then again, VS2019 will reach EOL in ~2 weeks, so it's quite possible that a similar chain of events will happen in the coming months as for VS2017->VS2019. In the case of tiledb, it's worth keeping in mind that there's no hard rule about individual feedstocks updating their compiler stack (despite the viral requirement that consumers that compile against outputs of said feedstock also need to update). In particular, the set of (transitive) compile-dependents of tiledb is small compared to the rest of conda-forge. Where that question becomes harder is if a really widespread package needs a newer compiler stack, but so far I don't think such a situation has arisen yet. |
Google just dropped support for VS2019 going forward - that means upcoming abseil/grpc/protobuf etc. (and their dependents) will very likely need to move. |
@h-vetinari we have reached this point with TileDB, though it isn't going as we expected.
Which leads me to the following questions:
|
It's not a guarantee that things break; for example, if the artefact produced by VS2022 uses no features not supported by VS2019, things should work. I'd say it's the other way around. If a consumer of a package built by VS2022 can still compile with VS2019, that's no problem, but if anything breaks, just upgrade that feedstock. |
Your question:
Motivation
The next release of tiledb-feedstock will require us to use vs2022 for its win-64 build. Manually migrating a single feedstock to vs2022 is straightforward and well documented. However, it's my understanding that after we build with vs2022, all downstream conda-forge packages that depend on tiledb will also be required to migrate to vs2022 (and thus their dependencies and beyond throughout the dependency network). Thus I was curious: is their a plan/timeline for migrating the conda-forge win-64 builds to vs2022?
xref: TileDB-Inc/conda-forge-nightly-controller#69, conda-forge/tiledb-feedstock#268
Research
Move to vc142 toolchain on windows #1732 - proposed the migration to vs2019. Also noted "The one caveat is that any library built with a given toolset version can only be consumed (e.g. linked) by a toolset version that's the same or newer."
move to vs2019/vc142 conda-forge-pinning-feedstock#3167 - This is the PR that bumped the pin from vs2017 to vs2019
vs2022 for win-arm64 conda-forge-pinning-feedstock#4415 - The PR title says it all
Update maintainer kb windows doc #1956 (comment) - This comment from @h-vetinari nicely summarizes the current practice of conda-forge to be conservative when it comes to updating MSVC
The text was updated successfully, but these errors were encountered: