mirror of https://github.com/ankitects/anki.git synced 2026-09-10 07:29:19 -04:00

Files

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

Raw Permalink Blame History

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.

1.9 KiB Raw Permalink Blame History