Export numa via a bundled FindNuma module instead of an absolute path

[mbrobbel]

Summary

Fixes #118.

find_library(NUMA_LIB numa REQUIRED) resolves numa to an absolute path (e.g. /usr/lib64/libnuma.so). That path was passed as a PUBLIC link dependency via ${NUMA_LIB}, so CMake serialized it verbatim into the exported cuCascadeTargets.cmake. Consumers on systems where libnuma lives at a different path then fail to link — for example a manylinux-built wheel referencing /usr/lib64/libnuma.so consumed on Ubuntu arm64 (where it is at /usr/lib/aarch64-linux-gnu/libnuma.so):

ninja: error: '/usr/lib64/libnuma.so', needed by 'librapidsmpf.so', missing and no known rule to make it

Changes

Rather than embed a library path in the export, this introduces a proper find module that produces an imported target, bundled with the package so the same find logic runs on both sides (per review feedback).

• cmake/Modules/FindNuma.cmake (new): locates numa.h and the numa library, validates via find_package_handle_standard_args, and produces a Numa::Numa imported target carrying both the include directory and the library location. This also propagates the numa.h include path, which a bare library reference did not.
• CMakeLists.txt: use find_package(Numa REQUIRED) and link the Numa::Numa target instead of a raw path; install FindNuma.cmake into the package's cmake/cuCascade/Modules dir (skipped for topology-only builds, which don't depend on libnuma).
• cmake/cuCascadeConfig.cmake.in: prepend the bundled Modules dir to CMAKE_MODULE_PATH and rerun find_dependency(Numa REQUIRED), so consumers reconstruct Numa::Numa against their own libnuma — no path baked into the exported targets, and a clear configure-time error if libnuma is missing.

Verification

Built, installed to a temp prefix, and configured a standalone consumer project against the install:

• Exported cuCascadeTargets.cmake references the target, not a path:

  INTERFACE_LINK_LIBRARIES "rmm::rmm;cudf::cudf;CUDA::cudart_static;Threads::Threads;Numa::Numa;..."
  

• FindNuma.cmake is installed under lib/cmake/cuCascade/Modules/.
• A consumer running find_package(cuCascade) reconstructs Numa::Numa, resolving libnuma at its own system path.

---

🤖 This PR was authored by an AI agent (Claude Code), under human review.

🤖 Generated with Claude Code

[pentschev]

@vyasr would you mind having a look at this? This change came from #141 , and I'm no CMake expert to determine whether this change is correct for all situations we support downstream (like conda-forge/wheels). At the very least CMakeLists.txt seems to my inexperienced eyes suspicious because apparently linking by numa name works, however, NUMA_LIB is supposed to be defined prior to that in the same file.

[vyasr]

This solution will solve the proximate problem, but it doesn't go far enough. The current solution won't guarantee that the numa.h header is available, and it won't propagate any compiler/linker flags or dependencies. What we ought to do is define a find module that produces a suitable NUMA target that we can link to. Then we bundle that file with our package so that the same find logic can run for consumers of cuCascade. Pytorch's module is one example that does a more comprehensive search for components and handles the proper find_package arguments. It doesn't create a target though. cudf's old cufile module is a good example for that. cudf also demonstrates how you can use a rapids-cmake function to ensure that find module gets installed for consumers. cuCascade doesn't use rapids-cmake, but the rapids-cmake function in question can be replicated easily enough, it adds the file in question to a tracked list and later copies them into the build/install tree.

[pentschev]

To my inexperienced eyes, this looks sane to me. @vyasr could you have another look?

[vyasr]

Looks right to me, thanks!

[pentschev]

Thanks @mbrobbel for working on it and @vyasr for reviews.

[pentschev]

/merge