Repository navigation
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Should this
_openmpi_optional_depbe a build dep or a runtime dep?The other uses have it in
RUNTIME_DEPS:TheRock/profiler/CMakeLists.txt
Lines 257 to 268 in 29faf3b
TheRock/profiler/CMakeLists.txt
Lines 348 to 361 in 29faf3b
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.
I believe, It should stay in BUILD_DEPS. The find_package(MPI) in rocprofiler-sdk fires at configure time. the dep provider intercepts it before a single source file is compiled. I feel, the other subprojects that put _openmpi_optional_dep in RUNTIME_DEPS are most likely only using MPI for test execution, not as a compile-time linking dependency.
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.
All
RUNTIME_DEPSare alsoBUILD_DEPS, not allBUILD_DEPSareRUNTIME_DEPS, seeTheRock/cmake/therock_subproject.cmake
Lines 244 to 248 in 29faf3b
If MPI is only used at build time then
BUILD_DEPSis appropriate. If it's also used at run time then it should go inRUNTIME_DEPS.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.
Thanks @ScottTodd for linking #6610 and #5627, Keeping BUILD_DEPS, MPI is intentionally not distributed with ROCm artifacts (from #6610 which added the dedicated OpenMPI test image for exactly this reason, and #5627 which wires rocprofiler-sdk tests to use it). libmpi.so is satisfied at test runtime via the container
image, not shipped with release artifacts, so BUILD_DEPS would be accurate here?
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.
Maybe? I'd prefer local consistency with a small fix like this.
If we need MPI available at configure time but we don't want to distribute it (leaving it as an optionally dynamically linked runtime dependency), then I think
BUILD_DEPScould work, but we'd want to be careful about how we represent that in the build and packaging files. Pretty much all of our other dependencies expect to be vendored and distributed together with the libraries and tests.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.
Good point on local consistency, I'll move it to RUNTIME_DEPS to match rocprofiler-compute and rocprofiler-systems. The proper long-term fix (guarding find_package(MPI) in rocprofiler-sdk's cmake so it's not reached in standard builds at all) will come as a follow-up PR in rocprofiler-sdk, which will make the dep declaration here moot when THEROCK_ENABLE_MPI=OFF. Moving now to unblock RCCL CI.