Tell cudf_kafka to use header-only fmt#12796
Tell cudf_kafka to use header-only fmt#12796rapids-bot[bot] merged 1 commit intorapidsai:branch-23.04from
Conversation
…t symbols should be marked as inline.
There was a problem hiding this comment.
Thank you for the explanation in the PR description! This change looks good, and the rationale makes total sense to me. I am not aware of any other non-CMake consumers of libcudf besides cudf_kafka.
Should we document somehow that libcudf requires this to be defined for builds not consuming libcudf via CMake?
This isn't even libcudf, it's coming from librmm. I had a chat with Rob about this and we have open questions about whether it should be possible to mix header-only fmt with library fmt. He's run into related issues in other places recently as well, so figuring out the best approach will be a follow-up task. |
|
/merge |
Description
The changes to spdlog/fmt packaging in rmm caused an undefined symbol issue in cudf_kafka. To unblock CI in #12783, I simply added fmt to the list of required libraries for the Python package (see caf7adf and the explanation). The underlying issue turns out to be that by default usage of fmt results in the dependent assuming that the headers are compiled in not header-only mode. When using CMake to manage the build, fmt relies on use of the appropriate target
fmt::fmt-header-onlyto configure the build such that anything using fmt knows to use it in header-only mode, which sets theFMT_HEADER_ONLYpreprocessor macro under the hood. Since the Python cudf_kafka package is not built using CMake, however, this information was not propagated to its build from its dependencies (libcudf/libcudf_kafka). As a result, it was compiled expecting an external definition of some fmt symbols rather than inlining them. This PR removes the undesirable library dependency on fmt introduced in #12783 in favor of properly telling fmt to expect inlined symbols.Checklist