Re: New src:rocm-compiler for hipcc, comgr and device-libs
Hi Xuanteng,
I did a more detailed review now. Looks good :)
On 2024-09-06 09:55, Xuanteng Huang wrote:
> 1. Determine the name of source package
>
> There is already a removed package named rocm-llvm in Salsa [2], and I think rocm-llvm is not precise to describe the content as this package doesn’t provide LLVM. Not sure whether rocm-compiler is concrete enough.
On 2024-09-06 09:55, Xuanteng Huang wrote:
> 1. Determine the name of source package
>
> There is already a removed package named rocm-llvm in Salsa [2], and Ithink rocm-llvm is not precise to describe the content as this package
doesn’t provide LLVM. Not sure whether rocm-compiler is concrete enough.
On 2024-09-10 09:11, Cordell Bloor wrote:
> The upstream repository is the AMD ROCm fork of LLVM and I would be
tempted to name it rocm-llvm even if we've decided to strip out all but
the unique components of the ROCm fork.
I'm also leaning towards this. Assuming an outsider stumbles over our
repositories [4], I think rocm-llvm would be less mental effort to
associate with the upstream project, even if the actual LLVM is stripped.
We should also at least take a look at Fedora's approach [5]. Perhaps
Jeremy or Tom could expand on this?
Some other thing that I noticed reviewing just now: rocm-hipamd
currently also ships:
* libamdhip64-5
* libamdhip64-dev
* libhiprtc-builtins5
* libamhip64-doc
The new package does not. If I understand the situation correctly, this
is because 6.1 works against upstream LLVM directly, right?
> 2. File concflicts of binary packages
>
> Intuitively, there will be some file conflicts between the binary packages generated from the holistic new source and the original separated source packages (e.g., /usr/bin/hipcc). At least we should “rename” the binary packages and declare the conflict relations between them.
The package names can stay the same, and the newer same-named packages (like hipcc) need Breaks+Replaces.
I'm not yet sure if we need any other Breaks or Conflicts. For example: if a newer hipcc is installed, what happens to libamdhip64-5?
> 3. (Optional) Migrate tests
>
> There are some tests for the compilers [3], but they depend on rocminfo (and possibly other packages). We should package them with 6.1.2 version as well.
Agreed. Since this is a pretty major change, we'll need these tests to quickly discover if things went alright.
The old rocm-hipamd had a buildd workaround in d/rules where some
architectures were offloaded. I don't know if this is still relevant,
but we should keep that in mind in case we see a FTBFS.
Finally, as a general question to all, I wonder whether we should leave
the lintian warnings on the /usr/bin/*.pl scripts active. For example,
we have
/usr/bin/hipcc
which calls
/usr/bin/hipcc.pl
but does anything call /usr/bin/hipcc.pl directly? If not, it might be
best to move it to some private directory, and patch /usr/bin/hipcc to
call it there. Same for hipconfig.pl.
Best,
Christian
> [1]: https://salsa.debian.org/xuantengh/rocm-compiler
> [2]: https://salsa.debian.org/rocm-team/rocm-llvm
> [3]: https://salsa.debian.org/rocm-team/rocm-hipamd/-/tree/master/debian/tests
[4]: https://salsa.debian.org/rocm-team/
[5]: https://src.fedoraproject.org/rpms/rocm-compilersupport
Reply to: