ROCm/TheRock: modular HIP and ROCm build system

TheRock's role in the ROCm build and release pipeline

ROCm/TheRock addresses the coordination problem behind AMD's GPU computing platform. It is both the open source build and release system for HIP and ROCm and the top-level entry point that combines individual ROCm components into one buildable, testable, and releasable product. According to the README, ROCm has used TheRock for builds and releases since ROCm 7.14.

The change matters because the previous process was monolithic. TheRock replaces it with a modular workflow, allowing components to be built, integrated, and distributed as parts of a larger product. The repository layout reflects that scope. Directories such as `compiler/`, `core/`, `math-libs/`, `ml-libs/`, `profiler/`, and `storage-libs/` separate major areas of ROCm, while `external-builds/` contains integrations such as PyTorch. Build tooling, packaging, CMake support, tests, and CI configuration have their own top-level locations.

The intended users are ROCm contributors, component developers, researchers, and advanced users who need recent ROCm capabilities or source-build flexibility. It is not positioned as a small application installer. It is infrastructure for producing the software stack and for investigating failures below the level of a Python wheel or operating-system package.

CMake orchestration around modular ROCm components

TheRock uses a CMake super-project as its integration layer. The repository contains `CMakeLists.txt`, `CMakePresets.json`, `FLAGS.cmake`, and `BUILD_TOPOLOGY.toml`, indicating that builds are organized through project-wide CMake configuration plus a declared component topology. This structure suits ROCm because the platform combines compilers, libraries, tools, and optional external projects rather than one self-contained application.

The Python side supports the surrounding build system. `pyproject.toml` identifies test locations under `build_tools/`, `cmake/`, `external-builds/pytorch/`, `test_tools/`, and `skills/therock_pr_bot/`. It marks `manual` tests as expensive or dependent on a particular environment, so routine automated selection excludes them unless they are explicitly requested. The declared test paths also show that packaging is not an afterthought. Archive, Linux, Python, Windows, third-party source management, and GitHub Actions helpers each have dedicated tests.

A source build therefore has two visible sides. CMake coordinates software components, while Python tooling supports testing, packaging, release automation, and external integrations. The README does not provide a complete command sequence for selecting components or starting a full local build, so the exact invocation cannot be inferred safely from these files. `CONTRIBUTING.md`, `TESTING.md`, `docs/environment_setup_guide.md`, and `CMakePresets.json` are the relevant project-specific starting points.

Ubuntu 24.04 setup before the first TheRock build

For most users, installing a supported prebuilt configuration is the documented shortcut. The README directs readers to `RELEASES.md` for instructions covering prebuilt ROCm, PyTorch, and JAX packages. That is the appropriate first route when a compatible release already meets the need. The README supplies no release package command in the available instructions, so none should be invented here.

A source-oriented user on Ubuntu 24.04 can begin by installing the dependencies and cloning the repository with the documented commands:

sudo apt update
sudo apt install gfortran git ninja-build cmake g++ pkg-config xxd automake libtool python3-venv python3-dev libegl1-mesa-dev texinfo bison flex
git clone https://github.com/ROCm/TheRock.git
cd TheRock

The first command updates package metadata, the second installs build tools and headers, and the remaining commands fetch the repository and enter its root directory. The presence of `ninja-build`, `cmake`, Python development packages, parsers, and platform headers matches the repository's combined CMake, packaging, and native-component workload.

The setup is not yet a complete build. The README continues with a patched `patchelf` installation, but the visible excerpt ends in the middle of that instruction. Follow `docs/environment_setup_guide.md` for the complete setup and its alternatives. The first real decision is whether to proceed with the full build or use the release instructions, because the source route can consume approximately 200 GB and multiple hours.

Release artifacts, source builds, and framework integrations

TheRock covers several delivery paths rather than treating every user as a source builder. The repository publishes nightly ROCm and PyTorch releases, and the README states that prebuilt ROCm, PyTorch, and JAX packages are covered by `RELEASES.md`. The release list includes ROCm Core SDK versions 10.1.0, 7.14.1, and 10.0.0 under corresponding TheRock release tags, but tags alone do not document installation compatibility. Supported operating systems and GPU coverage need to be checked in the release instructions and `SUPPORTED_GPUS.md`.

The documented platform scope includes multiple Linux distributions and native Windows. CI jobs are separated by concern, including ROCm artifacts, ASan-instrumented builds, native Linux package installation, PyTorch wheels for Linux and Windows, full PyTorch wheel tests, and JAX wheels for Linux. This separation provides more targeted status information than a single build badge. It also reveals that a successful ROCm artifact job does not automatically establish that every framework wheel has passed its own suite.

For source builds, TheRock supports PyTorch and JAX from source and tools for developing individual ROCm components. That is the main distinction from a traditional package-based ROCm installation. A release consumer receives selected artifacts, while a contributor may need to alter component integration, build flags, dependencies, or framework builds. The trade-off is substantial local cost and exposure to operating-system dependency differences, which the README identifies as a common cause of build failure.

Where a full TheRock build is the wrong choice

The clearest wrong-tool case is a user who only needs a supported binary distribution. The README explicitly says that installing from releases is often faster and easier than building from source. A full source build requires approximately 200 GB of free disk space and can take multiple hours. The README also warns that builds fail if disk space runs out. On a smaller development machine, this is an immediate capacity constraint rather than a minor inconvenience.

Source building is also a poor fit when dependency versions are unknown. The README states that many failures come from minor operating-system differences in dependencies and project setup. Its Ubuntu instructions are explicitly presented as instructions for a recent, commonly used operating system, while alternatives and contributed configurations belong in `docs/environment_setup_guide.md`. An engineer working from an unlisted OS arrangement should not assume that the Ubuntu dependency list is universally valid.

Component scope is another boundary. The repository is a large integration system, not a compact HIP installation. Selecting a narrower component build may fit an individual development task better than the full product, but the README does not give a verified component-selection command. The CMake presets and documentation must be consulted for that decision. Attempting the full build merely to validate a small source change can waste both disk capacity and compilation time.

Maintenance signals, CI separation, and MIT licensing

The repository is not archived, and its last push was on 2026-10-15. Recent releases include `therock-10.1` for ROCm Core SDK 10.1.0, `therock-7.14.1` for ROCm Core SDK 7.14.1, and `therock-10.0` for ROCm Core SDK 10.0.0. Those dates and release records support recent project activity, although they do not guarantee compatibility with any particular machine.

Maintenance work can affect more than source code because TheRock owns build, packaging, testing, and release integration. `requirements.txt` contains pinned and bounded dependencies, including `packaging==25.0`, `PyYAML==6.0.2`, `lit==18.1.8`, `psutil==7.1.3`, and a `boto3` range aligned with another dependency. A source contributor may therefore need to track both ROCm component changes and Python tooling changes. The separate CI jobs for ASan, package installation, PyTorch, and JAX also mean upgrade checks span multiple artifact classes.

The repository declares the MIT license. That permits use, modification, distribution, and sublicensing subject to the license conditions, but this article does not interpret the license for a particular organization. The operational upgrade cost remains visible in the 200 GB build footprint, multi-hour compilation, dependency setup, and separate framework test paths.

TheRock compared with direct ROCm package installation

The real alternative is the former package-oriented consumption model: installing supported ROCm, PyTorch, or JAX packages without using TheRock as a local source-build environment. The difference is not package format alone. TheRock acts upstream as the modular system that builds, integrates, tests, and releases the component set, while direct package installation consumes outputs that have already been produced.

For routine application development, direct installation is usually the more efficient boundary. It avoids managing the super-project's source dependencies and does not require the approximately 200 GB capacity cited for a full build. The README points users toward release instructions for supported configurations because that route is often faster and easier.

TheRock becomes the relevant choice when the task crosses that boundary. A ROCm contributor needs the build graph, an individual component developer may need specialized configuration, or a framework user needs PyTorch or JAX built from source. Adoption should therefore follow from the required level of control. Installing TheRock does not remove GPU, operating-system, or ROCm compatibility requirements, and a successful local source build does not by itself guarantee that the corresponding release artifacts passed every CI test.

Editorial conclusion

ROCm contributors, ROCm component maintainers, and advanced users who need source-level control should evaluate TheRock after confirming that their operating system and GPU are supported. Users seeking a conventional package installation should start with RELEASES.md rather than a source build, and anyone planning a custom build must first verify access to approximately 200 GB of free disk space and time for a multi-hour compile.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. ROCm/TheRock on GitHub