[Issue]: Tensile should not be vendored

[bgamari]

Problem Description

It appears that hipBLASLt depends upon Tensile. However, instead of recognizing this fact, the dependency is ignored by the documentation and is instead vendored.

Vendoring of dependencies creates untold headaches for distributors as the packager needs to:

• identify the implicit dependency
• sort out what version of the dependency the package expects
• figure out how to furnish the dependency in a way that works with whatever bespoke mechanism the package has developed
• continually maintain all of the above as the package and its dependency evolve

For this reason, vendoring of dependency is highly discouraged. If hipBLASLt depends upon Tensile then there is a proper way to do so: advertise the dependency in the readme, and discover it via the usual dependency discovery mechanisms.

Operating System

Any

CPU

All

GPU

Other

Other

this is a packaging issue and not hardware specific

ROCm Version

ROCm 6.2.3, ROCm 6.2.2, ROCm 6.2.1, ROCm 6.2.0, ROCm 6.1.2, ROCm 6.1.1, ROCm 6.1.0, ROCm 6.0.2

ROCm Component

hipBLASLt

Steps to Reproduce

No response

(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support

No response

Additional Information

No response

[IMbackK]

tensilelight in this repo is a hard fork from the tensile of rocblas, its not so mutch a vendored tensile as it is something else entirely

[bgamari]

Thanks for the clarification. Nevertheless, it would be appreciated if this project (and ROCm projects more broadly) would make less use of build-time fetching of dependencies as this greatly complicates packaging. Specifically, many packaging policies strictly prohibit fetching of further resources from the internet. The source distribution (e.g. git repository or source tarball) must include everything necessary to build the the package. Many distributions go even further than this, prohibiting usage of vendored dependencies entirely. This is generally out of concern for security, auditability, and maintainability.

If the dependency is tightly-coupled to hipBLASLt then consider turning it into a git submodule. If not then make it a proper dependency.

I understand the introduction of dependency-fetching logic is often made with the good intention of making users' lives easier, but it generally makes packagers' lives harder, not easier. If such logic is still desired for end-users then the package's installation documentation should clearly describe how such logic can be disable and how the dependencies can be furnished via traditional means.

[ppanchad-amd]

As per our internal team: hipBLASLt doesn't depend on Tensile. hipBLASLt has its own kernel generator inside hipBLASLt.