MSVC build fails due to cub symlink: fatal error C1083: Cannot open include file: '../config.cuh': No such file or directory #1328
Comments
|
It can be fixed by adding some subdirectories to the CUB include paths in cub/cub/cmake/cub-config.cmake: but that doesnt really feel like the right way to solve the issue. Interestingly, the issue doesnt manifest if I try and build just CUB in isolation |
Where did this version of MSVC come from? I build regularly with MSVC Community 2019, and the updater doesn't report any version newer than 19.27.29112. Everything builds just fine there :-/ Is this a pre-release developer snapshot of MSVC or something? |
|
This was 16.8 preview 4 i believe, im not at that machine currently though. The preview builds dont show up in the standard installer, it think theres a separate installer for them. I'll install 16.7 and see if I can reproduce it |
|
same error with 19.27.29112.0, cmake 3.18.0 have you added any cmake flags when you build with MSVC? i'm just doing from a |
|
I just built the failing compilation units with a fresh, no-option* *I did disable a few SM archs (all but sm_75), but that shouldn't affect this. It's strange. The compiler is finding the CUB headers, since the error is occurring in Some sanity checks:
It probably wouldn't be a bad idea for us to sweep through the CUB codebase and convert all of the relative paths to full includes relative to the CUB include path, but it should work as-is. |
|
I think I see a possible explanation. Are you using the MSVC developer prompt to configure this, or some other shell? Here's what's weird: Both the thrust and cub include paths are added to the
However, the file that MSVC is complaining about is
This is due to a I'm trying to get rid of that symlink because it's a timebomb in a cross-platform project, and it looks like you found a way to make it explode. Issue #1283 is tracking the effort to remove it in a way that won't break anyone's existing build. As a work-around, try removing the cc: @brycelelbach for visibility -- symlinks are bad. |
alliepiper
changed the title
|
Updated title to improve google-ability of the underlying issue. Others may hit this before we get it fixed. |
|
Yep thats it! Deleting the symlink fixes the build. What problem did the symlink solve? I imagine the CUB include dirs could be handled by the CUB cmake target include directories For reference I tried building from the MSVC developer prompt and from VS Code (which i'm pretty sure uses the vcvars.bat from the dev prompt under the hood). |
Some people wanted the simplicity of just doing
Ah, I thought maybe you were using some WSL or git bash setup that would understand the unix symlink and generate the bad path before it got to MSVC's preprocessor and choked. Is this breaking / blocking your projects, or is deleting the symlink a reasonable workaround until we get the monorepo? |
alliepiper
removed
the
info needed
alliepiper
changed the title
alliepiper
added
type: bug: functional
|
Its not really blocking any projects, i only tend to use the github branch for thrust to contribute to thrust, not for real work. Deleting the symlink and disabling warnings-as-errors is a fine workaround for now FWIW, a monorepo shouldnt be necessary if the relative includes are removed and cmake projects are set up properly. obviously that could break people to |
|
The monorepo is to address many issues, not just the symlink. Thrust and CUB are version locked, tightly coupled, and share a lot of build infrastructure. They're effectively two layers of abstraction providing the same functionality, so it makes sense to combine the code bases.
I'm not sure what you mean here, the relative includes internal to each project should be fine, and we have a new CMake config that seems to be working fairly well for most users. Have you had other issues related to these? |
|
I have a same issue when using thrust with CMake on GitHub Action windows-2019 virtual machine. Logs: |
alliepiper
added
P0: must have
This breaks builds on some toolchains.
Users should explicitly set their include directories for Thrust's
dependencies:
```
-I ${THRUST_ROOT}/dependencies/cub
-I ${THRUST_ROOT}/dependencies/libcudacxx/include
```
If using Thrust's CMake packages, these paths will be configured
automatically.
Fixes NVIDIA#1328.
|
This will no longer be an issue after Thrust 2.0 🎉 |
With a freshly cloned thrust (and recursively cloned CUB) i'm getting 'file not found' errors in CUB:
Here is the configure output:
The text was updated successfully, but these errors were encountered: