Hi Étienne, On 2022-10-26 12:44, Étienne Mollier wrote:
I'm not too sure yet of the implementation to not export the oam target; this looks to have been autogenerated by cmake. About the dependency, I'm thinking twice before making that a hard one, since it is possible to make use of the headers without pulling the oam, at least from my quick test. What do you think about simply recommending the installation?
I think recommending the package makes sense, as upstream seems to install them together. That's a good start, but I think we can do more than that.
The oam target code is generated by CMake, but it appears to be exported by this line here: https://github.com/RadeonOpenCompute/rocm_smi_lib/blob/rocm-5.3.0/CMakeLists.txt#L183
(Incidentally, "rcom_smi_target.cmake" looks like a typo.)I think we could probably create a patch that splits the rocm_smi and oam CMake config files. We'd remove oam from the rocm_smi exported targets and create an oam-config.cmake file, so it could be exported as its own thing. find_package(oam) would then be used to get the oam target.
To make Debian's behaviour compatible with upstream when both libraries are installed, we could modify the rocm_smi-config.cmake template (rocm_smi-config.cmake.in), so that find_package(rocm_smi) does a find_package(oam QUIET).
And maybe try to upstream the split? Sincerely, Cory Bloor