Roadmap

cxpm is being redesigned from a build tool that sits beside CMake into the tool that replaces it: a package manager that fetches a project’s dependencies, builds against a sysroot made of exactly those dependencies, and hands the result to the package manager of the system it is installed on.

The plan was six milestones, in dependency order. Each one is tracked issue by issue on the project board, planning.pb, at the root of the repository; the issue numbers below are the board’s. The itemized findings that several of these issues close — every A# reference on this page — are in planning.pb (board #46, “SRS: Architecture & Flaws”), with file and line citations.

Status on 2026-10-04

Milestones 0.3, 0.4 and 0.5 are complete. The sections below were written as the plan and are kept as such; what is still open:

0.2 — Foundation: cx libraries and modular CMake

cxpm stops carrying its own containers, serialization, command-line, process and logging code and is built on the cx-core and cx-console libraries, vendored as submodules under third-party/ the same way softforge-payments-server does. CMake stays for now, reshaped into one independent project per target, which is the shape cxpm itself will have.

Done when cxpm builds from a fresh clone with submodules, the hand-rolled CXPM::Core and CXPM::Modules code is gone, and CI runs the tests on every push.

0.3 — Manifest model: one target, declared dependencies

package.cpp and package.json describe one target per project, and a target can only see what it declares: every include path and library comes from a declared dependency. What CMake solves with several targets inside one project becomes several projects related by dependencies. Toolchains declare the sysroot they compile against, the staging directory they install into and the package manager of the system that sysroot belongs to.

Done when the examples are rewritten in the new model and each one builds from its declared dependencies alone.

0.4 — Lifecycle: fetch, configure, build, pack, install

The five commands that are enough to distribute an application: fetch the dependencies, configure against a toolchain, build, pack into the staging directory, install through a package manager interface. Everything a command produces lives under the project’s .cxpm/ directory.

Done when an example with one fetched dependency goes through all five stages from a clean checkout.

0.5 — Sysroot isolation and native packaging

Builds run against a sysroot assembled from the project’s complete declared dependencies, never against whatever the host has installed. pack produces the package format of the target sysroot’s package manager, and install is a wrapper over that package manager.

Done when the same project produces a pacman package on an Arch sysroot and an rpm on an Amazon Linux sysroot, and each installs and uninstalls cleanly with the native tool.

0.6 — Self-hosting: CMake removed

cxpm builds, tests, packs and installs itself, and softforge-payments-server does the same. Every CMakeLists.txt is deleted.

A CMake build has since been brought back for working on cxpm locally (see quickstart ). It is not needed: the bootstrap script and cxpm itself still build everything with no CMake on the machine.

Done when a fresh clone goes from the bootstrap script to an installed cxpm package with no CMake on the machine.

0.7 — Package index: cx::pm::index::server

An npm-like index that maps package names and versions to their repositories. It holds no code: each entry points at the package’s repository. The index is served by cxpm itself and published at 01.dev.soft-forge.dev/cxpm/index, with the Soft Forge payments platform as the login.

Done when cxpm fetch resolves a dependency by name and version through the index and cxpm publish registers a new version.

Where the previous roadmap went

The page this one replaces listed 19 items written against the old --build/--install flags. None of them was dropped: the ones already done stay recorded in planning.pb (board #46, “SRS: Architecture & Flaws”), and every one still open was carried into an issue above, labelled tech-debt on the board and tagged with its A# number so it can be traced back to the finding that motivated it.