Update to 2.2.0 (and switch to monorepo)

[conda-forge-admin]

Fixes #2

• Update to CCCL 2.2.0
• Switch to using CCCL monorepo (instead of combining the sources ourselves)
• Use CMake & Ninja to install (instead of manually copying files)
• Disable tests as those are irrelevant here (CCCL is header-only and tests add CPM dependencies)

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to update the version for you, but it looks like there was nothing to do.

I am closing this PR!

This message was generated by GitHub actions workflow run https://github.com/conda-forge/cccl-feedstock/actions/runs/7893076871.

[jakirkham]

@conda-forge-admin , please re-render

[jakirkham]

Noticing we haven't done the arch migration here. Going to pause and start that first: conda-forge/conda-forge-pinning-feedstock#5501

Will come back to this after that is done

Edit: Was done in PR: #7

[jakirkham]

@conda-forge-admin , please re-render

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/cccl-feedstock/actions/runs/7894807589.

[jakirkham]

Weird, for some reason when running python build-locally.py, the source is put in this directory. However on CI (or if the Docker image is spun up manually and the build is done in there), the source directory is not named this way (and is not nested)

[jakirkham]

@conda-forge-admin , please re-render

[jakirkham]

@jrhemstad , could you please look over this and let me know if there is anything that we need to change here?

Want to make sure we are picking up all the files we need to. Looks just like a couple of CMake files, but please let us know if we need other components as well

[jakirkham]

Highlighted the relevant CCCL changes below

Otherwise this just copies over the same Thrust, CUB & libcudacxx files as before

Please let us know if there is anything else we should have here

[jakirkham]

@conda-forge-admin , please re-render

[jakirkham]

@conda-forge-admin , please re-render

[jakirkham]

@conda-forge-admin , please re-render

[jakirkham]

@conda-forge-admin , please re-render

[jakirkham]

Following up on Rob's suggestion to use a relative path for CMAKE_INSTALL_LIBDIR

[jakirkham]

Rob also suggested offline that we add a test to verify find_package(CCCL) works correctly. Will look into that next

[jrhemstad]

Rob's approval means a lot more than mine, but I'll still approve fwiw 🙂

[jakirkham]

Thanks you both! 🙏

If anything else comes up, would be happy to follow up 🙂

[leofang]

Thanks everyone!

[robertmaynard]

We want to validate that the CCCL includes are coming from the package we just made and not the version packaged in the CUDAToolkit.
I believe that the following check should be added at the end:

get_target_property(cccl_raw_includes CCCL::libcudacxx INTERFACE_INCLUDE_DIRECTORIES)
foreach(item IN LISTS cccl_raw_includes)
  foreach(toolkit_path IN LISTS CUDAToolkit_INCLUDE_DIRS)
    cmake_path(IS_PREFIX toolkit_path "${item}" NORMALIZE is_prefix)
    if(is_prefix)
      message(FATAL_ERROR "Failed to find conda version of the CCCL. Instead found version within the CUDAToolkit")
    endif()
  endforeach()
endforeach()

[jakirkham]

Right now this is run on CUDA 11.8 where the NVIDIA CUDA-based Docker images are used. Here are the results we see with that

-- The CUDA compiler identification is NVIDIA 11.8.89
-- Detecting CUDA compiler ABI info
-- Detecting CUDA compiler ABI info - done
-- Check for working CUDA compiler: $PREFIX/bin/nvcc - skipped
-- Detecting CUDA compile features
-- Detecting CUDA compile features - done
-- Found CUDAToolkit: /usr/local/cuda/targets/x86_64-linux/include (found version "11.8.89") 
-- Found libcudacxx: $PREFIX/lib/cmake/libcudacxx/libcudacxx-config.cmake (found suitable version "2.2.0.0", minimum required is "2.2.0.0") 
-- Found Thrust: $PREFIX/lib/cmake/thrust/thrust-config.cmake (found suitable exact version "2.2.0.0") 
-- Found CUB: $PREFIX/lib/cmake/cub/cub-config.cmake (found suitable version "2.2.0.0", minimum required is "2.2.0.0") 
-- Found CCCL: $PREFIX/lib/cmake/cccl/cccl-config.cmake (found version "2.2.0.0") 
-- CCCL info:
--     config: $PREFIX/lib/cmake/cccl/cccl-config.cmake
--     version: 2.2.0.0
-- Configuring done (3.3s)
-- Generating done (0.0s)
-- Build files have been written to: $SRC_DIR/test_cmake

So that seems to point $PREFIX as expected

On CUDA 12, we ensured that $PREFIX (so this cccl) come before the targets directory in the search order

If we are concerned about cuda-cccl from targets being picked up, should we just override CMAKE_FIND_ROOT_PATH in the test?