cja
A CMake-compatible build system that generates Ninja build files.
Build a project with a CMakeLists.txt using:
cja
ninja
This is equivalent to the following with CMake:
cmake -Bbuild -GNinja -DCMAKE_BUILD_TYPE=Debug \
-DCMAKE_COLOR_DIAGNOSTICS=1 -DCMAKE_EXPORT_COMPILE_COMMANDS=1
ninja -Cbuild
Install
pip install cja
Or, if you're in a managed Python environment:
pipx install cja
Bash completion
Distribution packages install it automatically. Otherwise copy
completions/cja.bash to ~/.local/share/bash-completion/completions/cja.
Besides subcommands and options it completes the targets of cja build.
Comparison to CMake
- The
build.ninjafile is generated in your project root, not in the build directory. To allow multiple build configurations in parallel, the file name is<builddir>.ninja. - Paths are relative to the project root, while CMake uses absolute paths. This is faster, reduces output, and also reduces binary size as paths (e.g. for debug symbols) are shorter. When reading output from a Docker container, this lets you click paths and open the correct files in your local editor.
- Instead of a separate tool like CTest, cja generates a phony
testtarget that runs all tests as part of the Ninja build graph, so tests can start as soon as the first test binary is ready. Tests run one after another in Ninja's console pool;test-parallel(orcja test --parallel) runs them in parallel instead. Test fixtures (FIXTURES_SETUP,FIXTURES_REQUIRED,FIXTURES_CLEANUP) become dependencies between the test targets, so unlike CTest a cleanup test doesn't run when a test requiring its fixture fails. - Colors for compiler diagnostics are enabled by default.
_builddir_/compile_commands.jsonis always generated.- More colorful, simplified output. For example, when downloading dependencies, cja shows progress bars using
Rich, while CMake shows no output (or simple multi-line output when
-DFETCHCONTENT_QUIET=0is specified).
Limitations to keep cja simple:
- Only generates Ninja build files.
- Out-of-tree builds aren't allowed.
- Only supports Linux, macOS, and Windows.
- Only supports clang with a GNU-like command line on Windows.
Build Subcommand
cja supports a build subcommand, which runs ninja automatically afterward.
cja --release / cja build --release
cja --release is equivalent to:
cja -Bbuild-release -DCMAKE_BUILD_TYPE=Release
cja build --release additionally runs ninja:
cja -Bbuild-release -DCMAKE_BUILD_TYPE=Release
ninja -f build-release.ninja
-B and -D
cja build, cja run and cja test accept -B and -D like cja itself, e.g.
cja build -Bout -DFOO=1. -B takes precedence over build-release from --release. Passing -D
reconfigures an existing build directory; without it, the existing configuration is kept.
Run Subcommand
cja also generates a run phony target that executes the first executable (or the one set via
VS_STARTUP_PROJECT) in your CMakeLists.txt.
Format Subcommand
cja format formats CMake files, similar to cmake-format or
clang-format:
cja format CMakeLists.txt # print the formatted file
cja format -i CMakeLists.txt foo.cmake # format files in place
cja format --check CMakeLists.txt # exit with 1 if the file isn't formatted
cja format -i --lines 10:20 CMakeLists.txt # only format statements touching lines 10-20
Like clang-format's --lines, --lines START:END (1-based, inclusive, can be repeated) restricts formatting to the
statements that touch these lines or the blank lines before them. Everything else is left byte-for-byte unchanged.
Without file arguments it reads from stdin (use --assume-filename to tell it where the file lives).
These options are read from the nearest .clang-format:
IndentWidth,UseTabandTabWidthColumnLimit(0means no limit)MaxEmptyLinesToKeepLineEndingBasedOnStyle(for the defaults of the options above) andDisableFormat
If there's a .cmake-format.json, the nearest one overrides them. These options of its format section are supported:
line_width,tab_sizeanduse_tabcharsmax_subgroups_hwrap,max_pargs_hwrap,max_rows_cmdline,min_prefix_chars,max_prefix_charsandmax_lines_hwrapline_ending,command_caseanddisable
The parse section isn't needed: the keywords of custom commands are inferred from their arguments.
Everything else follows cmake-format's defaults, with a few differences:
- A command call that fits on one line is kept on one line, like clang-format does (cmake-format breaks calls with
more than two argument groups or six arguments). Setting
max_subgroups_hwrapormax_pargs_hwrapin.cmake-format.jsonswitches to cmake-format's behavior. - Comments are never reflowed.
- The names of user-defined commands keep their spelling (builtin commands are still lowercased) and UPPERCASE words in their arguments are treated as keywords.
- Line endings and a UTF-8 BOM are preserved.
Use # cmake-format: off / # cmake-format: on (or # clang-format off / on) to exclude a region.
LSP Subcommand
cja lsp is a Language Server Protocol server for CMake
files. It talks to the editor over stdin/stdout (--stdio is accepted and is the default), so an editor extension
only has to launch cja lsp --stdio.
When the editor opens a workspace folder, all CMakeLists.txt and *.cmake files in it are indexed (build
directories, hidden directories and _deps are skipped). The server provides:
- Semantic highlighting of commands (builtin, user-defined functions and macros), keywords, variables, function parameters, targets, strings, numbers, constants and comments
- Diagnostics for syntax errors and unbalanced blocks (
if()withoutendif()and so on) while typing - Go to definition and find references for functions and macros, variables, targets, and the files named by
include()andadd_subdirectory() - Hover with the definition (and the comment above it) of user-defined commands, variables and targets, and a link to the documentation of builtin commands
- Completion of command names, of the keywords of the current command, of target names and of variable names
after
${ - Document symbols (functions, macros, targets, options and the project), folding and formatting of the
whole document or of the selected lines (like
cja formatandcja format --lines)
Nothing is executed for these. Optionally, the project can also be configured with cja to report the errors and
warnings of a real configure run (e.g. unsupported arguments with --strict) as diagnostics. This runs CMake code
from the project (execute_process(), downloads with FetchContent, …) and writes the build directory, so it's off by
default. It runs on save with configureOnSave, or when the client sends the cja.configure command
(workspace/executeCommand). These options can be passed as initializationOptions or as cja settings in
workspace/didChangeConfiguration:
| Option | Default | Description |
|---|---|---|
configureOnSave |
false |
Configure the project when a file is saved |
buildDir |
"build" |
Build directory used for configuring |
strict |
true |
Configure with --strict |
configureArgs |
[] |
Additional arguments, e.g. ["-DFOO=ON"] |
Building the RPM
cja.spec builds an RPM for Fedora. To build one from the working tree with mock:
uv build --sdist -o dist
mock --buildsrpm --spec cja.spec --sources dist --resultdir rpm
mock --rebuild rpm/cja-*.src.rpm --resultdir rpm
Version in the spec must match the version in pyproject.toml. The test suite runs during the
build; tests that download dependencies are skipped.
Metadata
Release files for cja 0.10.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| cja-0.10.1.tar.gz | 347.8 kB | With provenance | Details for cja-0.10.1.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| cja-0.10.1-py3-none-any.whl | Python 3 | none | any | Details for cja-0.10.1-py3-none-any.whl |
Total release size: 557.5 kB
Release files / cja-0.10.1.tar.gz
| Download URL | cja-0.10.1.tar.gz |
|---|---|
| Size | 347.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
eacadd7a0a5da1c515eb8f88197e912f7ea3ba9ed8977a53fee6031de447c0a9
|
|
BLAKE2b-256 checksum How to use checksums |
cf33cf447774627cac14c24f50610019c382517d4a1db1e37bd468bf8da7814a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 28, 2026.
Transparency logRelease files / cja-0.10.1-py3-none-any.whl
| Download URL | cja-0.10.1-py3-none-any.whl |
|---|---|
| Size | 209.7 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
656cc354e75d87645f4ece49361928496870dd6404d0b1a3e133f2fff010ed25
|
|
BLAKE2b-256 checksum How to use checksums |
b8be0529c9cee8d9ae3944ff1e747070031a8ff9f8537c36feeb3e55f14c1620
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 28, 2026.
Transparency logSecurity for cja 0.10.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
Both files in this release have been uploaded with provenance metadata.
Attestation for cja-0.10.1.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 28, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.