[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ROCm 5.4.0 Released



Hi Étienne,

On 2022-12-02 03:49, Étienne Mollier wrote:
That being said, in such context, would it still be worth
bumping at least the rocm-cmake version in the unstable and then
testing distribution?

I'm one of the upstream maintainers of rocm-cmake, so I may be a little biased, but I would bump it on unstable/testing. The change to respect CMAKE_INSTALL_LIBDIR in ROCm 5.3 was made specifically to improve the experience of building the ROCm libraries for distros. There were no relevant changes to rocm-cmake in ROCm 5.4.

I agree with you that we should largely leave the ROCm stack untouched on unstable aside from bugfixes, but it's worth trying to get a newer rocm-cmake in there. I'm trying to ensure that rocm-cmake from ROCm 5.3 is a reasonable minimum version for building the ROCm libraries from source (on Linux) for a long time. For that reason, it would be unfortunate if Bookworm was frozen with rocm-cmake from ROCm 5.2.

Note that you don't have to update everything in the stack to update rocm-cmake. Most of the packages that depend on rocm-cmake only use ROCMSetupVersion.cmake, which in an independent module that hasn't changed since ROCm 4.1. There's only one package that will be affected if rocm-cmake were to be updated: rocprim.

rocprim will FTBS on experimental now that rocm-cmake from ROCm 5.4 has been uploaded. That's because rocprim >=5.3 with rocm-cmake >=5.3 will respect the `-DCMAKE_INSTALL_LIBDIR=lib/$(DEB_HOST_MULTIARCH)` that is automatically passed by Debian tooling (and thus install exported targets into /usr/lib/x86_64-linux-gnu/cmake rather than /usr/lib/cmake as is specified in the install file).

To prevent the build failure in rocprim, you can add `-DCMAKE_INSTALL_LIBDIR=lib` to its cmake flags and thereby ensure you get the same build results with both rocm-cmake 5.2 and rocm-cmake 5.4.

Though, if we're updating the rocprim package... should the package be Archiecture: all? It's header-only, so I'd imagine so. I think I missed that when I was preparing the package... mea culpa.

Sincerely,
Cory


Reply to: