[BUG] rapids_cpm_override in 25.04 fails when a project requires `SOURCE_SUBDIR`

[robertmaynard]

Describe the bug
After rapids-cmake 25.04 updated to CPM 0.40.2 projects that had nvtx3 entries started to fail to build due to nvt3 targets no longer existing.

Before CPM 0.40.2 when a rapids-cmake override exists the following calls occur:

  FetchContent_Populate(
    nvtx3
    GIT_REPOSITORY ${override_repository}
    GIT_TAG ${override_tag}

  )
  FetchContent_Declare(
    nvtx3
    GIT_REPOSITORY ${repository}
    GIT_TAG ${tag}
    SOURCE_SUBDIR c
  )
  
  FetchContent_GetProperties(nvtx3)
  if(NOT nvtx3_POPULATED)
    add_subdirectory(${nvtx3_SOURCE_DIR}/${nvtx3_SOURCE_SUBDIR} ${nvtx3_BINARY_DIR})
  endif()

The key parts are that CPM would itself track nvtx3_SOURCE_SUBDIR and call add_subdirectory based on the last value seen by it.

When we switch to CPM 0.40.2 all of that logic has been removed ( due to complying with policy 168 ) and instead FetchContent always handles the call to add_subdirectory. When FetchContent calls add_subdirectory it only considers information provided to it in the first FetchContent_Declare and therefore ignores the SOURCE_SUBDIR value.

Steps/Code to reproduce bug
Have nvtx3 in a rapids-cmake override file

[robertmaynard]

Given the fact that this issue is currently breaking downstream rapids-cmake users, we need to rollback to using CPM 0.40.0 as we develop a proper long term solution

• Rollback to CPM 0.40.0 #789

[robertmaynard]

Ideas on how to solve

1. rapids-cmake override doesn't call FetchContent at all. But instead we defer everything to rapids_cpm_find.
   The downside is that this means we won't override direct calls to CPMFindPackage/CPMAddPackage.
2. The SOURCE_SUBDIR becomes a required component of versions.json.
3. https://cmake.org/cmake/help/latest/command/cmake_language.html#dependency-providers and we see if we can provide our custom urls / info. More exploration is required

I also thought about https://cmake.org/cmake/help/latest/command/cmake_language.html#dependency-providers but I am hesitant to use those as it would inhibit us from integrating with vcpkg / other package managers in the future.