-
-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Export Thrust/CUB version used at build time #31
Conversation
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 ( |
@conda-forge-admin, please rerender |
@conda-forge-admin, please rerender |
…nda-forge-pinning 2022.05.25.14.40.58
I am confused. From the CI log it seems RMM always bundles a copy of Thrust/CUB headers via CPM. Can we disable this behavior? |
Looks like we should do |
lol we didn't have thrust/cub 1.15 created... |
Does 1.16 not work? That is created. |
No I think it's pinned somewhere in the RAPIDS stack (rapids-cmake, maybe? @robertmaynard) |
1.16 changes some side-effect of header includes that can cause user failures. I am tracking progress of deploying corrections to all RAPIDS projects at: rapidsai/cudf#10841 So currently we are pinning at 1.15 since all of our libraries haven't been verified with 1.16 |
@conda-forge-admin, please restart ci |
The CPM trick seems to be working now. The benefit of it is Thrust headers are no longer bundled in librmm, which feels more natural now. TODO:
|
I think this is ready!
|
recipe/build.sh
Outdated
-DCPM_Thrust_SOURCE=${PREFIX} \ | ||
-DCPM_spdlog_SOURCE=${PREFIX} \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We really shouldn't need these. It looks like RMM doesn't have the conda environment handling snippet that other RAPIDS libraries do (https://github.com/rapidsai/cudf/blob/branch-22.08/cpp/CMakeLists.txt#L122) which adds the conda env to the cmake prefix path to have it searched in find_package
calls automatically.
I also think that you're pointing to these packages as if they're source directories that should be added via an add_subdirectory
type of call, but they should be installed packages found via find_package
. I think we could use Thrust_ROOT
and spdlog_ROOT
instead here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would setting -D<package>_ROOT=...
prevent CPM from fetching a copy? I don't understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because CPM first calls find_package
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-DCPM_Thrust_SOURCE=${PREFIX} \ | |
-DCPM_spdlog_SOURCE=${PREFIX} \ | |
-DThrust_ROOT=${PREFIX} \ | |
-Dspdlog_ROOT=${PREFIX} \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kkraus14 @robertmaynard Unfortunately it doesn't work...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@robertmaynard any insights here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2022-05-26T17:22:44.7681580Z +CMAKE_PREFIX_PATH=$PREFIX:$BUILD_PREFIX/x86_64-conda-linux-gnu/sysroot/usr
This should be setting the search paths appropriately, but I think it's supposed to be semicolon separated as opposed to colon separated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this may need to be fixed? https://github.com/conda-forge/ctng-compiler-activation-feedstock/blob/7ac7228866a63b3cd0f9db7ab9b7e362bf58650d/recipe/activate-gcc.sh#L92-L99
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is correct, You should use :
for the the env variable CMAKE_PREFIX_PATH
I thought Conda's CMake would be able to find any cmake configs that come with the installed packages
It should. I will reproduce locally, and report back
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, so a bad CMAKE_PREFIX_PATH
would make the search fail...
Anyway, I sent a fix: conda-forge/ctng-compiler-activation-feedstock#76
Co-authored-by: Keith Kraus <keith.j.kraus@gmail.com>
Thinking about this more, we shouldn't do this. The primary reason that rmm / RAPIDS packages thrust the way we do is to avoid having thrust placed in conda's When CMake brings in thrust via In short conda needs to:
Note: |
Is this an nvcc thing or a CMake thing? Implicitly adding a user include seems very wrong... |
A |
Ouch thanks for the detailed explanation @robertmaynard, it's a big bummer... Do I understand you correctly regarding the search order issue that we should
? |
I think the best longer term option would be to update the thrust and cub packages in conda to install the headers using a 'stutter' approach. So instead of the headers being in As an additional step we can patch thrust so that it sets the new In the shorter term I think we need to do the above and have |
Thanks, @robertmaynard, one last question: The stutter approach would only work for CMake builds right? For packages like CuPy that do not use CMake to find Thrust/CUB and instead simply relying on |
Correct :( |
@robertmaynard Would it be better then to modify the shutter approach such that |
Let me close this PR and summary my finding learned from this PR and another (conda-forge/rmm-feedstock#11) in the original issue. |
To close the loop on this. I have proposed a fix to this in CMake itself: https://gitlab.kitware.com/cmake/cmake/-/issues/23731 |
Close #30.
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)