BYOS: build your own stack
The "pro" in externpro is a triple play: project, provider, and provisioner. A dependency provider and build platform that provisions the complete build ecosystem—toolchain environments, reusable CI pipelines, and dependency packaging—so your project becomes a consumable downstream package. Reproducible builds. Reusable dependencies. Consistent CI. Fewer "works on my machine" surprises.
externpro standardizes toolchains, dependencies, and CI workflows across developers, machines, and repositories—so teams ship faster with less drift and duplication.
-
externpro (core) 🧰 CMake build platform + dependency provider model + reusable workflows (
xpsync,xpbuild,xptag,xprelease). -
buildpro (Linux toolchain images) 🐳 Linux Docker build images used by externpro-enabled repos to keep compilers/tools/system deps consistent.
-
tutorial (adoption walkthrough) 🎓 Vendor externpro as a
.devcontainersubmodule, runxpSync, followxpTag → xpBuild → xpRelease, and consume externpro-produced deps viafind_package().
- Add externpro as a submodule to your project — the tutorial walks through the exact steps
- Run the bootstrap script to set up the xpro branch, copy workflow templates, and configure externpro
- Verify the setup works locally with
cmake --list-presetsandcmake --preset=<platform> - Run the
xpSyncworkflow to sync externpro and open a PR that standardizes presets, workflows, and repo wiring - Use other org repos as reference implementations (see the externpro projects table: https://github.com/externpro/externpro/blob/main/cmake/README.md)
- Start building and delivering your projects on multiple OSes, architectures, and compilers - creating packages that can be consumed by other projects quickly and consistently!
- Read the core overview in externpro
- Review the foundational patterns in buildpro
- externpro wiki - Announcements, notes, and Q&A
- externpro README - Core overview and getting started information
- GitHub Actions docs index - GitHub Actions integration, caller workflows, reusable workflows, release flow, build customization, supply chain, secrets and tokens, and architecture overview
- CMake dependency/projects table - Community-maintained catalog of externpro organization projects with licenses, descriptions, versions, sources, and diffs
- CMake toolkit docs index - CMake toolkit documentation for consuming packages, producing packages, repo adoption, and advanced topics
externpro uses decentralized package catalogs. The community-maintained catalog is in pros.cmake. Organizations can create their own catalog files (e.g., requirements.cmake, package.cmake, or any name they choose) to:
- Override packages specified by externpro's community-maintained catalog
- Include internal/private packages from their own repositories
- Control exactly which package versions their projects use
- Pin specific versions to avoid unexpected changes when externpro's catalog is updated via the xpsync workflow
The last catalog file included determines where packages come from and which version is used. Each package definition specifies the repository, tag (version), and a manifest hash that verifies the integrity of the downloaded release. For local development, you can use DIST_DIR or XPRO_PATH to point to a local build's dist directory or local xpro package path to test a development version before publishing a release.
| Capability | What it means |
|---|---|
| 🏗️ Build platform | A consistent build + toolchain baseline across Linux/macOS/Windows, x86_64/arm64, and multiple compiler toolchains (Linux buildpro containers; macOS/Windows GitHub-hosted runners) |
| 📦 Dependency provider | Dependencies are provided to your build as ready-to-use packages/targets, so consuming projects can just find_package() and link (rather than each repo reinventing fetch/build/patch) |
| 🔁 Reusable CI | Standardized sync/build/test/tag/release pipelines with supply chain outputs (SBOM/attestation) |
| 🔍 Supply chain visibility | Auto-generated dependency graphs and license information for compliance and software supply chain understanding |
Most repositories in the organization act as reference implementations—examples of integrating externpro and using the workflow as intended. See the externpro projects table: https://github.com/externpro/externpro/blob/main/cmake/README.md