Use when hacking on Xmake itself — building the xmake binary from source, loading the local source tree so your changes take effect without reinstalling, and debugging either the Lua scripts under xmake/ or the native C core under core/src/xmake.
Use when configuring xmake via environment variables — XMAKEPROGRAMDIR/XMAKEPROGRAMFILE (local source debug), XMAKEGLOBALDIR/XMAKECONFIGDIR (config locations), XMAKECOLORTERM/XMAKEPROFILE, XMAKERCFILES (global defaults), XMAKEROOT, and how to list/inspect them with xmake show -l envs.
Use when xmake is misbehaving — hangs/stuck, mysterious errors, slow configure/build, regressions after upgrade — and you need to diagnose it. Covers -vD verbose traces, XMAKEPROFILE=stuck/trace/perf: profiling env var, git bisect via xmake l cli.bisect, and debugging the Lua + C core. Do NOT use for everyday build…
Use when a package from addrequires / xmake-repo fails to build or misbehaves, and you need to debug its source — editing the upstream files in place without patches, running the recipe against a local source tree with -d , stepping through oninstall, extracting the patch once fixed, and remote debugging via --remote.
Use when package downloads are slow, failing, or blocked — especially in China or behind corporate networks. Covers HTTP/SOCKS5 proxies (xmake g --proxy), host allow-lists, pac.lua routing, mirror() URL rewriting for GitHub acceleration, manual download directories, and recommended mirror setups for domestic network…
Use when distributing C/C++ libraries inside a company or team — packaging a library with xmake package, creating a private package repository (local directory or git), writing package recipes for source/binary distribution, and consuming them via addrepositories + addrequires. For shipping end-user installers…
Use when adding or modifying a package recipe in the xmake-repo repository (github.com/xmake-io/xmake-repo) and you need to test-build it locally. Wraps the xmake l scripts/test.lua workflow with --shallow, platform/arch/mode/kind/configs flags so package changes can be verified quickly before submitting a PR.
Use when installing, inspecting, or exporting C/C++ packages from the command line with xrepo — xmake's standalone package manager. Covers install/search/info/fetch/export/download, repository management, and package virtual environments (xrepo env).
Use when the user wants a virtual environment of C/C++ libraries and CLI tools managed by xrepo — dropping into a shell with python/luajit/cmake/etc. on PATH, pinning per-project tool versions via xmake.lua, or registering named global environments. Conceptually similar to conda/venv but for C/C++ and native CLI tools.
Use when producing distributable packages from an xmake project — zip/tar.gz/deb/rpm/nsis/wix/srpm/pacman/runself/zst etc. — via xpack(...) in xmake.lua and the xmake pack CLI. Covers package metadata, format selection, install layout, components, custom install commands, and CLI flags.
Use when configuring or debugging xmake's local build cache (built-in, replaces ccache) or the remote compile cache service (shared across machines via xmake service --ccache). Covers enabling/disabling, fallbacks to external ccache, remote cache server/client setup, and cache cleaning.
Use when a project builds slowly and you want to make it faster — parallel jobs, unity build, precompiled headers, build cache, LTO, link-time improvements, binary package cache, and profiling with XMAKEPROFILE=perf:. Covers idiomatic xmake speedups and the order to try them.
Use when setting up or using xmake's built-in distributed compilation (distcc-equivalent) to offload compile jobs to a cluster of servers. Covers xmake service --distcc, server/client config, token auth, job control, combining with local/remote cache, and distributed cross-compilation (Android/iOS).
Use when compiling and running a project on a remote machine transparently — edit locally, build/run/debug on a Linux/macOS/Windows server. Covers xmake service (remote build server), multi-host client config, token/password auth, --sync/--pull, and the difference from distributed compilation.
Use when probing the host/toolchain for capabilities inside xmake.lua — hascfuncs / hascxxtypes / hasfeatures, checkcsnippets, checkcflags / checkcxxflags, option auto-probes (addcxxincludes / addcfuncs), and lib.detect.find. Covers how to gate target config on whether a symbol/header/flag is actually usable on the…
Use when defining user-configurable build options (option(...)), reading them from targets, or exposing them on the xmake f command line. Covers showmenu, default, values, and option-driven config.h generation.
Use when adding third-party C/C++ dependencies to an Xmake project — via addrequires / addpackages, configuring package options, pinning versions, or using xrepo from the command line.
Use when setting build policies via setpolicy("name", value) — named feature toggles that control sanitizers, LTO, warnings, C++ modules, ccache, module-reuse, rpath, preprocessor behavior, package download strict mode, and many others. Covers the common policies grouped by purpose, how to scope them (project vs…
Use when applying built-in rules (e.g. mode.debug, mode.release, qt.widgetapp, c++.unitybuild) or writing a custom rule to handle a new file extension or codegen step.
Use when configuring targets in xmake.lua — setting kind (binary/static/shared), adding files/includes/links, defining dependencies between targets, and applying per-target compile/link flags.
Use when writing an Xmake addon — the addon.lua manifest, the payload layout (plugins/rules/toolchains/modules/includes/templates), @self references, shipping package definitions with an addon, addglobalmodules, testing it locally, and publishing it to xmake-repo as an addon kind package.
Use when installing or using an Xmake addon — xmake addon --install/--list/--remove/--upgrade/--search, declaring addaddons(...) in a project, and referencing addon payloads with @addon/ / , @addon. . or @self. For writing and publishing one, see xmake-addon-development.