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
