-
Notifications
You must be signed in to change notification settings - Fork 0
Target reference
Every target at a glance, and what a machine needs to run them.
make without a target prints the annotated, colorized help, including the detected app, version and certificate status. Colors turn off automatically when stdout is not a terminal and honor NO_COLOR. make help-<target> (for example make help-rsync) prints extended help for a single target — options and worked examples where they help.
| Area | Targets |
|---|---|
| Release versioning |
version, changelog, tag
|
| Build |
build, dist, composer ARGS=..., npm ARGS=..., reuse
|
| Local deploy |
rsync TARGET=..., cp TARGET=...
|
| App Store (module) |
csr, register, publish, sign, release, list-releases, list-releases-full, list-for-author, delete-release, ratings
|
| CI workflows (module) |
workflows-list, workflows-install W=..., workflows-update
|
| Utility |
clean, dist-clean, self-update, dev-init, dev-clean, help, help-<target>
|
Targets marked [m] in the help are maintainer-only: they need repository write access and/or the App Store signing key. Everything else works for anyone who clones the app. The areas marked (module) come from the developer modules (make dev-init, see Workflows and App Store); without the modules those targets simply do not exist — which keeps the help of a plain checkout down to build, deploy and utility.
GNU make, git, curl, openssl, rsync, python3. Optional but recommended: xmllint (libxml2) for reading info.xml — ncmake falls back to grep when it is missing, so a bare CI runner works too. Optional: podman or docker for containerized builds (strongly recommended; without them use RUNTIME=bare and provide composer and npm yourself).
© 2026 [ernolf] Raphael Gradenwitz · MIT-licensed · Report an issue
For app developers
- Getting started
- How ncmake understands your app
- Building and packaging
- Releasing
- Per-app tuning
- Target reference
CI workflows
App Store
For app users
Background