メニュー
Use when building Nim projects with xmake — binary/library targets with `.nim` sources, choosing the C backend (the default) vs C++, and mixing Nim 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-nim |
| description | Use when building Nim projects with xmake — binary/library targets with `.nim` sources, choosing the C backend (the default) vs C++, and mixing Nim with C. |
Nim compiles to C (or C++ / JavaScript) via nim c / nim cpp; xmake wraps this into a regular target model.
xmake create -l nim -t console hello
cd hello
xmake run
add_rules("mode.debug", "mode.release")
target("hello")
set_kind("binary")
add_files("src/*.nim")
target("app") set_kind("binary")
target("mylib") set_kind("static")
target("mydyn") set_kind("shared")
target("app")
add_files("src/main.nim")
set_values("nim.backend", "c") -- default
-- or:
set_values("nim.backend", "cpp")
set_values("nim.backend", "objc")
set_values("nim.backend", "js")
Most projects use c (native). cpp is required if you import C++ libraries via {.importcpp.}. js is for web targets.
target("app")
add_files("src/*.nim")
add_ncflags("-d:release", "--opt:speed") -- Nim compiler flags
add_cxflags("-O3") -- passes to underlying C compiler
add_ncflags = Nim compiler flags. add_cxflags flows through to the C backend.
xmake f --toolchain=nim
xmake f --toolchain=nim --sdk=/opt/nim-2.0
Nim code can call C with {.importc.}; xmake can also compile C files alongside:
target("app")
set_kind("binary")
add_files("src/main.nim", "src/helper.c")
add_includedirs("include")
{.importcpp.}, the target must use nim.backend = "cpp". Otherwise link errors.nimble vs xmake. Nim's native package manager is nimble. Xmake doesn't integrate with it — declare Nim deps via nimble manually, and let xmake handle the build.-d:release passed as nim flag. It's a Nim define, not a C flag — must go in add_ncflags, not add_defines.xmake-targetsxmake-targets