Files
anki/docs/build.md
Luc Mcgrady 7cf1d29896 docs: Replace docs/ with symlinks (#5031)
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.

Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->

## Linked issue (required)

<!-- Fixes #123 / Closes #123 / Refs #123 -->
closes #5001

This PR replaces the contents of `docs/` with symlinks to
`docs-site/developers/`

A caveat of this is that the metadata appears at the top of the file
instead of the title.
<img width="885" height="275" alt="image"
src="https://github.com/user-attachments/assets/430f9a71-e5a5-4412-983a-e4cfd7dc4714"
/>

We could either:
- Use ninja to copy the files from docs-site/developers and convert it
from .mdx to .md (Might be a problem with the symlink approach if mdx is
added to the contributor file later)
- Leave placeholder "For contribution instructions see: (link to
mintlify site)"s in the folder, which would have to wait until the
domain of the site is set. (Probably the best solution).

---------

Co-authored-by: Abdo <abdo@abdnh.net>
2026-08-04 22:01:31 +03:00

1.9 KiB

The build system

Basic use

Basic use is described in development.md.

Architecture

The build/ folder is made up of 4 packages:

  • build/configure defines the actions and inputs/outputs of the build graph - this is where you add new build steps or modify existing ones. The defined actions are converted at build time to a build.ninja file that Ninja executes.
  • build/ninja_gen is a library for writing a build.ninja file, and includes various rules like "build a Rust crate" or "run a command".
  • build/archives is a helper to download/checksum/extract a dependency as part of the build process.
  • build/runner serves a number of purposes:
    • it's the entrypoint to the build process, taking care of generating the build file and then invoking Ninja
    • it wraps executable invocations in the build file, swallowing their output if they exit successfully
    • it provides a few helpers for multi-step processes that can't be easily described in a cross-platform manner thanks to differences on Windows.

Tracing build problems

If you run into trouble with the build process:

  • You can see the executed commands with e.g. ./ninja pylib -v
  • You can see the output of successful commands by defining N2_OUTPUT_SUCCESS=1
  • You can see what's triggering a rebuild of a target with e.g. ./ninja qt/anki -d explain.
  • You can browse the build graph via e.g. ./ninja -- -t browse wheels
  • You can profile build performance with https://discourse.cmake.org/t/profiling-build-performance/2443/3.

Packaging considerations

See this page.