القائمة
Use when building D projects with xmake — binary/library targets with `.d` sources, DUB package integration via `add_requires("dub::...")`, and selecting DMD / LDC / GDC compilers.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | xmake-dlang |
| description | Use when building D projects with xmake — binary/library targets with `.d` sources, DUB package integration via `add_requires("dub::...")`, and selecting DMD / LDC / GDC compilers. |
D has three main compilers (DMD, LDC, GDC); xmake drives all of them through a unified target() API and supports DUB for package dependencies.
xmake create -l dlang -t console hello
cd hello
xmake run
add_rules("mode.debug", "mode.release")
target("hello")
set_kind("binary")
add_files("src/*.d")
target("app") set_kind("binary")
target("mylib") set_kind("static")
target("mydyn") set_kind("shared")
add_requires("dub::vibe-d ~>0.9.5")
add_requires("dub::libasync")
target("app")
set_kind("binary")
add_files("src/*.d")
add_packages("dub::vibe-d", "dub::libasync")
Known limitation: cascading transitive deps must be declared manually for now. Add every dep in the tree explicitly.
xmake f --toolchain=dlang # DMD (default)
xmake f --toolchain=ldc
xmake f --toolchain=gdc
Or pin paths:
xmake f --toolchain=ldc --sdk=/opt/ldc-1.30
LDC is usually the best choice for release builds (LLVM backend, best optimization). DMD is fastest to compile with.
target("app")
add_files("src/*.d")
add_dcflags("-O", "-release") -- passed to the D compiler
add_ldflags("-Wl,--as-needed")
add_dcflags = D compiler flags. Each compiler has its own flag dialect — prefer portable ones or gate with if is_toolchain("ldc") then ... end.
target("app")
set_kind("binary")
add_files("src/main.d", "src/extern.c") -- mix C and D in one target
add_includedirs("include")
D can call C directly via extern (C) declarations on the D side. No bridging needed.
add_dcflags("-mattr=+avx2") works on LDC, fails on DMD. Gate with is_toolchain.xmake-targets, xmake-build-optimizationxmake-cross-compilation (LDC supports many targets)xmake-packagesUse 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.