Repository navigation
build: wire TEST_SUBPROJECTS for math-libs and ml-libs components - #6646
endurthiabhilash wants to merge 1 commit into
Conversation
Add TEST_SUBPROJECTS entries to therock_cmake_subproject_declare blocks so downstream consumers are tracked for testing: - hipBLASLt: hipblasltprovider, MIOpen, rocBLAS - rocBLAS: hipblasltprovider, hipSPARSE, MIOpen, rocSOLVER, rocSPARSE, rocWMMA - rocSPARSE: rocPRIM, rocBLAS - hipBLAS: MIOpen, rocWMMA, hipSOLVER, hipSPARSE, rocSPARSE - rocPRIM: rocSOLVER - libhipcxx: rocThrust - composable_kernel: MIOpen - MIOpen: hipDNN_samples, hipdnn_integration_tests - miopenprovider: hipDNN_samples Co-Authored-By: Claude Sonnet 4 <noreply@anthropic.com>
✅ All Checks Passed — Ready for Review
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
🎉 All checks passed! This PR is ready for review. |
geomin12
left a comment
There was a problem hiding this comment.
lgtm, but let's get component teams to review and approve as well pls
|
Wait why do we need a dedicated variable for this? Can't we get this information from the build graph? If A depends on B, we should build/test A when B changes. We don't need B to be aware that A depends on it. |
purpose of the variable is to get granular component and their dependencies. I wanted to use build_topology.toml, but it was too broad. previously in rocm-libraries impl, for example, any blas (rocblas, hipblaslt, hipblas) update, we would build all of BLAS and test all of BLAS for all updates. however, ROCm devs let me know this is not efficient (ex: for rocblas updates, we don't need to test hipblaslt)! i looked around and couldn't find the granularity i wanted, so ended with this impl. @endurthiabhilash and I are happy to place it somewhere else, or if there is a way to pull this data more dynamically, let me know. it's fairly hard-coded and minimal impact |
|
Yeah, the build topology is not the right tool to use here. In the CMake next to where TheRock/cmake/therock_subproject.cmake Lines 1482 to 1527 in 44164a5 that says "for a given project, what are all the transitive dependencies" when here you want "for a given project, what are all the transitive consumers". May need a subproject registry if one doesn't already exist to be able to compute that. The explicit |
ack! this hard-coded item is matching the I'm planning to swap CI systems over for superrepos (so we get it done). this will work for now, then we can work on swapping this out this portion to dynamically select and make it more sophisticated @endurthiabhilash and I will create GH issue |
geomin12
left a comment
There was a problem hiding this comment.
as mentioned here (#6646 (comment)), this is not an ideal solution. However, this is a replicate of therock-matrix.py and this will apply to multi-arch.
After multi-arch migration happens, @endurthiabhilash and I are going to work to improve this retrieval to be dynamic. Especially if https://github.com/ROCm/TheRock/blob/main/docs/rfcs/RFC0003-Build-Tree-Normalization.md occurs, we want our solution to be workable for both CMakeLists scenarios
|
No longer needed as #6941 dynamically selects sub projects. |
As part of enabling multi-arch on rocm-libraries #3343, adding TEST_SUBPROJECTS entries to therock_cmake_subproject_declare blocks so downstream consumers are tracked for testing:
Motivation
Technical Details
Test Plan
Test Result
Submission Checklist