How to install the xPack QEMU RISC-V
The xPack QEMU RISC-V can be installed automatically, using the xpm
command
(the recommended method), or manually, by downloading and unpacking one of the
platform specific archives.
Automated install
The easiest (and recommended) way to install QEMU RISC-V
is via xpm and the package available
as @xpack-dev-tools/qemu-riscv
from
the npmjs.com
registry.
xpm packages (xPacks) refresher
xpm packages, abbreviated as xPacks, are general-purpose,
language-neutral software packages.
They use the same format as npm packages,
which is a collection of files/folders
and a package.json
file with the package metadata.
xpm can install source and binary packages.
Binary packages include references to regular archives with the platform
specific binaries (such as .tar.gz
for Unix or .zip
for Windows).
These archives are unpacked and links/forwarders to
the executables are created in a .bin
folder.
For more details, please see the previous explanation in the Getting Started page.
Prerequisites
The only requirement for an automated install is a recent xpm, which is a portable Node.js command line application that complements npm with several extra features specific to C/C++ projects.
To install xpm, follow the instructions in the xpm install page.
If already installed, it is always a good idea to update it to the latest version with:
npm install --location=global xpm@latest
Although not mandated by xpm, it is also a good idea to upgrade npm to the latest version, and node to a reasonably recent version (currently npm requires a node >=18.17.0).
Local installs
One of the xPack design goals is to allow each project to choose the exact versions of the tools it requires.
Similarly to npm being able to install specific versions of the JavaScript tools into each project, xpm was also designed to be able to install specific versions of the required binary tools locally into each project.
Therefore, similarly to the way npm installs the JavaScript packages into
node_modules
, xpm installs the binary tools into
xpacks
. Here there will be separate folders with the installed
packages, for example
xpacks/@xpack-dev-tools/qemu-riscv
.
Each such folder includes the package.json
file with the
project metadata and a sub-folder .content
with the extracted
binary archive. The executables are usually in .content/bin
.
On some platforms, names starting with .
(dot) might be hidden for
normal browsing, and seeing them requires
separate options (like ls -A
) or, in file browsers, to enable
settings like Show Hidden Files.
The xpacks/.bin
folder
If multiple binary packages are installed, in order to allow
the executables to be accessed, one possible solution is to add
all <package>/.content/bin
folders to the PATH
.
To simplify things, npm employs a separate <project>/node_modules/.bin
folder
where it places links/forwarders
pointing to the actual executable files.
Similarly, xpm adds links/forwarders into
a separate <project>/xpacks/.bin
folder.
With this setup, the project needs to prepend only this .bin
folder
to the PATH
, and all the required tools are accessible
and preferred to possible system tools.
Global installs and the user global xPacks store
Given that some binary tools (such as toolchains) can be very large (hundreds of megabytes or more), it is impractical to keep multiple copies of these tools, one for each project.
Instead, xpm installs the binary packages only once into a user global store (a platform-dependent folder within the home folder), thereby conserving disk space when the same tools are used across multiple projects.
In order to allow the projects to access the binary tools installed in the
user global store, instead of unpacking the archives in xpacks
,
xpm adds symbolic links pointing to the user global xPacks store.
The outcome is functionally equivalent to installing the tools into each project, but without the wasted disk space.
It is possible to force a local install into a project
by passing --copy
to xpm install
.
if necessary, it is also possible to install packages only globally, without creating local links/forwarders (see below).
The user xPacks cache
To save download time, all archives are first stored in a cache, and all subsequent downloads are replaced with the cached content.
Therefore all published archives should be read-only and it is not allowed to replace them at a later time.
Initialise the project
Upon initial use, ensure that a package.json
file is present in the
project root folder.
This can be achieved by running xpm init
in the desired project folder
(substitute my-project
accordingly):
cd my-project
xpm init
Under the hood
The main purpose of xpm init
is to create a package.json
file, if not
already present.
In addition to name
& version
, the minimal package.json
must
include a property named xpacks
, even empty. This property is
mandatory to identify the package as an xpm package.