Guide

SC::Package

Install and inspect pinned development tools, cross toolchains, sysroots, and runners with SC::Package.

Package lifecycle

From recipe to build capability

Recipe Describe acquisition and validation
Install or import Acquire the development tool
Validate Check the expected layout
Receipt and exports Expose named tools and sysroots

SC::Package acquires development tools, compilers, sysroots, and runners used by repository workflows. It is not an application dependency manager: packages live under _Build and support building, formatting, documentation, and cross-target validation.

Think in recipes, receipts, and exports

Every package has three useful layers:

  1. A recipe describes how the package is downloaded, imported, prepared, and validated.
  2. A receipt records what was installed and which recipe version produced it.
  3. Exports name the tools, sysroots, runners, include directories, or libraries that another tool may consume.

After installation or import, validation produces a receipt and a set of named exports. This allows SC::Build to ask for a capability such as an LLVM compiler or QEMU runner without reconstructing an installation path from directory naming conventions.

Inspect before changing package state

Start with read-only actions:

./SC.sh package list
./SC.sh package info llvm
./SC.sh package status llvm
./SC.sh package exports llvm

status reports whether a receipt is present and structurally valid without failing merely because a package is missing. verify performs the stricter validation used when a workflow depends on that package:

./SC.sh package verify llvm

When validation fails, doctor explains the observed state and suggests a next action:

./SC.sh package doctor llvm

Install, import, or repair

Install a package managed by the built-in catalog:

./SC.sh package install llvm

Some large or host-specific tools can be registered from an existing directory instead of downloaded:

./SC.sh package install qemu --import-directory /opt/qemu-user

repair is for a recognized existing layout whose current receipt or launcher metadata can be reconstructed. It is not a generic substitute for a failed install:

./SC.sh package repair llvm-mingw

Record the resolved environment

lock writes _Build/SC-package.lock, a local summary of installed receipts and exports:

./SC.sh package lock

The lock file makes a development environment auditable. It does not turn imported packages into content-addressed artifacts and should not be mistaken for an application dependency lock.

Use ./SC.sh package help for the current package catalog and action syntax. The registry and recipe API live in Tools/SC-package when an external tool needs to compose its own package entries.