You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we are using sccache 0.7.7 in our CI images. This version has some bugs in its support for the compiler arguments used when we upgrade to gcc 14 (in particular I found issues in the compiler flags added by CMake for C++20 modules support, but there may be other issues as well). We should upgrade to a newer version to fix this.
Based on some offline discussions we do not want to upgrade to the latest public releases of sccache. @trxcllnt has done a lot of work to enable better caching specifically for nvcc, so we'll want to use a fork with those changes until we can get them upstreamed.
I attempted to reenable module scanning and we ran into a bunch of new issues with compilation. The original issue (which arose as invalid compilation flags) is indeed fixed, but we now observe new bugs during the actual compilation that will need to be fixed.
It looks like sccache is only just adding proper support for modules in mozilla/sccache#2516. That PR only has clang support, we'll need a subsequent PR for gcc support (the only host compiler RAPIDS uses) and then we'll need that merged into our fork, so it'll probably still be a while before this is all working correctly.
GCC c++20 modules support is very bad, so if you aim to use modules I would suggest looking at using clang.
Thanks for the heads up! We're not really looking to use modules in our code, we're just running into problems where unless we actively disable modules in our CMake the resulting compile lines it produces are producing various very bad compilation outcomes (OOMs during sccache compilation, invalid code, incorrect deps specifications, etc). We are now investigating if this could be a CMake issue since really we would expect that in code without modules this CMake feature should simply result in no change to the generated compilation commands.
The sccache upgrade was completed a while ago. As per NVIDIA/cudf#19495 (comment), we're punting on the module scanning piece for now, so I'm closing this issue.
Activity
vyasr commentedon Jun 25, 2025
Based on some offline discussions we do not want to upgrade to the latest public releases of sccache. @trxcllnt has done a lot of work to enable better caching specifically for nvcc, so we'll want to use a fork with those changes until we can get them upstreamed.
vyasr commentedon Feb 27, 2026
I attempted to reenable module scanning and we ran into a bunch of new issues with compilation. The original issue (which arose as invalid compilation flags) is indeed fixed, but we now observe new bugs during the actual compilation that will need to be fixed.
vyasr commentedon Feb 28, 2026
It looks like sccache is only just adding proper support for modules in mozilla/sccache#2516. That PR only has clang support, we'll need a subsequent PR for gcc support (the only host compiler RAPIDS uses) and then we'll need that merged into our fork, so it'll probably still be a while before this is all working correctly.
TroyKomodo commentedon Mar 1, 2026
GCC c++20 modules support is very bad, so if you aim to use modules I would suggest looking at using clang.
vyasr commentedon Mar 2, 2026
Thanks for the heads up! We're not really looking to use modules in our code, we're just running into problems where unless we actively disable modules in our CMake the resulting compile lines it produces are producing various very bad compilation outcomes (OOMs during sccache compilation, invalid code, incorrect deps specifications, etc). We are now investigating if this could be a CMake issue since really we would expect that in code without modules this CMake feature should simply result in no change to the generated compilation commands.
vyasr commentedon Mar 3, 2026
The sccache upgrade was completed a while ago. As per NVIDIA/cudf#19495 (comment), we're punting on the module scanning piece for now, so I'm closing this issue.