Celer installs, builds, and caches C/C++ libraries — isolated by platform × project × build type. The same libraries can be built for Windows MSVC, Linux aarch64, and QNX without versions leaking across targets. Your CMake project stays unchanged. Celer generates a toolchain_file.cmake outside the tree and injects the toolchain, dependencies, and flags. Hand that file to a teammate or CI and the build environment goes with it.

🚀 30-second start

Download a binary from Releases, or git clone and go build.

# Example config repo — swap in your team's conf
celer init --url=https://github.com/celer-pkg/test-conf.git
Pick a platform and project (one platform.toml = toolchain + sysroot)
celer configure --platform=x86_64-linux-ubuntu-22.04-gcc-11.5.0
celer configure --project=project_test_01
Install a dependency, switch to aarch64 / Windows / QNX by changing --platform
celer install [email protected]

Then in your own project:

cmake -B build -DCMAKE_TOOLCHAIN_FILE=<toolchain_file.cmake from Celer>
cmake --build build

📖 Full quick start · Why Celer?

🧩 VS Code extension

Recommended: celer-vscode，then you can use celer graphically.

💡 Non-intrusive: the project does not change

!workflow

Dependencies, platforms, and compiler flags live in Celer's conf — not in your application repo.

• Keep your existing CMake layout; no recipe rewrite for the package manager
• Switch targets by swapping a platform.toml, not rewriting CLI flags and profiles
• The generated toolchain file travels on its own — CI, handoff, and bug reproduction use the same file

🎯 Who this is for

• You ship one product across Windows / Linux / embedded with MSVC, GCC, and Clang
• You need a reproducible build for teammates or CI, not "works on my machine"
• You distribute private binaries or run an internal artifact store
• Several projects share a machine and you are done with dependency versions colliding

🌟 What you get

| When you need… | What Celer does | | --- | --- | | Cross-compile | One platform.toml holds toolchain, sysroot, and env vars — ARM / x86 / QNX / Windows / Linux | | Isolation | Isolate versions, macros, and CMake vars by platform × project × build type | | Build systems | CMake, Makefiles, Meson, B2, QMake, Bazel, GYP | | Private artifacts | Hash-based artifact cache shared by the team and CI | | Git access | Git repos of third-party libraries and tools you already fetched are cached | | Reproducible CI | Export a workspace snapshot; the same config enters the pipeline | | Distributed builds | --export-dag splits it into one job per port, wired by dependency edges; the shared pkgcache carries the artifacts |

MSVC / Clang / GCC are ready on Windows and Linux; macOS is still in progress. Additional targets (including QNX) are defined as platform configs.

📚 Documentation

Get started in 5 minutes:

• Quick Start Guide · Init a Workspace
• Create a Platform / Project / Port
• Install a Library · Deploy

• Generate CMake Config Files
• Platform Config Deep Dive · Port Config Deep Dive · Project Config Deep Dive
• PkgCache: Shared Cache (fs / MinIO) · Artifact Cache · Repo Cache · Download Cache · Python Wheel Cache
• CCache Integration
• CUDA Auto-detection
• Expression Variables
• Dependency Conflict Detection
• Python Version Management
• Build Tools
• Distributed Build (Jenkins)
• Export Snapshots

• configure · install · remove · update · search · tree · clean · autoremove · reverse · integrate · strip · version

🤝 Contributing

Contributions are welcome in the core, ports, and extension:

• celer — core package manager
• ports — port definitions & build configs
• celer-vscode — VS Code extension

📄 License

MIT. See LICENSE. Third-party libraries in ports/ remain under their original licenses.