Closed FaustinCarter closed 3 months ago
traversaro
commented
5 months ago @FaustinCarter In theory this should have been handled by https://github.com/conda-forge/vc-feedstock/pull/56, can you report your conda list in the environment you are experiencing the problem? This is also valid for other person experiencing the same problem @S-Dafarra @dariosortino .
S-Dafarra
commented
5 months ago @FaustinCarter In theory this should have been handled by #56, can you report your
conda listin the environment you are experiencing the problem? This is also valid for other person experiencing the same problem @S-Dafarra @dariosortino.
Here the
mamba listtraversaro
commented
5 months ago I just tested on my machine, and even if I see the messages:
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.9.3
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[ERROR:vcvars.bat] Toolset directory for version '14.38' was not found.
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***
[ERROR:VsDevCmd.bat] In an uninitialized command prompt, please 'set VSCMD_DEBUG=[value]' and then re-run
[ERROR:VsDevCmd.bat] vsdevcmd.bat [args] for additional details.
[ERROR:VsDevCmd.bat] Where [value] is:
[ERROR:VsDevCmd.bat] 1 : basic debug logging
[ERROR:VsDevCmd.bat] 2 : detailed debug logging
[ERROR:VsDevCmd.bat] 3 : trace level logging. Redirection of output to a file when using this level is recommended.
[ERROR:VsDevCmd.bat] Example: set VSCMD_DEBUG=3
[ERROR:VsDevCmd.bat] vsdevcmd.bat > vsdevcmd.trace.txt 2>&1
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.9.3
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'at the end of activation script, then I am able to build fine CMake projects using ninja. What I guess is happening, is that the failure is coming from the invocation of https://github.com/conda-forge/vc-feedstock/blob/8725d3429b35eb8b12897a015925ef4d2a135edc/recipe/activate.bat#L135 . However, that line fails, but then the environment is anyhow activated by the line https://github.com/conda-forge/vc-feedstock/blob/8725d3429b35eb8b12897a015925ef4d2a135edc/recipe/activate.bat#L141 .
@S-Dafarra @FaustinCarter @dariosortino TL;DR: I tested and at least in my case the problem is just the confusing activation message. Are you experiencing some other failure if you try to build something in the environment?
S-Dafarra
commented
5 months ago Are you experiencing some other failure if you try to build something in the environment?
No particular failure from my side, I just noticed that intellisense of Visual Studio was not working properly with the standard library includes.
traversaro
commented
5 months ago Are you experiencing some other failure if you try to build something in the environment?
No particular failure from my side, I just noticed that
intellisenseof Visual Studio was not working properly with the standard library includes.
Interesting, if you want to spend time on this it would be interesting to see the diff between set after you activate your env , and set after you manually call call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvars64.bat" to fix intellisense.
dariosortino
commented
5 months ago Are you experiencing some other failure if you try to build something in the environment?
No particular failure from my side, I just noticed that
intellisenseof Visual Studio was not working properly with the standard library includes.
I just upgraded Visual Studio to its newer version, then generate again the CMakeCache. It fixed my broken Intellisense
S-Dafarra
commented
5 months ago Interesting, if you want to spend time on this it would be interesting to see the diff between
setafter you activate yourenv, andsetafter you manually callcall "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvars64.bat"to fix intellisense.
I checked and it seems that with the package installed, actually there are more paths set with respect to the manual case. At this point, I am not entirely sure it is an issue anymore. I will double-check in the following days if I manage to isolate some macroscopic differences.
FaustinCarter
commented
5 months ago @FaustinCarter In theory this should have been handled by #56, can you report your
conda listin the environment you are experiencing the problem? This is also valid for other person experiencing the same problem @S-Dafarra @dariosortino .
@traversaro Here's what conda-build was sticking in the build env:
bzip2: 1.0.8-hcfcfb64_5
ca-certificates: 2024.2.2-h56e8100_0
eigen: 3.4.0-h91493d7_0
libffi: 3.4.2-h8ffe710_5
libsqlite: 3.45.2-hcfcfb64_0
libzlib: 1.2.13-hcfcfb64_5
openssl: 3.2.1-hcfcfb64_1
pip: 24.0-pyhd8ed1ab_0
pybind11: 2.11.1-py38hb1fd069_2
pybind11-global: 2.11.1-py38hb1fd069_2
python: 3.8.19-h4de0772_0_cpython
python_abi: 3.8-4_cp38
setuptools: 69.2.0-pyhd8ed1ab_0
tk: 8.6.13-h5226925_1
ucrt: 10.0.22621.0-h57928b3_0
vc: 14.3-hcf57466_18
vc14_runtime: 14.38.33130-h82b7239_18
vs2015_runtime: 14.38.33130-hcb4865c_18
vs2022_win-64: 19.34.31933-h78da3e3_17
vswhere: 3.1.4-h57928b3_0
wheel: 0.43.0-pyhd8ed1ab_0
xz: 5.2.6-h8d14728_0 The system this was running on had 14.39 installed. This is what it kicked out shortly before failing:
C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools>CALL "VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.34 10.0.22621.0
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.9.2
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[ERROR:vcvars.bat] Toolset directory for version '14.34' was not found.
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***
[ERROR:VsDevCmd.bat] In an uninitialized command prompt, please 'set VSCMD_DEBUG=[value]' and then re-run
[ERROR:VsDevCmd.bat] vsdevcmd.bat [args] for additional details.
[ERROR:VsDevCmd.bat] Where [value] is:
[ERROR:VsDevCmd.bat] 1 : basic debug logging
[ERROR:VsDevCmd.bat] 2 : detailed debug logging
[ERROR:VsDevCmd.bat] 3 : trace level logging. Redirection of output to a file when using this level is recommended.
[ERROR:VsDevCmd.bat] Example: set VSCMD_DEBUG=3
[ERROR:VsDevCmd.bat] vsdevcmd.bat > vsdevcmd.trace.txt 2>&1And the actual error message was during the pip build wheel call, and was a failure of cl.exe:
error: command 'cl.exe' failed: None
error: subprocess-exited-with-error
× Building wheel for sequencing (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> See above for output.
mgovers
commented
4 months ago The default image changed MSVC version to 14.39. Seems similar to #70 and #68 .
What's the reason for explicitly pinning to a single version instead of using the default toolchain? It is available and is actually logged by the build script (see e.g. https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=935910&view=logs&j=270c184a-5340-5429-138e-d97b868f5bb8&t=e13479c6-59fe-5ccc-f20c-19bfb689de0c&l=953 ):
%SRC_DIR%>type "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\\VC\Auxiliary\Build\Microsoft.VCToolsVersion.default.txt"
14.39.33519Only a couple lines later, the pinned version is requested, which then produces incorrect output (see e.g. https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=935910&view=logs&j=270c184a-5340-5429-138e-d97b868f5bb8&t=e13479c6-59fe-5ccc-f20c-19bfb689de0c&l=984 ):
C:\Program Files\Microsoft Visual Studio\2022\Enterprise>CALL "VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.38 10.0.22621.0
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.9.7
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[ERROR:vcvars.bat] Toolset directory for version '14.38' was not found.The default image changed MSVC version to 14.39. Seems similar to #70 and #68 .
What's the reason for explicitly pinning to a single version instead of using the default toolchain? It is available and is actually logged by the build script (see e.g. https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=935910&view=logs&j=270c184a-5340-5429-138e-d97b868f5bb8&t=e13479c6-59fe-5ccc-f20c-19bfb689de0c&l=953 ):
%SRC_DIR%>type "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\\VC\Auxiliary\Build\Microsoft.VCToolsVersion.default.txt" 14.39.33519Only a couple lines later, the pinned version is requested, which then produces incorrect output (see e.g. https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=935910&view=logs&j=270c184a-5340-5429-138e-d97b868f5bb8&t=e13479c6-59fe-5ccc-f20c-19bfb689de0c&l=984 ):
C:\Program Files\Microsoft Visual Studio\2022\Enterprise>CALL "VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.38 10.0.22621.0 ********************************************************************** ** Visual Studio 2022 Developer Command Prompt v17.9.7 ** Copyright (c) 2022 Microsoft Corporation ********************************************************************** [ERROR:vcvars.bat] Toolset directory for version '14.38' was not found.
I tried bumping to 14.39, but interestingly enough, not all builds passed. I did a patch version bump to 14.8.33135 instead in #76 . It won't close this issue, but at least, the builds should pass again.
isuruf
commented
3 months ago Fixed now
Comment:
The latest build tools version is 14.39, and that does not yet exist on conda-forge, which means anyone using a bleeding edge install of VS2022 is out of luck without some extra leg work.