update `fmt` and `spdlog` across RAPIDS

[jameslamb]

Description

RAPIDS projects that need fmt and spdlog use rapids-cmake to find it, via functions like rapids_cpm_fmt() (docs link).

rapids-cmake is currently carrying patches to both of those libraries, and as a result always downloads sources of them. (see rapidsai/rapids-cmake#525 for details).

Those patches have since been upstreamed and made it into official releases of those projects (in their main source control and on conda-forge). This proposes upgrading to those new versions across RAPIDS and dropping the patches in rapids-cmake.

Benefits of this work

• reduces RAPIDS package sizes a bit
• fixes warnings about file-clobbering in conda builds across many RAPIDS projects
  • ... which would allow enforcing a CI check in rmm to ensure future such conflicts raise a loud error
  • ... which would reduce the visual noise in logs, improving developer productivity (e.g. WIP: Prevent path conflict in builds rmm#1508 (comment))
• removes some patches from rapids-cmake and therefore the need to reason about them in future upgrades

Acceptance Criteria

• rapids-cmake is pulling in fmt >= 11.0.1
• rapids-cmake is pulling in spdlog >= 1.14
• all RAPIDS projects enforce those floors in their build environments
• there are 0 warnings about clobbering fmt and spdlog in rmm's conda build CI logs
• 0 RAPIDS projects' CI is failing as a result of these changes

Approach

On a branch, modify rapids-cmake/cpm/versions.json (code link) such that:

• the versions for fmt and spdlog are bumped to these new ones
• the patches for those libraries are removed

Follow "Overriding RAPIDS CMake" (rapids-cmake docs) to point builds of at least rmm, cudf, and raft at your branch of rapids-cmake with these changes. Also modify those projects' dependencies.yaml and/or conda recipe meta.yaml to change their version constraints on fmt and spdlog.

NOTE: this is a great task for rapids-reviser (https://github.com/rapidsai/rapids-reviser/tree/main/examples/fmt-10-spdlog-1.12).

Confirm that CI succeeds and that the correct versions of fmt and spdlog are being pulled in.

For rmm, re-use this PR for that purpose: rapidsai/rmm#1508. If this change also results in there being 0 remaining conda clobbering warnings in rmm, leave in the conda config --set path_conflict prevent in that PR's build scripts, so we'll be alerted by a CI failure if something around this changes in the future.

Notes

What makes you confident that these patches can be removed?

From #54 (comment)

fmt's most recent release was 11.0.2, so that patch we're carrying around for the 10.1.1 version could be dropped.

• our patch in rapids-cmake: (fmt/fix_10_1_1_version.diff)
• v10.2.1 release on conda-forge removing a similar patch: fmt v10.2.1 conda-forge/fmt-feedstock#48

The spdlog patch we've been carrying around has been upstreamed

• our patch in rapids-cmake: (spdlog/nvcc_constexpr_fix.diff)
• to v1.13.0 of spdlog: Match SPDLOG_CONSTEXPR_FUNC to FMT_CONSTEXPR gabime/spdlog#2901
• v1.13.0 of the conda-forge recipe is up: spdlog v1.13.0 conda-forge/spdlog-feedstock#61

What are "clobber warnings" and how does this help with them?

As described in #54 and rapidsai/rmm#1508, conda builds of rmm and other RAPIDS packages downstream of it are emitting dozens of warnings like these:

This transaction has incompatible packages due to a shared path.
  packages: conda-forge/linux-aarch64::fmt-10.2.1-h2a328a1_0, file:///tmp/conda-bld-output/linux-aarch64::librmm-24.06.00a16-cuda12_240419_g9dfd9070_16
  path: 'include/fmt/chrono.h'

This transaction has incompatible packages due to a shared path.
   packages: conda-forge/linux-aarch64::spdlog-1.12.0-h6b8df57_2, file:///tmp/conda-bld-output/linux-aarch64::librmm-24.06.00a16-cuda12_240419_g9dfd9070_16
   path: 'include/spdlog/async.h'

These are saying that the librmm conda package contains files whose paths exactly conflict with those from the fmt and spdlog packages from conda-forge. When such packages are installed together, one will overwrite the other, which could lead to runtime issues.

Removing the patches in rapids-cmake makes it more likely that builds will find the files they need from the fmt and spdlog conda-forge packages already present in the build environment, and therefore not vendor them, and therefore not ship a copy that causes conflicts.

### Code changes (these PRs should be merged)
- [x] `rapids-cmake` (https://github.com/rapidsai/rapids-cmake/pull/689)
- [x] `rmm` (https://github.com/rapidsai/rmm/pull/1678)
- [x] `cudf` (https://github.com/rapidsai/cudf/pull/16806)
- [x] `ucxx` (https://github.com/rapidsai/ucxx/pull/278)
- [x] `raft` (https://github.com/rapidsai/raft/pull/2433)
- [x] `cuspatial` (https://github.com/rapidsai/cuspatial/pull/1441)
- [x] `cuml` (https://github.com/rapidsai/cuml/pull/6071)
- [x] `integration` (https://github.com/rapidsai/integration/pull/722)

### Testing dependencies (do not merge)
- [x] `cuvs` (https://github.com/rapidsai/cuvs/pull/335)
- [x] `cumlprims_mg` (https://github.com/rapidsai/cumlprims_mg/pull/211)
- [x] `cugraph-ops` (https://github.com/rapidsai/cugraph-ops/pull/692)
- [x] `cugraph` (https://github.com/rapidsai/cugraph/pull/4655)

### Post-migration
- [x] Revert pinnings on geospatial dependencies and specific RAPIDS alphas in `integration` (ref: https://github.com/rapidsai/integration/pull/719#discussion_r1761816933 ... as of now, part of https://github.com/rapidsai/integration/pull/722)

[jameslamb]

@bdice drew my attention to these global pins in conda-forge-pinning-feestock:

fmt:
  - '10'

spdlog:
  - '1.12'

(code link)

I think the fmt one shouldn't be a problem for this migration, but the spdlog one will. There's an ongoing conda-forge migration to spdlog==1.13.0, but I don't know how to estimate how long that'll take: https://conda-forge.org/status/migration/spdlog113.

I think we should NOT update any RAPIDS packages to depending on the spdlog==1.13.0 conda-forge package until that conda-forge migration to that version is done. Does that seem right @jakirkham @bdice ?

References:

• "Pinned dependencies" (conda-forge docs)
• https://github.com/conda-forge/conda-forge-pinning-feedstock

[bdice]

Yes, we should try to keep RAPIDS in sync with conda-forge. For these, I would move them forward once the migrator passes some critical threshold (for spdlog, I might base it on when packages like mamba and micromamba are migrated).

For the purpose of fixing our conda clobbering issues, we may want to work on some kind of vendoring solution (centralized via rapids-core-dependencies or copied in each RAPIDS conda package) because we have to carry patches for fmt and spdlog in rapids-cmake anyway. If we do that, we can remove all host/run dependencies on the conda-forge packages of fmt and spdlog and instead get them from upstream via rapids-cmake / CPM.

Also, if we vendor these and remove the dependencies from the RAPIDS conda packages, it would also make it possible to decouple from the global conda-forge pinnings and manage version updates solely through rapids-cmake (the status quo requires changes in both rapids-cmake and conda recipes).