-
Notifications
You must be signed in to change notification settings - Fork 908
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
Rework libcudf CMakeLists.txt to export targets for CPM #7107
Conversation
… each library target, export library targets
rerun tests |
rerun tests |
rerun tests |
1 similar comment
rerun tests |
@gpucibot merge |
This PR is sooooo great! Thank you!!! There is one more thing that I think we can improve it further. This PR still manually includes a list of .cu/.cpp files for the library. It would be much better if we can automate that by cmake. I'm not sure if we can do something similar to this: https://stackoverflow.com/questions/3201154/automatically-add-all-files-in-a-folder-to-a-target-using-cmake |
If we did this then CMake wouldn't be able to detect when changes are made, so CMake configuration would need to be run on every incremental build which is painful. We considered this and decided against doing this. |
Fixing the Java bindings build after the removal of the libcudf sub-libraries in #7107. Authors: - Jason Lowe (@jlowe) Approvers: - Robert (Bobby) Evans (@revans2) - MithunR (@mythrocks) URL: #7486
The refactor in #7107 introduced two subtle bugs that caused benchmarks to not build correctly. 1. The `benchmark_main` target needs to be explicitly placed on the final executable link line as it injects object files, and that doesn't work via transitive propagation. 2. The variable names `BUILD_BENCHMARKS` and `BUILD_TESTING` are shared between RMM and CUDF. When CUDF builds RMM via CPM it will force cache these variables to `OFF`. This means that if a developer try to run `cmake -DBUILD_BENCHMARKS=ON .` any subsequent execution of just `cmake .` will cause CUDF to forget it should have kept benchmarks enabled. Authors: - Robert Maynard (@robertmaynard) Approvers: - Keith Kraus (@kkraus14) URL: #7485
This PR includes many of the same changes as were made in [cudf/pull/7107](rapidsai/cudf#7107). * Export `cuspatial::cuspatial` CMake alias targets. * Fixes -Wall errors discovered when changing compile flags. * Use `CPMFindPackage` to find `libcudf` installed on the system or build `libcudf` from source. edit: Depends on rapidsai/cudf#7574 and rapidsai/cudf#7734 Authors: - Paul Taylor (@trxcllnt) Approvers: - AJ Schmidt (@ajschmidt8) - Mark Harris (@harrism) - Keith Kraus (@kkraus14) URL: #365
These changes rework libcudf's CMakeLists.txt files to export targets for inclusion by other CMake projects. I took inspiration from RMM's CMakeLists.txt. However I'm not a CMake expert, and likely missed/messed up a few things.
I also fixed those annoying
-Wstrict-prototypes
warnings we see compiling Cython files.These changes are adequate to build libcudf as a dependency in another CMake project with CPM, for example: