standardize CMake linting and auto-formatting across RAPIDS

Description

As of this writing, CMake formatting varies somewhat across RAPIDS. It would be great to standardize the look and feel of CMake code across RAPIDS, and pre-commit seems like a good system to do that.

This could involve creating new hooks or choosing from the existing third-party open-source projects.

Benefits of this work

• standardization enforced by tools = less effort put into style-related review comments
• static analysis = reduced risks of bugs making it through review (especially helpful for code paths not touched by CI)
• creating an easier-to-adopt approach for CMake linting should improve the likelihood that projects adopt it

Acceptance Criteria

• RAPIDS projects use pre-commit hook(s) for CMake autoformatting and linting

Approach

1. Review the current approaches used across RAPIDS

Several RAPIDS projects use the following approach:

1. vendor shell script that invokes cmake-format and cmake-lint in pre-commit-friendly ways (example: cudf/cpp/scripts/ run-cmake-format.sh)
2. vendor a config file for cmake-format (example: cudf/cpp/cmake/config.json)
3. at runtime in CI, download more configuration from the rapids-cmake repo like this:

RAPIDS_VERSION_MAJOR_MINOR="$(rapids-version-major-minor)"
FORMAT_FILE_URL="https://raw.githubusercontent.com/rapidsai/rapids-cmake/branch-${RAPIDS_VERSION_MAJOR_MINOR}/cmake-format-rapids-cmake.json"
export RAPIDS_CMAKE_FORMAT_FILE=/tmp/rapids_cmake_ci/cmake-formats-rapids-cmake.json
mkdir -p $(dirname ${RAPIDS_CMAKE_FORMAT_FILE})
wget -O ${RAPIDS_CMAKE_FORMAT_FILE} ${FORMAT_FILE_URL}

(example: cudf/ci/check_style.sh)

4. Invoke those scripts, using that configuration, using "local" pre-commit hooks, like this:

      - id: cmake-format
        name: cmake-format
        entry: ./cpp/scripts/run-cmake-format.sh cmake-format
        language: python
        types: [cmake]
        additional_dependencies:
          - cmakelang==0.6.13
        verbose: true
        require_serial: true
        exclude: |
          (?x)^(
            cpp/cmake/Modules/FindCUDAToolkit[.]cmake$
          )
      - id: cmake-lint
        name: cmake-lint
        entry: ./cpp/scripts/run-cmake-format.sh cmake-lint
        language: python
        types: [cmake]
          - cmakelang==0.6.13
        verbose: true
        require_serial: true
        exclude: |
          (?x)^(
            cpp/cmake/Modules/FindCUDAToolkit[.]cmake$
          )

(example: cudf/.pre-commit-config.yaml)

2. Review open-source options

Both cmake-format and cmake-lint have official pre-commit hooks.

• https://cmake-format.readthedocs.io/en/latest/installation.html#pre-commit
• https://github.com/cmake-lint/cmake-lint/tree/develop?tab=readme-ov-file#usage

These might not have existed or might not have fits RAPIDS needs when the approach described above was first introduced.

3. Pick a path and implement it

Some functionality I think we want:

• fast execution
• lightweight installation (e.g. npm / Node, go)
• minimal at-check-time network requests
• minimal vendoring of identical files
• auto-formatting
• RAPIDS-specific configuration (example: https://github.com/rapidsai/cugraph/pull/4889#discussion_r1927724090)
• helpful logs

Notes

Historical context:

• https://github.com/rapidsai/rapids-cmake/blob/3a35e72257175978bd78a1903f4fdbde0c9e06dd/ci/checks/run-cmake-format.sh#L5-L19
• https://github.com/rapidsai/cugraph/pull/4889#pullrequestreview-2571696715
• https://github.com/rapidsai/cudf/pull/9484
• https://github.com/rapidsai/rapids-cmake/pull/336