Closed eriknw closed 1 year ago
conda-forge-linter
commented
1 year ago Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
eriknw
commented
1 year ago @conda-forge-admin, please rerender
eriknw
commented
1 year ago @DrTimothyAldenDavis any idea about the Windows failure here?
Sorry for not trying to build one of the betas.
DrTimothyAldenDavis
commented
1 year ago No idea. Maybe the compiler ran out of memory or something? Can you try building on a single core?
eriknw
commented
1 year ago I manually reverted back to vs2017, and we no longer get the error that we see when using vs2019.
conda-forge recently updated to vs2019/vc142 toolchain:
@jakirkham should we continue using vs2017? Should we ping anybody else about the issue we saw in vs2019? This is beyond my expertise, but I generally trust forward compatibility of Microsoft compilers.
eriknw
commented
1 year ago YOLO. Let's use vs2017. Merging.
DrTimothyAldenDavis
commented
1 year ago Great! I should probably post a note on SuiteSparse:GraphBLAS about using vscode 2019. Which version of VS code does that correspond to on this list? https://code.visualstudio.com/updates/v1_72
eriknw
commented
1 year ago Great! I should probably post a note on SuiteSparse:GraphBLAS about using vscode 2019. Which version of VS code does that correspond to on this list? https://code.visualstudio.com/updates/v1_72
I don't think vs2017 or vs2019 are on that list. See: https://visualstudio.microsoft.com/vs/older-downloads/
DrTimothyAldenDavis
commented
1 year ago Got it. Have you tried vs2020 or later? Maybe the bug only appears in vs2019.
eriknw
commented
1 year ago Nope, sorry. I don't think there are many other versions for us to try as part of this CI workflow.
jakirkham
commented
1 year ago I manually reverted back to vs2017, and we no longer get the error that we see when using vs2019.
conda-forge recently updated to vs2019/vc142 toolchain:
- Move to vc142 toolchain on windows conda-forge.github.io#1732
- move to vs2019/vc142 conda-forge-pinning-feedstock#3167
@jakirkham should we continue using vs2017? Should we ping anybody else about the issue we saw in vs2019? This is beyond my expertise, but I generally trust forward compatibility of Microsoft compilers.
Was out when this was asked.
Yes would suggest raising a new issue on this feedstock with relevant details (like logs, snippet of the error, etc.) and ping core.
eriknw
commented
1 year ago Thanks @jakirkham. Done: https://github.com/conda-forge/graphblas-feedstock/issues/47
h-vetinari
commented
1 year ago @DrTimothyAldenDavis: Great! I should probably post a note on SuiteSparse:GraphBLAS about using vscode 2019. Which version of VS code does that correspond to on this list? https://code.visualstudio.com/updates/v1_72
@eriknw: I don't think vs2017 or vs2019 are on that list. See: https://visualstudio.microsoft.com/vs/older-downloads/
@DrTimothyAldenDavis: Got it. Have you tried vs2020 or later? Maybe the bug only appears in vs2019.
@eriknw: Nope, sorry. I don't think there are many other versions for us to try as part of this CI workflow.
There's no vs2020. Ignoring ancient history, there's 2015, 2017, 2019, 2022, but in general the numbering scheme is hella confusing, e.g.
| VS year | VS version | Toolchain version (default) |
MSVC++ version | _MSC_VER |
version reported by cl.exe |
|---|---|---|---|---|---|
| 2017 | 15.x | 141 | 14.1x | 191x | 19.1x.yyyyy |
| 2019 | 16.x | 142 | 14.2x | 192x | 19.2x.yyyyy |
| 2022 | 17.x | 143 | 14.3x | 193x | 19.3x.yyyyy |
For each release (each line in the table above has several, roughly x=0..9), the x in 14- & 19-versions is always the same; since VS2019 the x in the VS version also matches. More details.
PS. Conda-forge doesn't have vs2022 yet.
Checklist
0(if the version changed)conda-smithy(Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)