rapidsai / rapids-cmake Goto Github PK

I've been reading through the rapids-cmake docs and I noticed that we use Sphinx refs in places like here. I think the objective of the ref is to link to the official, external CMake docs, but it doesn't seem to be working currently. I think we need to configure our intersphinx_mapping variable to something like this in order for the external links to work correctly.

Here's the official docs on the intersphinx_mapping variable for reference: https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html#confval-intersphinx_mapping

I can try to tackle this after the holidays if no one gets to it before then.

Is your feature request related to a problem? Please describe.

We'd like to use rapids-cmake for all dependency management in NVBench, and we will be adding a dependency on the catch2 library soon.

Describe the solution you'd like

Support for rapids_cpm_catch2 that does the equivalent of

CPMAddPackage("gh:catchorg/[email protected]")

Describe alternatives you've considered

We could manage this dependency manually, but would like to make use of the extra functionality in rapids-cpm for consistency.

Is your feature request related to a problem? Please describe.

rapids-cmake should provide a rapids_cpm_libcudacxx function that allows for a unified version of libcudacxx across all rapids-cmake projects.

This is important as more RAPIDS projects start using newer versions of libcudacxx compared to the one provided by the CUDA Toolkit.

Describe the solution you'd like

rapids_cpm_libcudacxx would provide a consistent API to find an existing install of libcudacxx or download it from source.

Since currently libcudacxx doesn't provide a way to install just the headers, or a libcudacxx-config.cmake to allow find_package(libcudacxx) to work rapids_cpm_libcudacxx will need to do the following:

• Specify custom install rules for libcudacxx
• Generate a build directory libcudacxx-config.cmake
• Generate an install directory libcudacxx-config.cmake

Like thrust, libcudacxx is provided as part of the CUDA Toolkit and therefore the issues outlined in #95 also apply. Primarily the generated libcudacxx-config.cmake needs to ensure that the include paths are brought in as non-imported.

The description of rapids_cpm_find makes it seem like it's nearly a drop in replacement for CPMFindPackage that adds functionality for tracking global dependencies and setting up correct exports. However, the function subtly changes the behavior of CPMFindPackage depending on whether this function has already been called, and overrides CPM functionality. This can lead to bugs that are difficult to diagnose if a user expects every call to rapids_cpm_find to function similarly to CPMFindPackage.

The problem lies in this section of the function:

  if(package_needs_to_be_added)
    if(CPM_${name}_SOURCE)
      CPMAddPackage(NAME ${name} VERSION ${version} ${RAPIDS_UNPARSED_ARGUMENTS})
    else()
      CPMFindPackage(NAME ${name} VERSION ${version} ${RAPIDS_UNPARSED_ARGUMENTS})
    endif()
  endif()

If the user needs some variables set by CPMFindPackage, they may or may not be set depending on whether rapids_cpm_find has already been called or not. Consider this scenario, partially pulled from cuDF, where two dependencies each call rapids_cpm_find with the same arguments:

function(find_and_configure_libcudacxx VERSION)
    rapids_cpm_find(libcudacxx ${VERSION} ...)

    set(LIBCUDACXX_INCLUDE_DIR "${libcudacxx_SOURCE_DIR}/include" PARENT_SCOPE)
endfunction()

function(configure_cudf VERSION)
    find_and_configure_libcudacxx(VERSION)

    # This next line may fail!!!!
    file(COPY "${LIBCUDACXX_INCLUDE_DIR}/" DESTINATION "${CMAKE_BINARY_DIR}/include/libcudacxx")
endfunction()

function(configure_matx VERSION)
    rapids_cpm_find(libcudacxx ${VERSION} ...)
endfunction()

Everything works smoothly if the configure functions are called in this order:

configure_cudf(...)
configure_matx(...)

However, they fail if called in this order:

configure_matx(...)
configure_cudf(...) # ERROR: Cannot copy /include !!!

An error will be generated much later in the code because libcudacxx_SOURCE_DIR was never set in the second function call. I recently ran into this issue and it was difficult to debug what was happening because the error message and the cause of the error were very far apart and only showed up depending on the order some third party dependencies were added.

To fix this, I think any function that wraps a CPM function should:

1. Always call the wrapped CPM function
   a. CPM already has mechanisms to handle duplicate calls while still providing the same output
   b. Calling CPMFindPackage regardless of the value of package_needs_to_be_added ensures the correct variables are set with very little downsides
2. Do not call a different CPM function than the wrapped function
   a. i.e. rapids_cpm_find should call CPMFindPackage and never CPMAddPackage if CPM_${name}_SOURCE is set
   4. CPM already has mechanisms to call CPMFindPackage from CPMAddPackage and CPMAddPackage from CPMFindPackage. This behavior will only complicates or hides that behavior
3. Provide separate wrappers for each wrapped CPM function
   a. i.e. There should be a rapids_cpm_find to wrap CPMFindPackage and rapids_cpm_add to wrap CPMAddPackage
   b. This also helps with dependencies which always need to be added, even if they are found. Its not possible to use rapids_cpm_find in this scenario. (GLOG is an example of this. You must build from source if you want a custom log format)

In my opinion, these changes would make the functionality of rapids_cpm_XXX functions more clear, lead to less bugs, and make it easier to maintain the library for future updates to CPM.

Report incorrect documentation

Location of incorrect documentation

https://docs.rapids.ai/api/rapids-cmake/nightly/api.html, link to "rapids_cuda_init_runtime"

Describe the problems or issues found in the documentation

The "rapids_cuda_init_runtime" link goes to the doc page for "rapids_cuda_init_architectures".

Steps taken to verify documentation is incorrect

Clicked the link, observed result.

Describe the bug

Conda recipes use the requirements section to define build time and runtime dependencies of a project. WIthin the requirements sections, there's three subsections build, host, and run. build is supposed to contain native tools used for building like cmake, make, ninja, compilers, etc. host contains libraries for the target platform of the project (for example to allow cross compiling) typically used for linking. Read more here: https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#requirements-section

It isn't well documented and is likely legacy, but there's also the possibility of running with only two sections a build and run section, in which the build tools and target platform library dependencies are merged into a single section. Most of the RAPIDS conda recipes are defined in this way, likely due to legacy reasons.

The build and host sections map to different conda environments during a conda build and have environment variables of BUILD_PREFIX and PREFIX set accordingly. Where there's only a build section in the recipe there can still be a corresponding PREFIX environment created alongside the BUILD_PREFIX environment depending on the packages included in the build sections. Notably using the {{ compiler(...) }} jinja templates causes two separate environments to be created.

It looks like if you have a recipe that uses both the build and host sections as expected, then we end up improperly setting the search paths to find packages in the build environment as opposed to the host environment: https://github.com/rapidsai/rapids-cmake/blob/branch-22.06/rapids-cmake/cmake/support_conda_env.cmake#L78-L83. This causes issues when building a project that depends on something that CMake or other build tools also depend on, i.e. libcurl.

In general, we should probably make searching in the build environment opt-in as opposed to default behavior because it can cause issues in cross compiling, but I understand some rapids conda recipes are defined using only build and run as of now. An easy temporary fix for these recipes would be to just change the build section to host for now.

Expected behavior

When using rapids_cmake_support_conda_env I expect the packages defined in the host section of my conda recipe to be found before finding packages in the build environment.

cc @jakirkham because conda recipes 😄

Provide bullet point list of major user facing changes to Sophie Watson by the end of **burn down**

Need a doc describing how to override rapids-cmake FetchContent to pull from a custom fork/branch: #127 (comment)

Describe the bug

Currently rapids_find_package is a function and therefore doesn't propagate any variables set by the underlying
find_package call. This is problematic when projects want to use variables such as <PROJECT_FOUND> or <PROJECT>_INCLUDE_DIRS.

Expected behavior
Switching rapids_find_package over to being a macro will resolve the above issues.

Since macros don't induce scope we will need to make sure the following occur:

• All local variables are prefixed with _rapids, so we don't clobber any existing local variable
• All local variables are unset at the end of the macro

** Notes **

Issue found when porting cudf to rapids-cmake

Please provide bullet point list of major user facing changes to Sophie Watson by the end of burn down

Is your feature request related to a problem? Please describe.

RAPIDS projects use CalVer strings that look like 21.06.00 but the branch/tag names look like branch-21.06. This causes
problems as we need to drop the date component

Describe the solution you'd like

Introduction of rapids_cmake_parse_version with the following modes would make it easier to switch from CalVer string to Major.Minor string

- rapids_cmake_parse_version(MAJOR <input_var> <out_var>)
- rapids_cmake_parse_version(MINOR <input_var> <out_var>)
- rapids_cmake_parse_version(PATCH <input_var> <out_var>)
- rapids_cmake_parse_version(MAJOR_MINOR <input_var> <out_var>)

Is your feature request related to a problem? Please describe.

We'd like to use rapids-cmake for all dependency management in NVBench, and the fmt library is one of our dependencies.

Describe the solution you'd like

Support for rapids_cpm_fmt that does the equivalent of

CPMAddPackage(
  NAME fmt
  GITHUB_REPOSITORY fmtlib/fmt
  GIT_TAG 7.1.3
)

Describe alternatives you've considered

We could manage this dependency manually, but would like to make use of the extra functionality in rapids-cpm for consistency.

Is your feature request related to a problem? Please describe.

NVBench's project name is NVBench, so all of the rapids-cmake preprocessor macros currently start with that string. However, we conventionally use all-caps NVBENCH to prefix preprocessor macros.

Describe the solution you'd like

A PREFIX <string> option to the write_version_file / write_git_revision_file function that defaults to the project name, but allows customization.

Describe alternatives you've considered

Renaming my project to NVBENCH is an alternative, but this would be burdensome and disruptive to adoption.

Additional context

Documentation should state that the default is the project name.

Is your feature request related to a problem? Please describe.
https://github.com/NVIDIA/cuCollections added stream support but the most recent version of cuCollection requires libcudacxx 1.7.

Describe the solution you'd like
Update libcudacxx version from 1.6 to 1.7

Currently cuDF is pulling in nvcomp release 2.3.2. The DevTech team is in the process of releasing 2.3.3.

Once it is available, we should consider moving to it for release 22.08.
This version includes fixes for deflate:

Fixed the correctness issue of deflate compression.
Update the nvcompBatchedDeflateGetDecompressSizeAsync.
Add API tests for deflate, and change the file structure of deflate (Add template parameters)

Note that for cuDF, we worked around the problem with the missing nvcompBatchedDeflateDecompressGetTempSizeEx in PR: rapidsai/cudf#11213

Related to #1, sometimes project dependencies fail to build for various reasons. Doing a clean rebuild of the dependent project won't detect that one of its dependencies didn't build and clean-build it too, because clean builds of the dependent project don't (shouldn't?) clean out the dependency build cache.

It's kind of a hacky solution, but we have a CMake function that checks whether the files for a dependency exist, and if not, deletes ${FETCHCONTENT_BASE_DIR}/${pkg}-build and ${FETCHCONTENT_BASE_DIR}/${pkg}-subbuild directories before calling CPMFindPackage:

function(_clean_build_dirs_if_not_fully_built dir soname)
  if (NOT EXISTS "${CPM_BINARY_CACHE}/${dir}-build/${soname}")
    file(REMOVE_RECURSE "${CPM_BINARY_CACHE}/${dir}-build")
    file(REMOVE_RECURSE "${CPM_BINARY_CACHE}/${dir}-subbuild")
  endif()
endfunction()

Provide bullet point list of major user facing changes to Sophie Watson by the end of **burn down**

From the CPM docs, all of examples show including CPM.cmake directly in the root CMakeLists.txt via include(CPM.cmake) or include(get_cpm). I assume this is to allow CPM to set variables such as CMAKE_MODULE_PATH in the root scope.

If a project uses rapids_cpm_init() to load CPM, this uses a function which will prevent the value set for CMAKE_MODULE_PATH by CPM from reaching the parent scope. This usually isn't an issue unless you try to use find_package() later on in CMake to a dependency added by CPM. For example, the following will not configure:

function(find_json)
    rapids_cpm_find(nlohmann_json 3.9.1
        BUILD_EXPORT_SET my-targets
    )
endfunction()

find_json()

find_package(nlohmann_json CONFIG REQUIRED) # <-- This will fail

To handle this scenario, CPM makes a folder in the build directory called CPM_Modules which contains a FindXXX.cmake module for every package added by CPM. CPM then adds this directory to CMAKE_MODULE_PATH allowing any subsequent find_package() calls to succeed.

This was discussed with @robertmaynard and some potental fixes are:

• Add the ability to include(${CPM_DOWNLOAD_LOCATION}) directly
• Use macros instead of functions for rapids_cpm_init() and rapids_cpm_download()
  • Downside here is ensuring no variables in these functions leak to the calling scope
• Propagate the CMAKE_MODULE_PATH variable up to the parent scope
  • Downside here is any future version of CPM would need to be checked for additional variables that are set

Describe the bug

When one of the following rapids-cmake modules is loaded after cmake_minimium_required(3.19+) the global targets are not recorded correctly in the generated project-dependencies.cmake.

• rapids-cmake/export/cpm.cmake
• rapids-cmake/export/package.cmake

This causes error messages like:

This occurs due to CMake policy 79 which enables calling target_link_libraries(A PRIVATE B) in directories outside of the one which created A. This break rapids-cmake as CMake adds special encoding placeholders to the INTERFACE_LINK_LIBRARIES list which can't be evaluated by commands such as if(TARGET)

Steps/Code to reproduce bug

cmake_minimum_required(VERSION 3.20)
project(Reproducer)

include(FetchContent)
FetchContent_Declare(
  rapids-cmake
  GIT_REPOSITORY https://github.com/rapidsai/rapids-cmake.git
  GIT_TAG        origin/branch-21.06
  )
FetchContent_MakeAvailable(rapids-cmake)

include(${rapids-cmake-dir}/export/cpm.cmake)

rapids_export_cpm( BUILD
                   FAKE_CPM_PACKAGE
                   test_export_set
                   CPM_ARGS
                    FAKE_PACKAGE_ARGS TRUE
                   GLOBAL_TARGETS ABC::ABC
                   )

rapids_export(BUILD Reproducer
  EXPORT_SET test_export_set
  LANGUAGES CXX
  NAMESPACE test::
  )

Expected behavior
Expected behavior is that rapids-cmake would use a different technique to encode the GLOBAL_TARGETS so that they aren't hit by policy 79.

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

Currently cuDF is pulling in nvcomp release 2.3. The DevTech team is in the process of releasing 2.3.1, which has a number of stability fixes. We should update the nvcomp release to 2.3.1 once it is available.

Is your feature request related to a problem? Please describe.

Issue was first brought in discussion: rapidsai/rmm#800 (comment)

The main ask is for a common shared formula for common dependencies of projects such as:

• Thrust
• GTest
• GBench
• SpdLog

Describe the solution you'd like

The solution is to provide a limited number of high value packages in the rapids/cpm namespace. These packages would use the following template. This template allows for dependency tracking, but enforces a consistent version of dependencies across all consumers.

  rapids_cpm_<PackageName>( [BUILD_EXPORT_SET <export-name>]
                            [INSTALL_EXPORT_SET <export-name>]                  
                          )

The initial version will limit it self to only support GTest, GBench, SpdLog, and Thrust. Thrust will be added without the patches used by cudf initially and we can determine separately if those patches should be applied for all RAPIDS projects.

For packages that aren't as widely used the recommend approach is to continue to use rapds_cpm_find.

Describe the bug
CPM picks up a locally installed googletest library regardless of whether it provides GTest::gmock (whose presence can be controlled via -DBUILD_GMOCK=OFF). This leads to the following error on generation:

-- CPM: using local package [email protected]
-- CPM: adding package [email protected] (branch-22.08)
-- Found cuFile: /usr/local/cuda-11.7/lib64/libcufile.so
-- Configuring done
CMake Error at CMakeLists.txt:692 (target_link_libraries):
  Target "cudftestutil" links to:

    GTest::gmock

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.



-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

Steps/Code to reproduce bug
Install googletest 1.8.0 or newer from source with -DBUILD_GMOCK=OFF and run build.sh.
I used spack via spack install googletest to install the library.

Expected behavior
The cmake configuration should work

Environment overview (please complete the following information)

• Environment location: WSL2 with Ubuntu 20.04
• Method of cuDF install: from source

Environment details

 **git***
 commit e2ff00f665472a477f7c5b90bed8045c9d0d40a4 (HEAD -> branch-22.08, origin/branch-22.08, origin/HEAD)
 Author: etseidl <[email protected]>
 Date:   Mon Jul 4 14:32:08 2022 -0700

 Add thrift support for parquet column and offset indexes (#11178)

 Adds some necessary structs to parquet.hpp as well as methods to CompactProtocolReader/Writer to address rapidsai/cudf#9268

 I can add tests if necessary once rapidsai/cudf#11177 is merged, or testing can be deferred to be included in a future PR (based on rapidsai/cudf#11171)

 Authors:
 - https://github.com/etseidl

 Approvers:
 - Devavret Makkar (https://github.com/devavret)
 - Yunsong Wang (https://github.com/PointKernel)

 URL: https://github.com/rapidsai/cudf/pull/11178
 **git submodules***

 ***OS Information***
 DISTRIB_ID=Ubuntu
 DISTRIB_RELEASE=20.04
 DISTRIB_CODENAME=focal
 DISTRIB_DESCRIPTION="Ubuntu 20.04 LTS"
 NAME="Ubuntu"
 VERSION="20.04 LTS (Focal Fossa)"
 ID=ubuntu
 ID_LIKE=debian
 PRETTY_NAME="Ubuntu 20.04 LTS"
 VERSION_ID="20.04"
 HOME_URL="https://www.ubuntu.com/"
 SUPPORT_URL="https://help.ubuntu.com/"
 BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
 PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
 VERSION_CODENAME=focal
 UBUNTU_CODENAME=focal
 Linux 5.10.16.3-microsoft-standard-WSL2 rapidsai/cudf#1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

 ***GPU Information***
 Tue Jul  5 15:54:11 2022
 +-----------------------------------------------------------------------------+
 | NVIDIA-SMI 515.43.01    Driver Version: 516.01       CUDA Version: 11.7     |
 |-------------------------------+----------------------+----------------------+
 | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
 | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
 |                               |                      |               MIG M. |
 |===============================+======================+======================|
 |   0  Quadro RTX 3000...  On   | 00000000:01:00.0 Off |                  N/A |
 | N/A   48C    P0    18W /  N/A |      0MiB /  6144MiB |      0%      Default |
 |                               |                      |                  N/A |
 +-------------------------------+----------------------+----------------------+

 +-----------------------------------------------------------------------------+
 | Processes:                                                                  |
 |  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
 |        ID   ID                                                   Usage      |
 |=============================================================================|
 |  No running processes found                                                 |
 +-----------------------------------------------------------------------------+

 ***CPU***
 Architecture:                    x86_64
 CPU op-mode(s):                  32-bit, 64-bit
 Byte Order:                      Little Endian
 Address sizes:                   39 bits physical, 48 bits virtual
 CPU(s):                          16
 On-line CPU(s) list:             0-15
 Thread(s) per core:              2
 Core(s) per socket:              8
 Socket(s):                       1
 Vendor ID:                       GenuineIntel
 CPU family:                      6
 Model:                           165
 Model name:                      Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz
 Stepping:                        2
 CPU MHz:                         2304.007
 BogoMIPS:                        4608.01
 Hypervisor vendor:               Microsoft
 Virtualization type:             full
 L1d cache:                       256 KiB
 L1i cache:                       256 KiB
 L2 cache:                        2 MiB
 L3 cache:                        16 MiB
 Vulnerability Itlb multihit:     KVM: Mitigation: VMX unsupported
 Vulnerability L1tf:              Not affected
 Vulnerability Mds:               Not affected
 Vulnerability Meltdown:          Not affected
 Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
 Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
 Vulnerability Spectre v2:        Mitigation; Enhanced IBRS, IBPB conditional, RSB filling
 Vulnerability Srbds:             Not affected
 Vulnerability Tsx async abort:   Not affected
 Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves flush_l1d arch_capabilities

 ***CMake***
 /home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/cmake-3.23.2-p2knxqhaxheekzcizgr25xxj2vzahssk/bin/cmake
 cmake version 3.23.2

 CMake suite maintained and supported by Kitware (kitware.com/cmake).

 ***g++***
 /home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/gcc-11.3.0-smnfbmjldfjl6utm5wuabw5sntrgag5z/bin/g++
 g++ (Spack GCC) 11.3.0
 Copyright (C) 2021 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


 ***nvcc***
 /usr/local/cuda-11.7/bin/nvcc
 nvcc: NVIDIA (R) Cuda compiler driver
 Copyright (c) 2005-2022 NVIDIA Corporation
 Built on Tue_May__3_18:49:52_PDT_2022
 Cuda compilation tools, release 11.7, V11.7.64
 Build cuda_11.7.r11.7/compiler.31294372_0

 ***Python***
 /home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/python-3.9.13-mjbtlo67lldhazprooi7bscvnenehw56/bin/python
 Python 3.9.13

 ***Environment Variables***
 PATH                            : /home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/openssl-1.1.1p-suhytzhenyctx4hskzud246ul7mh7mse/bin:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/gcc-11.3.0-smnfbmjldfjl6utm5wuabw5sntrgag5z/bin:/usr/local/cuda-11.7/bin:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/hwloc-2.7.1-v2ajufvqih6ahfobdfqut5brvgwxle3p/bin:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/gflags-2.2.2-sfpwril4k2r5cwatrmepfdvxjl542tkf/bin:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/openmpi-4.1.4-57ki2uxf2tivfambnt7wmt76synav4on/bin:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/python-3.9.13-mjbtlo67lldhazprooi7bscvnenehw56/bin:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/ninja-1.11.0-ihlo3n7cyhvrh6oxalsks25edlcq3g3j/bin:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/cmake-3.23.2-p2knxqhaxheekzcizgr25xxj2vzahssk/bin:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/llvm-14.0.6-gkek3xptdok6lahz7lqj3eyq3xi7xjdz/bin:/home/tribizel/spack/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Program
 Files/PowerShell/7:/mnt/c/Program: Files/NVIDIA
 GPU                             : Computing
 Toolkit/CUDA/v11.7/bin:/mnt/c/Program: Files/NVIDIA
 GPU                             : Computing
 Toolkit/CUDA/v11.7/libnvvp:/mnt/c/windows/system32:/mnt/c/windows:/mnt/c/windows/System32/Wbem:/mnt/c/windows/System32/WindowsPowerShell/v1.0:/mnt/c/windows/System32/OpenSSH:/mnt/c/Program: Files/Perforce:/mnt/c/Program
 Files/NVIDIA                    : Corporation/Nsight
 Compute                         : 2022.2.0:/mnt/c/Program
 Files                           : (x86)/NVIDIA
 Corporation/PhysX/Common:/mnt/c/Users/tribizel/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/tribizel/AppData/Local/Programs/Microsoft: VS
 Code/bin:/snap/bin              :
 LD_LIBRARY_PATH                 : /home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/googletest-1.10.0-52m35fglkskemxojpgknbcebrnlpafx6/lib:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/openssl-1.1.1p-suhytzhenyctx4hskzud246ul7mh7mse/lib:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/zlib-1.2.12-3xrlqm2oj6djouizyxcwt7d36zifpibd/lib:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/gcc-11.3.0-smnfbmjldfjl6utm5wuabw5sntrgag5z/lib64:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/gcc-11.3.0-smnfbmjldfjl6utm5wuabw5sntrgag5z/lib:/usr/local/cuda-11.7/lib64:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/rapidjson-1.2.0-2022-03-09-cwptm7yij2im2dvbd2o4teywroik3lqq/lib:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/benchmark-1.6.0-a5yaa2qhx45pm3s4i3nyeosdiir3ffuu/lib:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/hwloc-2.7.1-v2ajufvqih6ahfobdfqut5brvgwxle3p/lib:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/gflags-2.2.2-sfpwril4k2r5cwatrmepfdvxjl542tkf/lib:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/openmpi-4.1.4-57ki2uxf2tivfambnt7wmt76synav4on/lib:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/python-3.9.13-mjbtlo67lldhazprooi7bscvnenehw56/lib:/home/tribizel/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.4.0/llvm-14.0.6-gkek3xptdok6lahz7lqj3eyq3xi7xjdz/lib
 NUMBAPRO_NVVM                   :
 NUMBAPRO_LIBDEVICE              :
 CONDA_PREFIX                    :
 PYTHON_PATH                     :

 conda not found
 pip not found

Additional context
Add any other context about the problem here.

Similar to the existing rapids_cpm_rmm(), it would be great to have similar functions for cuDF, cuML and any other future projects that use CMake.

This would allow for users of these libraries to easily add them as dependencies. Additionally, this makes it easier for users of multiple Rapids libraries to easily keep versions in sync (i.e. when downloading rapids-cmake=21.10 you automatically have dependencies on cudf=21.10 cuml=21.10 rmm=21.10)

Is your feature request related to a problem? Please describe.
Can we please update the default libcudacxx version to 1.8.0 thus we can use the new cuda::std::array feature?

Describe the solution you'd like
Update the libcudacxx to 1.8.

Additional context
@robertmaynard mentioned that 1.8.0 introduced CMake support so it requires more changes to avoid conflicting targets being constructed

Is your feature request related to a problem? Please describe.

Projects such as cudf, and rmm require newer versions of Thrust, libcuc++ than can be found in the oldest supported CUDA toolkit. This requires these components to install/packaged so that consumers use the same version.

This becomes challenging with CMake+NVCC due to the rules around import targets, and system includes and the default install layout packages like Thrust use.

For example when a projects installs Thrust to a conda env you end up with a layout that looks like:

conda/env/include/rmm
conda/env/include/thrust
conda/env/include/cub 

This means that any project that specifies conda/env/include as a system path will capture thrust as a system path. Since CMake treats any include path specified on an import target as SYSTEM this causes the thrust inside conda to be a system path as a side-effect.

So why does that matter? Well compilers have specific rules on the order that includes are searched for headers. In general user includes are searched before any system includes going in the order provided. The issue is that NVCC injects the CUDA toollkit includes into the system include search order as the first entry. Therefore stopping discovery of another system included thrust.

Describe the solution you'd like

rapids-cmake should provide a general way to mark a targets includes as non-system with some INCLUDE|EXCLUDE regex filter

Report needed documentation

Reference: https://docs.rapids.ai/api/rapids-cmake/nightly/command/rapids_cpm_find.html

Report needed documentation

It's not clear what the supported projects/versions are when looking for help on this function.

Describe the documentation you'd like

Link to (or list) the supported packages / versions from this function's documentation page.

Steps taken to search for needed documentation

This is available elsewhere in the docs, but it would be convenient to have it available from rapids_cpm_find.

Is your feature request related to a problem? Please describe.

When building / testing a new feature that cross cuts multiple projects, or testing new project dependencies a developer might need to use a different branch / repo for a project offered by rapids_cmake.

Currently to have this work you need to do the following:

• Branch rapids-cmake
• modify versions.json
• modify rapids.cmake to point to your repo and branch
• modify the consuming project to fetch from your rapids-cmake fork

This is a really high bar to deploy / verify package changes, and rapids_cmake should offer a better approach.

Describe the solution you'd like

We need a solution that only requires changes in the consuming project.

To that end I have thought about the following methods:

1. Provide hooks via rapids_cpm_init and rapids_cpm_package_override where a user defined json file can be specified which contains the project(s) new information.

2. Provide just rapids_cpm_package_override( <Package_Name> ) which has explicit VERSION, GIT_URL, GIT_TAG, ... arguments which take the user defined new values.

The upside of number 1 is that the user facing code ( rapids_cpm_package_override ) doesn't have to change each time the version.json has new entries. The problem being that it is has a higher barrier of entry for consumers.

#184 introduces some CMake code to patch limitations with scikit-build, namely scikit-build/scikit-build#668. While that issue is not fixed yet, work is ongoing in scikit-build/scikit-build#668. Once a release of scikit-build exists with the necessary patch, we should modify our patch function so that it is only defined if the scikit-build version is old enough to contain the bug.

Report incorrect documentation

Location of incorrect documentation
All the rapids_cpm_pkg commands propagate unparsed arguments to rapids_cpm_find and we should capture that behavior.

Is your feature request related to a problem? Please describe.

Now that CPM supports fine grained per project download controls, we should update to use the latest version of CPM
cpm-cmake/CPM.cmake#336

CPM v0.35.3 doesn't error out when the build directory is a symlink. This fix will help rapids-compose users.

Is your feature request related to a problem? Please describe.

Thrust supports all architectures supported by CTK, including deprecated ones. This means we currently need to build against SM35+ in our benchmarking library.

However, rapids_cuda_init_architectures only adds architectures supported by RAPIDS (sm60+) when CMAKE_CUDA_ARCHITECTURES=ALL.

Describe the solution you'd like

Ideally, these special values would be something like:

• ALL: non deprecated arches supported by CTK (e.g. sm53+)
• ALL_LEGACY: all arches supported by CTK, including deprecated (e.g. sm35+)
• RAPIDS: all arches supported by RAPIDS (e.g. sm60+)

Since the current convention around ALL is already in use by rapids-cmake users, maybe the following values would be more agreeable and less disruptive:

• CTK: non deprecated arches supported by CTK (e.g. sm53+)
• CTK_LEGACY: all arches supported by CTK, including deprecated (e.g. sm35+)
• ALL / RAPIDS: all arches supported by RAPIDS (e.g. sm60+)

Also -- I'm not sure if NATIVE will add <sm60 if such a card is present. If not, adding NATIVE_CTK + NATIVE_CTK_LEGACY (or similar) would be useful for us.

Describe alternatives you've considered

We can still just list all arches explicitly, so this is a low-priority issue with an easy workaround. Most users will want NATIVE anyway.

Is your feature request related to a problem? Please describe.
We should continue leveraging latest CMake improvements, and therefore should review
the improvements that 3.21 and 3.22 will bring to rapids-cmake.

Describe the solution you'd like
I would like to see 3.22 become the required CMake version for rapids-cmake 22.X versions

Additional context
CMake 3.21 would bring in the following improvements:

• set behavior in regards to local/cache variables is not consistent!!! This is big quality of life improvement
• WriteBasicConfigVersion supports CalVer strings, so workaround in rapids-export can be dropped
• Less false positive error reports from FindThreads
• nicer ways to specify toolchain and install directory from the command line
• improvements to install() to copy runtime dependency will need to be reviews and we can see if they can be used when thirdparty dependencies are missing install rules
• Cleanup of foreach() and variable leaking. Most likely will need to update rapids-cmake in places due to this

CMake 3.22 would bring in the following improvements:

• find_library: Infer library prefix and suffix when in script mode. This is important to rapids-cmake as we hook up to projects before the project call which is analogous to script mode.
• compile_features ignore features for non-enabled languages. This allows projects to express a cxx_std_17 requirement and not fail when used by a project that doesn't enable CUDA.
• CUDA language level isn't inferred by the C++ language level
• GNUInstallDirs now aware of conda lib directory requirements

Describe the bug
The current version range is wrong as rapids-cmake didn't exist before 2021. We should update the range to be a single value for now.

Rapids-cmake currently provides no online documentation of the functions it provides.

Is your feature request related to a problem? Please describe.
Presume the following override.json:

{
  "packages" : {
      "Thrust" : {
        "version" : "1.17.0",
        "git_url" : "https://github.com/NVIDIA/thrust.git",
        "git_tag" : "${version}"
    }
  }
}

When this override exists, any call to rapids_cpm_thrust will use the override. But any call to rapids_cpm_find(Thrust... won't.

Describe the solution you'd like
Instead of having the activation of an override entry occur on the call to rapids_cpm_<pkg> it should happen on rapids_cpm_package_override. For this to work properly with rapids_cpm_find we will need to store the relevant information with FetchContent_Declare

The bug
When CPM options are exported via rapids_export the generated text is missing quotes around OPTIONS such as BUILD_TESTS OFF causing CPM to incorrectly parse them.

Unable to use newer version of nvCOMP when building cuDF as such:
~/cudf/build.sh libcudf --cmake-args=\"-DCMAKE_PREFIX_PATH=~/nvcomp-dir -DCUDF_USE_PROPRIETARY_NVCOMP=OFF\"
The build instead uses 2.3.3 version.

Is your feature request related to a problem? Please describe.
Currently the build and install export sets don't understand that static linking means that PRIVATE dependencies are
required to consume an exported library.

This generally means that all projects using rapids-cmake don't properly export dependencies when built statically, since they
only track dependencies that are required to use the library when built 'shared' ( .so )

Describe the solution you'd like
The optimal solution would be to have CMake do the following:

• Associate imported targets with the find_package call that created them
• Allow projects to generate the collection of find_package calls need by the link rules of the exported targets

If this becomes unreasonable to implement in CMake itself, we can do the following in rapids-cmake:

• Add the PUBLIC and PRIVATE keywords to rapids_find_package and rapids_cpm_find.
• Extend rapids_export with a INCLUDE_PRIVATE flag that will be set when building statically.

Is your feature request related to a problem? Please describe.
Dependency tracking, i.e. exporting targets for consumption of libraries, currently is not aware of the components functionality. This makes it so that consumers need to call additional find_packages for finding/defining the component targets.

This came up in rapidsai/cuml#4818, where cuML uses the nn and distance components of RAFT, but if a consumer calls find cuML but no find RAFT is called then this happens:

CMake Error at /home/ursa/miniconda3/envs/skbuild4/lib/cmake/cuml/cuml-targets.cmake:56 (set_target_properties):
  The link interface of target "cuml::cuml++" contains:

    raft::nn

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Call Stack (most recent call first):
  /home/ursa/miniconda3/envs/skbuild4/lib/cmake/cuml/cuml-config.cmake:77 (include)
  CMakeLists.txt:68 (find_package)

which makes it necessary to call a find RAFT in addition to find cuML.

When working with rapidsai projects, it can be difficult to overlay changes in the conda environment for transitive dependencies (e.g. cuCollections, cub, etc.). It would be great if we could override dependencies with our dirty checkouts for quick experiments.

Could we improve versions.json (or provide an example if it already supports it) to allow users to override a repository with a local directory path. It seems like rapids_cpm_find might be a natural place for this, but I'm also not a cmake or conda expert (maybe this is already possible!).

Thanks for your time :)

Describe the bug
In at least the librmm and libcudf 21.08 packages the cmake config and target files are in the lib64/cmake folder whereas they were previously in the lib/cmake folder. This differs from all other conda packages which also use the lib/cmake folder. I also believe it breaks find_package searches from working as expected.

Steps/Code to reproduce bug
See packages here: https://anaconda.org/rapidsai/librmm/files?version=21.08.00

Expected behavior
CMake config and target files should be in lib/cmake

Is your feature request related to a problem? Please describe.

We'd like to use rapids-cmake for all dependency management in NVBench, and the nlohmann_json library is one of our dependencies.

Describe the solution you'd like

Support for rapids_cpm_nlohmann_json that does the equivalent of

CPMAddPackage(
  NAME nlohmann_json
  # Latest release headers:
  VERSION 3.9.1
  URL https://github.com/nlohmann/json/releases/download/v3.9.1/include.zip
  URL_HASH SHA256=6bea5877b1541d353bd77bdfbdb2696333ae5ed8f9e8cc22df657192218cad91
  PATCH_COMMAND
    # Work around compiler bug in nvcc 11.0, see NVIDIA/NVBench#18
    ${CMAKE_COMMAND} -E copy
      "${CMAKE_CURRENT_SOURCE_DIR}/cmake/patches/nlohmann_json.hpp"
      "./include/nlohmann/json.hpp"
)

Describe alternatives you've considered

We could manage this dependency manually, but would like to make use of the extra functionality in rapids-cpm for consistency. This particular dependency is tricky to fetch because the usual "clone from github" approach is extremely slow, and the sources require patching to support nvcc 11.0.

Describe the bug
If a dependent project also uses RAPIDS.cmake, the default recipe will download and overwrite the file in the root build directory. This is especially problematic if the dependent project downloads an older version of rapids-cmake, pulling in an older versions.json.

Steps/Code to reproduce bug
Configure and build https://github.com/NVIDIA/cuCollections; it should work. Then re-run cmake . and observe that older versions of libcudacxx and Thrust are added (based on what https://github.com/NVIDIA/nvbench pulls in). The build will fail afterwards because cuCollections requires the newer versions.

Expected behavior
The build should be stable and work after reconfiguration.

Is your feature request related to a problem? Please describe.
find_package allows you to use REQUIRED on something like CUDAToolkit REQUIRED 11.4. It seem this is missing from rapids-cmake.

Describe the solution you'd like
Add the capability

Describe alternatives you've considered
Checks after rapids_find_package that error out

Additional context
Add any other context, code examples, or references to existing implementations about the feature request here.

In node-rapids we're taking advantage of a centralized source and build cache for all our C++ dependencies. We have multiple CMakeLists.txt project files that depend on certain expensive-to-build RAPIDS libraries like libcudf, and we don't want to build those libraries multiple times.

CPM has a utility for telling it to centralize where it downloads dependency sources via CPM_SOURCE_CACHE, but it has no corresponding setting for centralizing dependency build dirs i.e. CPM_BINARY_CACHE.

We can trick CPM (everything else that uses FetchContent) into centralizing build dirs via the FETCHCONTENT_BASE_DIR variable.

However, we later run into issues when a built project's export targets go to look up its own dependencies via FindPackage(). The dependencies aren't installed, and they're not in a location FindPackage() knows to search.

And since FetchContent doesn't create directory names FindPackage recognizes as locations a package could be (i.e. thrust vs. thrust-build), we can't simply do list(APPEND CMAKE_PREFIX_PATH ${FETCHCONTENT_BASE_DIR}).

Our workaround for this is to set ${pkg}_DIR for a project's dependencies before calling CPMFindPackage(). We have this little CMake function to help us:

function(_set_package_dir_if_exists pkg dir)
  if (EXISTS "${CPM_BINARY_CACHE}/${dir}-build")
      set(${pkg}_DIR "${CPM_BINARY_CACHE}/${dir}-build" PARENT_SCOPE)
  endif()
endfunction()

Describe the bug
If you have the cache variable RAPIDS_VERSION set before calling rapids_export(), the version it chooses can be incorrect if you omit the VERSION argument or set VERSION with no value. In these situations, the documentation states it will default to use PROJECT_VERSION. Instead it simply uses the value in RAPIDS_VERSION.

We ran into this in SRF and needed to explicitly set the version to get around the bug (here is the PR with the workaround: nv-morpheus/MRC#30). In SRF, we use the cache variable RAPIDS_VERSION to indicate which version of RMM, RAPIDS CMake, etc. we are using to build with. It took a while to discover why the generated srf-config-version.cmake was using the incorrect version value.

Steps/Code to reproduce bug
The following pseudocode should reproduce the bug:

project(my_project
  VERSION 22.06.00
  LANGUAGES C CXX
)

# Need to set the RAPIDS_VERSION cache variable
set(RAPIDS_VERSION "21.10" CACHE STRING "RAPIDS Libraries Version")

# This will create a version file with 21.10 as the version, not 22.06
rapids_export(INSTALL ${PROJECT_NAME}
  EXPORT_SET ${PROJECT_NAME}-core-exports
  GLOBAL_TARGETS libmy_project
  VERSION
  NAMESPACE my_project::
)

Also ommitting the VERSION argument will hit the bug as well.

Expected behavior
As indicated by the documentation, when VERSION has no value or is ommitted as an argument, rapids_export should default to using PROJECT_VERSION.

Environment details (please complete the following information):

• CMake version 3.22

Additional context
This issue can be quickly fixed by changing the prefix used for cmake_parse_arguments. Currently the code uses cmake_parse_arguments(RAPIDS ...) which creates too common of variable names like RAPIDS_VERSION, RAPIDS_NAMESPACE, RAPIDS_DOCUMENTATION, etc. Instead the prefix should be something like _RAPIDS to prevent collisions.

Describe the bug

Using CMAKE_CUDA_ARCHITECTURES=NATIVE was accepted as an argument and working (maybe unintentionally) in CMake 3.22.x.

It is widely used in many CUDA libraries, e.g.
https://github.com/rapidsai/cudf/blob/branch-22.08/build.sh#L262

When trying with CMake 3.24.0-rc3, it has to be replaced by CMAKE_CUDA_ARCHITECTURES=native (i.e lowercase value) else it's failing with:

CMake Error at /some/local/install/share/cmake-3.24/Modules/CMakeDetermineCUDACompiler.cmake:279 (message):
  CMAKE_CUDA_ARCHITECTURES:
    NATIVE
  is not one of the following:
    * a semicolon-separated list of integers, each optionally
      followed by '-real' or '-virtual'
    * a special value: all, all-major, native

I suspect the new case sensitivity is related to the new regular expression in:
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7202/diffs#b2fb7bf5b0acdc13be102e624ffe8eb2175fd813_325_278

Is this intentional ? a regression ?
At least several official CUDA libraries no longer compile in some setups with 3.24.0-rc3

Additional context
Originally reported at https://gitlab.kitware.com/cmake/cmake/-/issues/23739

Is your feature request related to a problem? Please describe.

As seen by #56 and #57 rapids-cmake uses the host distro information to compute the lib directory name ( lib vs lib64 ). This means that conda packages built on CentOS will incorrectly use lib64

rapids-cmake should provide the necessary functionality so that consuming projects can correctly compute the correct library location.

Describe the solution you'd like

As brought up in #57 we need some general API that can be used by both rapids_export and users of cmake so that
the following. This function would determine if we are in a conda environment and use lib otherwise falling back to GNUInstallDirs for all other situations. This will allow RAPIDS projects to work correctly across multiple distros and package managers.

One proposal is to have rapids_cmake_install_lib_dir(out_variable_name) which would be used by consumers like this:

rapids_cmake_install_lib_dir(install_lib_dir)

install(TARGETS cugraph
        DESTINATION ${install_lib_dir}
        EXPORT cugraph-exports)
        
install(DIRECTORY include/cugraph/
        DESTINATION include/cugraph)

We could also provide an option flag to rapids_cmake_install_lib_dir that will allow callers to opt-in to modifying the CMAKE_INSTALL_LIBDIR value, but I don't want to make that implicit by default as that breaks the design rules of rapids-cmake