mirror of
https://github.com/ankitects/anki.git
synced 2026-07-29 02:39:43 -04:00
e9ac48cac2
<!-- 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) closes #5018 <!-- Fixes #123 / Closes #123 / Refs #123 --> ## Summary / motivation (required) This prevents large diffs with prettier being used with the mintlify editor A caveat of this is that the docs generated by cog now have to be prettier compatible. Also for some reason prettier has problems with the {/* */} multi-line comment format so we have to use <!-- --> instead. Sadly I don't have a good way to check that the Prettier config does not differ between this PR and the editor. --------- Co-authored-by: Abdo <abdo@abdnh.net>
43 lines
1.6 KiB
Plaintext
43 lines
1.6 KiB
Plaintext
---
|
|
title: "The build system"
|
|
---
|
|
|
|
## Basic use
|
|
|
|
Basic use is described in [development.md](./development).
|
|
|
|
## 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](./linux).
|