[BUG] rapids_cpm_find isn't as invariant as one would expect

[robertmaynard]

Describe the bug

Consider the following reduced example of bringing in rmm via CPM and as a dependency via find_package

    rapids_cpm_find(A)
        -> find_package(rmm)
    rapids_cpm_find(rmm INSTALL_EXPORT_SET B)

If package A sets up variables / state that are required to find rmm, the subsequent call to rapids_cpm_find will try and check out rmm and build it by source causing duplicate target errors. If rapids_cpm_find(A) hadn't found a pre-built rmm we would have had no error as CPM is designed to handle that use case.

The current solution to this is the following:

    rapids_cpm_find(A)
        -> find_package(rmm)
   if(NOT TARGET rmm::rmm)
        rapids_cpm_find(rmm INSTALL_EXPORT_SET B)
   endif()

This fixes the biggest issue ( duplicate targets ) but causes rmm not to be entered into the export set of B. This is problematic, as A isn't in the export set of B and therefore we now have dropped the dependency.

The correct logic would be:

    rapids_cpm_find(A)
        -> find_package(rmm)
   if(NOT TARGET rmm::rmm)
        rapids_cpm_find(rmm INSTALL_EXPORT_SET B)
   else()
        rapids_export_package(INSTALL rmm B)
   endif()

Desired behavior
While we have a work around this requires users of rapids-cmake to understand all the permutations of behavior that is possible, the exact thing that rapids-cmake is trying to alleviate.

What should happen is that rapids_cpm_find should handle all the existence checks by looking at the GLOBAL_TARGETS argument. If any of those targets exist, it should record INSTALL_EXPORT_SET information and terminate. That way users get to write 'easy' code and get the correct behavior no matter what is happening

[robertmaynard]

Note: rapids_find_package doesn't suffer from this problem, since all config based find modules already don't try and add targets that already exist which allowsrapids_find_package to be invariant.