Introduce rapids_cpm_<preset> #52
Conversation
robertmaynard
added
feature request
robertmaynard
force-pushed
the
fea/rapids_offer_presetup_pkgs
branch
3 times, most recently
from
1078a88
to
6af51f9
Compare
rapids-cmake/cpm/thrust.cmake
Outdated
| endif() | ||
|
|
||
| include("${rapids-cmake-dir}/cpm/find.cmake") | ||
| rapids_cpm_find(Thrust 1.12.0 ${ARGN} |
There was a problem hiding this comment.
It would be tricky to have a central config file to control the versions of non rapids branch naming projects, but it'd be useful to have a readme with a list of the dependencies and versions, particularly if we put more of them here, to be sure they are synced with integration, conda recipes, etc. What do you think?
There was a problem hiding this comment.
I agree
How about something like a json file in the cpm directory that listed all the project url and branch?
rapids-cmake and the docs could both reference it to maintain a single source of truth
There was a problem hiding this comment.
That sounds like a great solution!
There was a problem hiding this comment.
What I am thinking is something like:
{
"GTest" : {
"version" : "1.10",
"git_url" : "https://github.com/google/googletest.git",
"git_tag" : "release-{version}",
},
"nvbench" : {
"version" : "0.0",
"git_url" : "https://github.com/NVIDIA/nvbench.git",
"git_tag" : "main",
},
"rmm" : {
"version" : "rapids-cmake-version",
"git_url" : "https://github.com/rapidsai/rmm.git",
"git_tag" : "branch-{version}",
},
"spdlog" : {
"version" : "1.8.5",
"git_url" : "https://github.com/gabime/spdlog.git",
"git_tag" : "v{version}",
},
"Thrust" : {
"version" : "1.12.0",
"git_url" : "https://github.com/NVIDIA/thrust.git",
"git_tag" : "{version}",
},
}
I am still trying to figure out how best to match rmm version to the current rapids calver, so for now I have used a placeholder ( rapids-cmake-version ).
Any thoughts?
There was a problem hiding this comment.
I have updated the PR with an initial implementation that has everything working based on a json file ( https://github.com/rapidsai/rapids-cmake/pull/52/files#diff-695faffc4b8bc9bc2b2fb2f4c3958c279c2d01744eeead1a30dedd1ead81eb6c )
I still have to do the following:
- Reference the json versions in each packages documentation
- Formally document the versions.json file and what magic placeholders are supported
rapids-cmake/cpm/gtest.cmake
Outdated
| CPM_ARGS | ||
| GIT_REPOSITORY ${repository} | ||
| GIT_TAG ${tag} | ||
| GIT_SHALLOW TRUE |
There was a problem hiding this comment.
won't GIT_SHALLOW shallow being TRUE interfere with the ability of setting any commit hash in the json file? Setting it to false would give us more flexibility, no?
There was a problem hiding this comment.
Since it is always combined with a tag it will do a shallow checkout at the tip of that tag/branch.
There was a problem hiding this comment.
Ohh I see what you mean, any arbitrary hash value for the GIT_TAG.
Yes in those case we need a shallow equals false. I think the best approach is to extend the json spec to include
git_shallow boolean field with the default being true
There was a problem hiding this comment.
I have updated the PR with the optional git_shallow field
robertmaynard
force-pushed
the
fea/rapids_offer_presetup_pkgs
branch
from
d7f03c4
to
01a8806
Compare
|
|
||
| An optional boolean value that represents if we should do a shallow git clone | ||
| or not. If no such field exists the default is `git_shallow : true` | ||
|
|
There was a problem hiding this comment.
I think we need the ability to patch things as well, i.e. https://github.com/rapidsai/cudf/blob/branch-21.10/cpp/cmake/thirdparty/CUDF_GetThrust.cmake#L33
There was a problem hiding this comment.
I think that is worth doing as a followup Issue/Feature discussion and PR.
As you are aware since cudf patches thrust it doesn't install it in the default location, which is what this change does. I am hesitant to install a modified Thrust in the 'default' location as that could cause confusion to users ( potential compile time or performance differences ). But once we resolve where patched versions of projects should be installed, this will be required.
|
rerun tests |
Fixes rapidsai#32 The following packages are now are easier to user for RAPIDS projects as rapids-cmake offers a pre-configured setup for each project. GTest NVBench RMM SpdLog Thrust On top of providing a consistent version of these packages to all RAPIDS projects, rapids-cmake now is able to deduce when these projects should also be installed. ```cmake rapids_cpm_gtest(BUILD_EXPORT_SET myproject) rapdis_cpm_rmm(BUILD_EXPORT_SET myproject INSTALL_EXPORT_SET myproject) ``` Given the above snippet when RMM is built as a subcomponent of `myproject` it will be installed as well. This is done since RMM is part of the INSTALL export set, and therefore must be available from an installed version of `myproject`.
…ency The generated output file from rapids_export_write_dependencies can't depend on rapid-cmake being reachable. This behavior has been restored by refactoring out the cpm download logic to `cpm/detail/download.cmake'
robertmaynard
force-pushed
the
fea/rapids_offer_presetup_pkgs
branch
from
f9362cc
to
8c37d6a
Compare
|
@gpucibot merge |
Requires #48 and #51
Adds rapids_cpm_ for common packages
Fixes #32
The following packages are now are easier to user for RAPIDS projects
as rapids-cmake offers a pre-configured setup for each project.
On top of providing a consistent version of these packages to all RAPIDS projects, rapids-cmake now is able to deduce when these projects should also be installed.
rapids_cpm_gtest(BUILD_EXPORT_SET myproject) rapdis_cpm_rmm(BUILD_EXPORT_SET myproject INSTALL_EXPORT_SET myproject)Given the above snippet when RMM is built as a subcomponent of
myprojectit will be installed as well. This is done sinceRMM is part of the INSTALL export set, and therefore must be available from an installed version of
myproject.