Upgrade to spdlog 1.10#1173
Conversation
|
Pull requests from external contributors require approval from a |
| - python | ||
| - scikit-build>=0.13.1 | ||
| - setuptools | ||
| - spdlog>=1.8.5,<2.0.0a0 |
There was a problem hiding this comment.
As far as I could tell the RMM cython doesn't directly use spdlog in any way other than needing to find it during build time because of the librmm dependency. It will get spdlog from the run dependency of the librmm recipe.
|
Apparently I no longer have permissions to set labels...? |
|
EDIT: PR here: rapidsai/rapids-cmake#312 |
|
/ok to test |
|
@kkraus14, I'm unaware of any permissions changes for your user account recently. I'll have to look into why you're unable to label PRs anymore. Regarding CI, we are in the process of switching RAPIDS to using GitHub Actions. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## branch-23.02 #1173 +/- ##
==============================================
Coverage ? 0.00%
==============================================
Files ? 5
Lines ? 406
Branches ? 0
==============================================
Hits ? 0
Misses ? 406
Partials ? 0 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@gpucibot merge |
|
We have a reported compile issue today: Is that due to this PR? Ref: https://nvidia.slack.com/archives/CDTANRCTT/p1670243383311319 |
This reverts commit 7bf7a76.
This reverts commit 7bf7a76. cc: @kkraus14 There's a handful of issues this caused downstream. We'll be sorting through these and fixing them but need to quickly revert this for now. Currrent problems: 1. rmm's meta.yaml doesn't correctly specify spdlog as a build dep. It's [incorrectly listed as a runtime dep](https://github.com/rapidsai/rmm/blob/7bf7a763a3b6a32a7a57f900de35e2e5f30f17c0/conda/recipes/librmm/meta.yaml#L56). This means that rmm [pulls spdlog via CPM with rapids-cmake](https://github.com/rapidsai/rmm/actions/runs/3595940512/jobs/6056061203#step:6:595) `-- CPM: adding package spdlog@1.8.5 (v1.8.5)` and then clobbers its own installed spdlog headers: ``` 2022-12-01T19:46:46.2167513Z ClobberWarning: This transaction has incompatible packages due to a shared path. 2022-12-01T19:46:46.2168766Z packages: conda-forge/linux-64::spdlog-1.10.0-h924138e_0, file:///tmp/conda-bld-output/linux-64::librmm-23.02.00a-cuda11_gc328a18d_11 2022-12-01T19:46:46.2169686Z path: 'include/spdlog/async.h' ``` 2. spdlog 1.10.0 doesn't work with nvcc. We need spdlog 1.11.0 to get fmt 9.1.0, which contains [a necessary fix](fmtlib/fmt#2971). However, there's some uncertainty about how to handle the spdlog conda-forge package which [no longer vendors fmt](conda-forge/spdlog-feedstock#50) while rapids-cmake is still using the upstream repo which continues to vendor fmt. Does this inconsistency matter, as long as we pin `fmt=9.1.0` in the conda package cases? @kkraus14 It looks like you weighed in on this matter [here](conda-forge/spdlog-feedstock#53) and [here](conda-forge/conda-forge-pinning-feedstock#3654). If you have insights that can help us with this quandary, please share! Authors: - Bradley Dice (https://github.com/bdice) Approvers: - Mark Harris (https://github.com/harrism) - Ray Douglass (https://github.com/raydouglass) URL: #1176
This looks like spdlog is being treated as a |
Description
Updates spdlog dependency to 1.10 to match the conda-forge pinning. Depends on rapidsai/rapids-cmake#312
Also updates the flake8 pre-commit hook location since it's migrated from gitlab to github.
Checklist