Toolchain installation scripts Check scripts

The public scripts are self-contained: fetch one and run it on any Debian/Ubuntu-based host, with no image and no checkout involved. Using the images is the Docker route instead.

Directory	Scope	What lives there
install/	Public - standalone	Toolchain installers - cmake.sh, gcc.sh, llvm.sh, binutils.sh, doxygen.sh. Reusable on any Debian/Ubuntu-based system, with no dependency on this repository. See install/README.md for the full option reference.
checks/	Public - standalone	cxx-standards.sh - which C++ standards a compiler accepts. cxx-stdlibs.sh - which C++ standard libraries are installed, with the SONAME and ABI version a binary will need to find. Point either at any machine, checkout or not. See checks/README.md.
checks/details/	Internal	The image validation gate, which runs inside a built image: it knows this repo's expected package origins and asks its installers what is present. See docs/IMAGES_VALIDATION.md.
details/	Internal	This repository's own tooling - the version-pin guard, the release-note renderer, the install-script parity check, the promotion-record schema and the image smoke test. Not reusable: they parse this repo's Dockerfile, renovate.json and releases/ records. See details/README.md.

The Dockerfile copies in and runs the install/ scripts, one per stage that needs one, and copies scripts/ whole into the throwaway validate stages so checks/ can run there.
Nothing under the top-level details/ ever enters an image: .dockerignore keeps it out of the build context entirely, and the smoke test reaches a built image by bind-mount instead.

checks/details/ is a different details/ - implementation details of checks/, in the C++ sense of a nested detail namespace. Being repo-specific is what the two share; unlike the top-level one, these must ship into the image they validate.

Using a public script on its own

Caution

For all scripts in this repo:

Optional value needs <name>=<value> semantic
There are no positional arguments.

Everything marked Public is a single file that needs nothing around it, so you can pull it straight from raw.githubusercontent.com and drop it into a project, a CI job or a plain shell - no image to pull, no repository to clone, no commitment to the rest of this toolchain:

base=https://raw.githubusercontent.com/GuillaumeDua/cpp-toolchain/main/scripts
 
# Install a toolchain on any Debian/Ubuntu-based host
wget "${base}/install/gcc.sh"
sudo bash gcc.sh --versions='>=13'
 
# Ask a compiler which C++ standards it accepts - useful to drive a CI matrix
wget "${base}/checks/cxx-standards.sh"
bash cxx-standards.sh --greatest --stable --format=std g++
# -> c++26
 
# Ask which ABI the installed libstdc++ exposes - the marker a 'GLIBCXX_... not found' names
wget "${base}/checks/cxx-stdlibs.sh"
bash cxx-stdlibs.sh --stdlib=libstdc++ --format=abi
# -> GLIBCXX_3.4.35

Every one of them describes itself with --help, so the fetched file is its own documentation.

Swap main for a release tag when you want the URL pinned, which is what you usually want in CI - main moves.

The Internal rows are not fetchable this way. They reach the rest of the tree by relative path and only work inside a checkout or an image.