Version manager

[VincentVanlaer]

I propose a new tool that takes care of

• Installing multiple versions of MESA
• Installing the corresponding MESA SDK version required for that MESA version
• Installing shmesa (or take over some of its duties)
• Selecting the right version of MESA at runtime

For now, I will not focus on potential ways of implementing this, but rather how a user is expected to use this tool. Details and names of commands can of course be changed for the actual implementation. This is inspired by tools such as rustup and uv.

Installation

On the MESA installation instructions, the first step listed after the prerequisites would become "Run the following in your terminal, then follow the onscreen instructions."

curl --proto '=https' --tlsv1.2 -sSf https://installer.mesastar.org | sh

This would then do the following (paths are assumed for a normal linux install):

• Install the installer itself in ~/.local/share/mesastar/bin.
• Add ~/.local/share/mesastar/bin to the user's PATH (e.g. by adding export PATH=~/.local/share/mesastar/bin:$PATH to the right shell initialization script)

Ideally, all of these steps are customizable. The script should tell the user what it plans to do.

Example: rustup installer options

Welcome to Rust!

This will download and install the official compiler for the Rust
programming language, and its package manager, Cargo.

Rustup metadata and toolchains will be installed into the Rustup
home directory, located at:

  /home/vincentva/.rustup

This can be modified with the RUSTUP_HOME environment variable.

The Cargo home directory is located at:

  /home/vincentva/.cache/cargo

This can be modified with the CARGO_HOME environment variable.

The cargo, rustc, rustup and other commands will be added to
Cargo's bin directory, located at:

  /home/vincentva/.cache/cargo/bin

This path will then be added to your PATH environment variable by
modifying the profile files located at:

  /home/vincentva/.profile
  /home/vincentva/.config/zsh/.zshenv

You can uninstall at any time with rustup self uninstall and
these changes will be reverted.

Current installation options:


   default host triple: x86_64-unknown-linux-gnu
     default toolchain: stable (default)
               profile: default
  modify PATH variable: yes

1) Proceed with standard installation (default - just press enter)
2) Customize installation
3) Cancel installation

After the installer has installed itself, it can then install the latest version of MESA and install the corresponding SDK. These would be downloaded and extracted to

• ~/.local/share/mesastar/sdk/SDK_VERSION
• ~/.local/share/mesastar/mesa/MESA_VERSION

and ./install would be executed.

Starting to use MESA

Once the installer (and potentially a base version of MESA is installed), the user would have access to a single command called mesa. The installation/getting started instructions should direct the user to create their first workdir.

mesa workdir new NAME_OF_WORKDIR

This will copy the workdir template from the default (more on that later) MESA version to NAME_OF_WORKDIR. This could be a new implementation or just delegate to shmesa located in this default MESA version. At that point we are basically at the normal setup and the user may continue to use MESA as they please.

But wait, what about MESA_DIR and MESASDK_ROOT?

At this point, there have been no instructions for the user to set the MESA_DIR and MESASDK_ROOT variables. How does MESA now know where to find itself then? The main Makefile in the workdir would essentially contain (or be patched to support older MESA version):

MESA_DIR ?= $(shell mesa environment print-mesa-dir)
MESASDK_ROOT ?= $(shell mesa environment print-sdk-dir)

We should allow the user to override these variables (in case they don't want to use the installer or work without the SDK).

Managing multiple MESA versions

The main selling point for a tool such as this would be to manage multiple versions of MESA at the same time. It would allow you to do things such as

mesa install MESA_VERSION
mesa set-default MESA_VERSION

As an example, you may mesa list could output

25.12.1 (default)
24.03.1
15140

Commands such as mesa workdir new would take an optional --version argument that would allow the user to select a specific MESA version. If this argument is not present, the default version is used. When a workdir is created, a file .mesa-version would be copied as well, which would allow mesa environment to output the right MESA_DIR and MESASDK_ROOT. If you don't have the right MESA version installed, it could offer to install it.

Power user/developer

For power users or developers, this tool should be optional. If your environment requires a specific compiler, prevents you from using the SDK, ... it should still be possible to install and customize MESA as is currently possible.

Thoughts? I mostly wanted to just document these ideas and gather feedback. I am not planning to start working on this soon.

[Debraheem]

Would the sdk part work on mac? The mac os sdk is installed in the applications folder. Might be good to keep in mind virtually everything pre r15140 (12778 with the right patch) cannot be run on arm macs anyway, as there were no compilers for arm at that point in time.

[Debraheem]

I think this seems like a nice optional feature we could provide in the future.