You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently use cufile in both cudf and kvikio. They are each carrying around a custom find module for this, and cudf has a little extra logic as well to make sure things work. cudf was using the resulting targets correctly, but kvikio was (until rapidsai/kvikio#540) incorrectly adding include dirs and not using these targets. Especially now that kvikio is going to publish a library instead of being header-only, we would benefit from ensuring that we synchronize and maintain a clean find module for cufile that may be reused appropriately. I'd like to see that tool added to rapids-cmake.
The text was updated successfully, but these errors were encountered:
Upon further inspection, the custom find modules aren't leveraging the built-in (since 3.25) CMake cufile support and are instead finding from scratch. If the built-in module works as-is then we may be able to use that directly and we can close this issue. If it has any problem we may need to carry around patches in rapids-cmake for a bit until we can get them upstreamed and update our required CMake version.
We currently use cufile in both cudf and kvikio. They are each carrying around a custom find module for this, and cudf has a little extra logic as well to make sure things work. cudf was using the resulting targets correctly, but kvikio was (until rapidsai/kvikio#540) incorrectly adding include dirs and not using these targets. Especially now that kvikio is going to publish a library instead of being header-only, we would benefit from ensuring that we synchronize and maintain a clean find module for cufile that may be reused appropriately. I'd like to see that tool added to rapids-cmake.
The text was updated successfully, but these errors were encountered: