-
Notifications
You must be signed in to change notification settings - Fork 915
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
Refactor cudf_kafka to use skbuild #14292
Refactor cudf_kafka to use skbuild #14292
Conversation
Cross-linking for awareness: https://github.com/rapidsai/cudf/pull/14296/files#r1364688842 |
Let's also fix the missing
edit: Done in 37dc381. |
…or new CI containers (#14296) The aws-sdk-cpp pinning introduced in #14173 causes problems because newer builds of libarrow require a newer version of aws-sdk-cpp. Even though we restrict to libarrow 12.0.1, this restriction is insufficient to create solvable environments because the conda (mamba) solver doesn't seem to consistently reach far back enough into the history of builds to pull the last build that was compatible with the aws-sdk-cpp version that we need. For now, the safest way for us to avoid this problem is to downgrade to arrow 12.0.0, for which all conda package builds are pinned to the older version of aws-sdk-cpp that does not have the bug in question. Separately, while the above issue was encountered we also got new builds of our CI images [that removed system installs of CTK packages from CUDA 12 images](rapidsai/ci-imgs#77). This changes was made because for CUDA 12 we can get all the necessary pieces of the CTK from conda-forge. However, it turns out that the cudf_kafka builds were implicitly relying on system CTK packages, and the cudf_kafka build is in fact not fully compatible with conda-forge CTK packages because it is not using CMake via scikit-build (nor any other more sophisticated library discovery mechanism like pkg-config) and therefore does not know how to find conda-forge CTK headers/libraries. This PR introduces a set of temporary patches to get around this limitation. These patches are not a long-term fix, and are only put in place assuming that #14292 is merged in the near future before we cut a 23.12 release. Authors: - Vyas Ramasubramani (https://github.com/vyasr) Approvers: - Bradley Dice (https://github.com/bdice) - Ray Douglass (https://github.com/raydouglass) URL: #14296
This PR requested a lot of reviewers because it touches a lot of files in fairly small ways. I think we would be fine with a single review from @vyasr and an ops review, since it's mostly build system changes that Vyas is familiar with (or explicitly requested during conversations about this PR). |
@divyegala or @robertmaynard, your reviews would also be welcome here if you have time. |
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.
praise: Few things left to clean up but overall this looks great!
…kage (which disallows wheel builds, but we aren't shipping wheels anyway).
@vyasr and I discussed this offline, and concluded that the |
I pushed one small fix that should hopefully get this passing CI. |
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.
Much happier with this simplified version. The remaining test failures are unrelated to this PR and will be resolved once we can merge #14399. Nice work you two!
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.
I was heavily involved in the development of this PR so my review is a bit unfair, but I did a round of self-review and all looks fine to me. I think we will be fine to merge this with a review from @rapidsai/ops.
I did want to mark this PR as |
/merge |
Description
Refactor the currently outdated cudf_kafka build setup to use skbuild instead.