القائمة
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