hip::host and hip::device is only defined in hip-config.cmake. Keeping FindHIP introduces cmake bugs that are difficult to trace. For example, rocFFT in Prefix does not include the correct hip-config.cmake but is confused by FindHIP.cmake. Dropping FindHIP was a serious consideration after the endless debugging of the nondeterministic behaviors caused by having both hip-config and FindHIP. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5223e983a0810e46633362ff4dbad6a194208819 I suggest the way forward is to understand the function of hip_add_executable() cmake function, patch torch/roctracer or provide it in hip-config.cmake. Reproducible: Always
I could build roctracer-5.7.1-r1 with hip-5.7.1-r1 (without FindHIP.cmake). roctracer is no longer a blocker. FindHIP is only for torch. It is torch that should be fixed.
I don't really consider this something I have any input on, I'm just reviewing the PRs.
I think whether FindHIP.cmake should be removed needs to directly discuss with upstream. The simplest way I see is to fix packages to force them use hip-config.cmake if they fail to configure
> I think whether FindHIP.cmake should be removed needs to directly discuss with upstream. It is only useful when you wrap CUDA with ROCm. See: https://github.com/ROCm/hipamd/issues/39
(In reply to Benda Xu from comment #4) > > I think whether FindHIP.cmake should be removed needs to directly discuss with upstream. > > It is only useful when you wrap CUDA with ROCm. > > See: https://github.com/ROCm/hipamd/issues/39 FindHIP.cmake is only useful situation is pytorch[rocm] and roctracer[test]. (In reply to Benda Xu from comment #1) > I suggest the way forward is to understand the function of > hip_add_executable() cmake function, patch torch/roctracer or provide it in > hip-config.cmake. > > Reproducible: Always The best way out is already mentioned, to patch (and upstream) them move on to the more modern way, using hip-config.cmake: Another workaround is hide FindHIP.cmake somewhere, and during src_prepare of pytorch[rocm] or roctracer[test] we put it in ${S}/cmake. The 3rd way is what https://github.com/gentoo/gentoo/pull/39063 does, just fix any package that should use the modern hip-config.cmake but seek for FindHIP.cmake by accident. Then upstream the fix. Solution 1 & 3 are upstream-able so could benefits all. Solution 2 & 3 take much less efforts than 1.
Another option is using https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_PACKAGE_PREFER_CONFIG.html and don't patch while we wait for upstream to implement our solution.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=582d164f4850c6c5b2b491214b404c58bad6e088 commit 582d164f4850c6c5b2b491214b404c58bad6e088 Author: Yiyang Wu <xgreenlandforwyy@gmail.com> AuthorDate: 2024-10-21 02:26:26 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-01-26 13:59:29 +0000 sci-libs/rocFFT: force using hip-config.cmake instead of FindHIP.cmake Closes: https://bugs.gentoo.org/932155 Signed-off-by: Yiyang Wu <xgreenlandforwyy@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> .../files/rocFFT-6.1.1-find-hip-use-config.patch | 31 ++++++++++++++++++++++ sci-libs/rocFFT/rocFFT-5.7.1-r2.ebuild | 1 + sci-libs/rocFFT/rocFFT-6.1.1.ebuild | 3 ++- sci-libs/rocFFT/rocFFT-6.3.0.ebuild | 3 ++- 4 files changed, 36 insertions(+), 2 deletions(-)