-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make 'librmm' a 'host' dependency for conda packages #2284
Conversation
Alright there are still two @bdice @ajschmidt8 since you'd done previous work related to this dependency, could you take a look? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup. That'd explain it. I made a mistake in #2102 in my recollection of how conda uses host
dependencies. This should be a proper fix.
/merge |
Contributes to rapidsai/build-planning#54.
The
libraft-headers
andlibraft-headers-only
conda packages are bundlingrmm
's headers. I believe that's because thelibrmm
conda package isn't available in thelibraft*
conda build environment, and as a result it's gettingrmm
via CPM (thanks torapids-cmake
).As a result, this project and any that depend on it are seeing warnings like the following in conda builds where
conda
'spath_conflict
setting is set towarn
orprevent
(like #2245):To fix that, this proposes the following changes:
librmm
ahost
dependency of the following conda packages:libraft-headers-only
,libraft-headers
Benefits of this change
libraft-headers
andlibraft-headers-only
conda packagesNotes for reviewers
History of changes to the
librmm
dependency forlibraft-headers
:run
andhost
: Adjusting conda packaging to remove duplicate dependencies #508run
andhost
, but ignoring itsrun_exports
: Remove duplicatelibrmm
runtime dependency #1264run
, but ignoring itsrun_exports
: Remove extraneous host pinnings from libraft-headers-only. #2102In particular, #2102 referred to the
host
dependency onlibrmm
as "extraneous" but from a packaging perspective, I don't think it is.librmm
being inhost
means it'll be present in the build environment, which means its headers will be found instead of downloaded, and therefore not packaging into thelibraft*
conda packages.How I tested this
Built all the
raft
conda packages locally frombranch-24.06
and confirmed that they containrmm
headers. Then again from this branch and confirmed they were gone.Also checked the CI logs from
conda-cpp-build
jobs here. On other recent PRs, I see CPM downloadingrmm
...... and all the
rmm
headers getting installed as part of thelibraft-headers
package(build link)
Here, I see
librmm
coming through via the conda package requirements ...... and being used instead of downloads via CPM ...
... and no installation of the
rmm
headers as part of building anylibraft
packages.(build link)