菜单
Use when building Zig projects with xmake — binary/library targets with `.zig` sources, cross-compilation (one of Zig's strengths), and mixing Zig with C.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when switching xmake's output theme (colors, progress style, emoji) or fixing garbled/unreadable terminal output — `xmake g --theme=...`. Built-in themes: default, ninja, emoji, dark, light, plain, powershell.
Use when the user is starting a new Xmake project, installing Xmake, or needs the minimal xmake.lua structure. Covers installation, `xmake create`, the project layout, and the smallest valid xmake.lua.
Use when writing or reviewing an `xmake.lua` (project, package recipe, or toolchain) and you want to follow idiomatic xmake style — description vs script domain separation, naming, indentation, `set_` vs `add_`, option/config organization, and common conventions used across xmake-repo and the xmake project itself. Apply this alongside `xmake-targets`/`xmake-packages`/etc. as a stylistic overlay.
Use when creating a new xmake project from a built-in or third-party template (`xmake create -t <template>`), listing available templates, or authoring and distributing custom templates (built-in, user-global, or via xmake-repo). Covers template layout, `${TARGET_NAME}` / `${FAQ}` substitution, and language selection.
Use when invoking Xmake from the command line — configuring, building, running, cleaning, installing, packing, or inspecting a project. Covers the common flags for `xmake f`, `xmake`, `xmake run`, `xmake install`, `xmake pack`, and friends.
Use when exporting an xmake project to another build system or IDE — `compile_commands.json` for clangd/LSP, `CMakeLists.txt`, `build.ninja`, Visual Studio solution (`vsxmake`), or an Xcode project. Covers `xmake project -k <kind>` and how each generator is typically used.
| name | xmake-zig |
| description | Use when building Zig projects with xmake — binary/library targets with `.zig` sources, cross-compilation (one of Zig's strengths), and mixing Zig with C. |
Xmake drives zig build-exe / zig build-lib under the hood. Zig is particularly nice because its native cross-compile story plays well with xmake's toolchain selection.
xmake create -l zig -t console hello
cd hello
xmake run
add_rules("mode.debug", "mode.release")
target("hello")
set_kind("binary")
add_files("src/*.zig")
target("app") set_kind("binary")
target("mylib") set_kind("static")
target("mydyn") set_kind("shared")
xmake f --toolchain=zig
xmake f --toolchain=zig --sdk=/opt/zig-0.12
Zig is auto-detected when zig is on PATH. Pin with --sdk for a specific install.
Zig has built-in cross-compile for every target it supports — no extra SDK needed:
xmake f -p windows -a x86_64 --toolchain=zig
xmake f -p linux -a arm64 --toolchain=zig
xmake f -p macosx -a arm64 --toolchain=zig
xmake
Xmake passes -target <triple> to zig build-exe. Far easier than GCC/Clang cross-SDKs.
Zig ships its own C compiler (zig cc) that can build C files. You can mix them in one target:
target("app")
set_kind("binary")
add_files("src/main.zig", "src/helper.c")
add_includedirs("include")
Zig imports C via @cImport. No bridging needed.
Bonus trick: point xmake's C toolchain at zig cc for free cross-compile of C projects:
xmake f --toolchain=zig
xmake f --cc="zig cc" --cxx="zig c++"
This is especially useful for MinGW-free Windows builds from Linux.
build-exe / build-lib flags change between versions. Pin --sdk to a known version in CI..zig and .cpp in one target. .zig + .c is fine; C++ is more brittle — use a separate target with add_deps.-target <triple> gives you a cross-compile, but you still need the right dynamic linker at runtime on the target — Zig can produce static binaries if you prefer (-fno-pie etc.).-p, -a, --sdk) → xmake-cross-compilationxmake-targets