RMM now leverages rapids-cmake to reduce CMake boilerplate #800
Conversation
rapids-cmake provides all the functionality of RMM existing CMake modules. This allow RAPIDS to deploy build-system fixes quickly and across all projects.
robertmaynard
added
non-breaking
ajschmidt8
added
the
improvement
| @@ -0,0 +1,43 @@ | |||
| # ============================================================================= | |||
There was a problem hiding this comment.
Should the get_gtest.cmake and get_gbench.cmake be promoted to the rapids-cmake repo? I'd think they would be duplicated across multiple RAPIDS repos if not.
There was a problem hiding this comment.
I think that gtest, gbench, and spdlog are all very resonable candiates to getting
moved over to rapids-cmake. In general I am hestitant to make rapids-cmake a package
manager but for core common dependencies it does make sense. I think thrust could also be included but we need to discuss that a bit more, since cudf uses a patched version of thrust ( do we want all of rapids to also do that? )
Most of the questions will be around what does the API look like for this. I think we would want to offer an API that offers very little customization ( around which version, flags, etc ) since rapids_cpm_find offers that. Instead we would be looking at a fairly closed/narrow API like the following:
rapids_cpm_<PackageName>( [BUILD_EXPORT_SET <export-name>]
[INSTALL_EXPORT_SET <export-name>]
)
Which would simplify rmm usage to:
rapids_cpm_gtest()
rapids_cpm_benchmark()
rapids_com_spdlog(BUILD_EXPORT_SET rmm-exports INSTALL_EXPORT_SET rmm-exports)
There was a problem hiding this comment.
That looks good. However I guess this shouldn't block the present PR. Agree?
There was a problem hiding this comment.
I agree.
I have added a feature request to rapids-cmake for this: rapidsai/rapids-cmake#32
The file should always be downloaded by CI to get the latest API changes.
|
@gpucibot merge |
…ing (#430) This PR contains three distinct changes required to get cuspatial builds working and tests passing again: 1. RMM switched to rapids-cmake (rapidsai/rmm#800), which requires CMake 3.20.1, so this PR includes the required updates for that. 2. The Arrow upgrade in cudf also moved the location of testing utilities (rapidsai/cudf#7495). Long term cuspatial needs to move away from use of the testing utilities, which are not part of cudf's public API, but we are currently blocked by rapidsai/cudf#8646, so this PR just imports the internal `assert_eq` method as a stopgap to get tests passing. 3. The changes in rapidsai/cudf#8373 altered the way that metadata was propagated to libcudf outputs from previously existing cuDF Python objects. The new code paths require cuspatial to override metadata copying at the GeoDataFrame rather than the GeoColumn level in order to ensure that information about column types is lost in the libcudf round trip and the metadata copying functions are now called on the output DataFrame rather than the input one. This PR supersedes #427, #428, and #429, all of which can now be closed. Authors: - Vyas Ramasubramani (https://github.com/vyasr) - GALI PREM SAGAR (https://github.com/galipremsagar) Approvers: - AJ Schmidt (https://github.com/ajschmidt8) - Christopher Harris (https://github.com/cwharris) URL: #430
rapids-cmake provides all the functionality of RMM existing CMake modules.
This will allow RAPIDS to deploy build-system fixes easily across all projects.