Skip to content
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

Closed
wants to merge 14 commits into from

Conversation

leofang
Copy link
Member

@leofang leofang commented May 25, 2022

Close #30.

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 @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
  • Ensured the license file is being packaged.

@conda-forge-linter
Copy link

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
Copy link
Member Author

leofang commented May 25, 2022

@conda-forge-admin, please rerender

@leofang
Copy link
Member Author

leofang commented May 25, 2022

@conda-forge-admin, please rerender

recipe/meta.yaml Outdated Show resolved Hide resolved
@leofang leofang changed the title Pin Thrust/CUB exactly Export Thrust/CUB version used at build time May 25, 2022
@leofang
Copy link
Member Author

leofang commented May 25, 2022

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?

@leofang
Copy link
Member Author

leofang commented May 25, 2022

Looks like we should do cmake -DCPM_LOCAL_PACKAGES_ONLY ....

recipe/build.sh Outdated Show resolved Hide resolved
@leofang
Copy link
Member Author

leofang commented May 25, 2022

lol we didn't have thrust/cub 1.15 created...

@kkraus14
Copy link
Contributor

lol we didn't have thrust/cub 1.15 created...

Does 1.16 not work? That is created.

@leofang leofang mentioned this pull request May 25, 2022
5 tasks
@leofang
Copy link
Member Author

leofang commented May 25, 2022

No I think it's pinned somewhere in the RAPIDS stack (rapids-cmake, maybe? @robertmaynard)

@robertmaynard
Copy link
Contributor

lol we didn't have thrust/cub 1.15 created...

Does 1.16 not work? That is created.

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

@leofang
Copy link
Member Author

leofang commented May 25, 2022

@conda-forge-admin, please restart ci

recipe/build.sh Outdated Show resolved Hide resolved
@leofang
Copy link
Member Author

leofang commented May 26, 2022

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:

  • CMake insists on using spdlog 1.8.5 as opposed to 1.10.0 from the global pinning. Need to figure out why.
  • CUB is not used by librmm, but when librmm is complied (in downstream), it's needed indirectly through Thrust. I think the current treatment is still needed, but I'd like to raise it for vis.

@leofang
Copy link
Member Author

leofang commented May 26, 2022

I think this is ready!

...
2022-05-26T14:33:34.3077589Z -- NO RAPIDS_VERSION for CUDAToolkit
2022-05-26T14:33:34.3084695Z -- NO RAPIDS_VERSION for CUDAToolkit
2022-05-26T14:33:34.3556740Z -- CPM: using local package spdlog@
2022-05-26T14:33:34.3566080Z -- NO RAPIDS_VERSION for spdlog
2022-05-26T14:33:34.3625485Z -- CPM: using local package Thrust@
2022-05-26T14:33:34.3894144Z -- Configuring done
2022-05-26T14:33:34.3939483Z -- Generating done
...

recipe/build.sh Outdated Show resolved Hide resolved
recipe/meta.yaml Outdated Show resolved Hide resolved
recipe/build.sh Outdated
Comment on lines 29 to 30
-DCPM_Thrust_SOURCE=${PREFIX} \
-DCPM_spdlog_SOURCE=${PREFIX} \
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
-DCPM_Thrust_SOURCE=${PREFIX} \
-DCPM_spdlog_SOURCE=${PREFIX} \
-DThrust_ROOT=${PREFIX} \
-Dspdlog_ROOT=${PREFIX} \

Copy link
Member Author

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...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@robertmaynard any insights here?

Copy link
Contributor

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

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

Copy link
Member Author

@leofang leofang May 26, 2022

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 <[email protected]>
@robertmaynard
Copy link
Contributor

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 env/include directory.

When CMake brings in thrust via find_package(Thrust) all the includes become system includes. As system includes are selected after user includes, nvcc implicit user include of the self packaged Thrust means that the conda installed Thrust will be ignored. ( See rapidsai/rapids-cmake#95 for more talk about this )

In short conda needs to:

  • Place the Thrust headers in a custom subfolder of <env>/include like RAPIDS does
  • Not bring header only packages like Thrust / Cub into conda OR document that they are unusable by CMake based projects

Note:
While https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6627 mitigates this issue, it would need to be applied to all CMake projects in conda to ensure that none of them bring in <env>/include as a system path.

@kkraus14
Copy link
Contributor

nvcc implicit user include of the self packaged Thrust

Is this an nvcc thing or a CMake thing? Implicitly adding a user include seems very wrong...

@robertmaynard
Copy link
Contributor

nvcc implicit user include of the self packaged Thrust

Is this an nvcc thing or a CMake thing? Implicitly adding a user include seems very wrong...

A nvcc thing.

@leofang
Copy link
Member Author

leofang commented May 26, 2022

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

  • abandon this librmm PR and stay with the status quo, and
  • find a way in rmm-feedstock to tell setup.py to look for librmm-bundled Thrust

?

@robertmaynard
Copy link
Contributor

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

  • abandon this librmm PR and stay with the status quo, and
  • find a way in rmm-feedstock to tell setup.py to look for librmm-bundled Thrust

?

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 <env>/include/thrust/ they would be in <env>/include/thrust/thrust/ and <env>/include/cub/cub/. This kind of layout is supported in Thrust and CUB starting in 1.16.

As an additional step we can patch thrust so that it sets the new IMPORTED_NO_SYSTEM target property which would allow any CMake based conda package to use the conda provided Thrust and CUB packages without issue.

In the shorter term I think we need to do the above and have setup.py to look for librmm-bundled Thrust

@leofang
Copy link
Member Author

leofang commented May 27, 2022

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 -I this approach would break them?

@robertmaynard
Copy link
Contributor

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 -I this approach would break them?

Correct :(

@leofang
Copy link
Member Author

leofang commented May 27, 2022

@robertmaynard Would it be better then to modify the shutter approach such that <env>/include/thrust/thrust/ is a symlink to <env>/include/thrust/? Would CMake be happy with symlinks?

leofang added a commit to conda-forge-linter/rmm-feedstock that referenced this pull request Jun 1, 2022
@leofang leofang mentioned this pull request Jun 3, 2022
3 tasks
@leofang
Copy link
Member Author

leofang commented Jun 7, 2022

Let me close this PR and summary my finding learned from this PR and another (conda-forge/rmm-feedstock#11) in the original issue.

@leofang leofang closed this Jun 7, 2022
@leofang leofang deleted the run_export branch June 7, 2022 04:28
@robertmaynard
Copy link
Contributor

To close the loop on this. I have proposed a fix to this in CMake itself: https://gitlab.kitware.com/cmake/cmake/-/issues/23731

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Thrust/CUB should be run-exported
4 participants