Fix nvcc on Windows - Githubissues

leofang commented 2 years ago

Close #76.

The common symptom, likely triggered after the vs2019 update, is this error

'cl.exe' is not recognized as an internal or external command,
operable program or batch file.

We need to use the --use-local-env flag to respect conda-forge's MSVC setup.

Skip MSVC environment initialization. By default nvcc assumes that the MSVC environment needs to be initialized. This is done by executing the appropriate command file available for the MSVC installation detected or specified. Initializing the environment for each nvcc invocation can add noticeable overheads. If the environment used to invoke nvcc has already been configured, this option can be used to skip this step.

cc: @isuruf @carterbox

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

conda-forge-linter commented 2 years 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.

leofang commented 2 years ago

cc: @jaimergp

leofang commented 2 years ago

@conda-forge-admin, please rerender

wolfv commented 2 years ago

Awesome!

leofang commented 2 years ago

@conda-forge-admin, please rerender

leofang commented 2 years ago

0f50a2f is actually wrong, but the CI did not catch it, proving my suspicion https://github.com/conda-forge/nvcc-feedstock/issues/76#issuecomment-1172896089 is right...

leofang commented 2 years ago

I am trying to understand what's the difference between msvc in the build vs the test environment, because I am pretty sure the added flag is the solution for the building error (https://github.com/conda-forge/cupy-feedstock/pull/173/commits/b33baf470501c1c16f60e1210629de5a82fe903b).

leofang commented 2 years ago

0f50a2f is actually wrong, but the CI did not catch it, proving my suspicion #76 (comment) is right...

And this is wrong 😑

leofang commented 2 years ago

My feeling is once we set --use-local-env we need to set all include and library search paths explicitly, which are done properly by any build system (setuptools, cmake, ...), but not in our simple test nvcc test_nvcc.cu.

leofang commented 2 years ago

My feeling is once we set --use-local-env we need to set all include and library search paths explicitly, which are done properly by any build system (setuptools, cmake, ...), but not in our simple test nvcc test_nvcc.cu.

Perhaps we should only set this flag at the build stage...

leofang commented 2 years ago

@jakirkham @jaimergp any chance you guys know what's going on here?

(%PREFIX%) %SRC_DIR%>"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.7\bin\nvcc.exe" --use-local-env -ccbin "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64\cl.exe" test.cu 
c:\program files\nvidia gpu computing toolkit\cuda\v11.7\include\crt/host_config.h(231): fatal error C1083: Cannot open include file: 'crtdefs.h': No such file or directory
test.cu

conda-forge / nvcc-feedstock

Fix nvcc on Windows #88