Recognize CUDA header file type (.cuh) #12134
Conversation
This PR mirrors the fix in bazelbuild@8804128 therefore shouldn't be considered as a standalone PR, but rather a follow up for the said commit as a bugfix. .cuh is widely used as suffix for CUDA. It is made more prominent since "cub" (https://nvlabs.github.io/cub/) recently distributed with CUDA ToolKit 11, hence, now .cuh headers are in every CUDA ToolKit distribution. From that lens, this PR simply fixed the said commit so that newer CUDA ToolKit can be natively supported in Bazel. I also believe if this PR made its way in, we can close this issue: bazelbuild#6578
|
Just noticed @chsigg has to rollback this change for some internal breakages. Would love to know more to close this one out. |
|
@oquenchil do you want to merge it? Fixed the merge conflict earlier today. |
|
This had to be rolledback because it caused internal build failures. We don't yet know why. |
It's because Google internal builds try to build CUDA headers into header modules (a Google internal variant of C++ modules) and fail spectacularly. We can land this in bazel, but not in blaze. See the comment here: #6578 (comment) |
|
Ideally, we keep the codebase between Bazel and the internal version as close as possible. Can we control whether we build a type of header into modules through the toolchain? IMO that's the only thing that should be different instead of introducing yet another flag. |
This PR mirrors the fix in
8804128
.cuh is widely used as suffix for CUDA. It is made more prominent since
"cub" (https://nvlabs.github.io/cub/) recently distributed with CUDA
ToolKit 11, hence, now .cuh headers are in every CUDA ToolKit
distribution.
I would like to continue with this PR and fix any breakages that may encounter.