Xmake: a Lua build tool that also fetches your C/C++ dependencies

The problem Xmake targets: build logic and dependency logic live in different tools

A typical C or C++ project today is assembled from parts. Make or Ninja executes the build. CMake or Meson generates the build files. Vcpkg or Conan resolves third-party libraries. Each of those has its own configuration language and its own upgrade cycle, and the seams between them are where projects break. Xmake's pitch is that one file, xmake.lua, describes the build and the dependencies together. The README states the project's own summary of this: Xmake is a cross-platform build utility based on the Lua scripting language, very lightweight, with no dependencies outside the standard library. The intended audience is C and C++ developers, but the supported language list goes well beyond that, including Objective-C, Swift, Go, Rust, Dlang, Fortran, Cuda, Zig, Vala, Pascal, Nim, Verilog, assembly dialects and more. If your repository mixes C++ with CUDA kernels, or a Rust component next to a C library, that breadth is the reason to look at it. If you write only C++ and only ever target one platform, the breadth buys you nothing and the Lua dependency costs you something.

How Xmake works: a Lua description, a backend, and a package repository

The project describes itself with an equation: Xmake = Build backend + Project Generator + Package Manager + [Remote|Distributed] Build + Cache. The README also offers a looser approximation, Xmake is roughly Make/Ninja plus CMake/Meson plus Vcpkg/Conan plus distcc plus ccache/sccache. Read that as an architectural claim rather than a benchmark. The build description is a Lua script that is executed to produce a target graph. A target declares its kind, its source files and its dependencies. From that graph, Xmake can either drive compilation directly, in the way Make or Ninja would, or emit project files for other systems, which the README lists as Visual Studio, Makefiles, CMake and compile_commands.json. Dependencies are declared in the same file, and Xmake fetches and builds them from package repositories, with the official repository being xmake-io/xmake-repo. The README notes that Xmake can fetch and install dependencies automatically. Two consequences follow from this design that are worth stating plainly. First, the build script is a program, so anything you can express in Lua you can express in a build, which is powerful and also means build files can become as hard to read as any other code. Second, the package manager is only as good as the recipes in xmake-repo; a library that has no recipe there is your problem to solve, not Xmake's.

Installing Xmake and building a first target

The README gives three one-line installers. On Linux and macOS, the cURL form pipes a script into bash:

curl -fsSL https://xmake.io/shget.text | bash

On Windows, the PowerShell equivalent downloads and executes a script:

irm https://xmake.io/psget.text | iex

Both are remote-script installs, so read the script first if your environment forbids piping downloads into a shell. The README points to the Installation Guide for other routes, including building from source and package managers. Once installed, a minimal project is a directory containing xmake.lua. The README's example creates a binary target and globs the C sources:

target("console")
    set_kind("binary")
    add_files("src/*.c")

With that file in the project root and sources under src/, running the bare command builds it:

xmake

To execute the target, name it:

xmake run console

Add -d to run it under the debugger, and use xmake test for tests. Platform and architecture are selected at configure time, for example:

xmake f -p linux -a x86_64 -m debug
xmake

If you would rather not memorise flags, xmake f --menu opens a terminal configuration menu. Dependencies go in the same file. The README's example requires tbox at 1.6, zlib at any version, and libpng at 1.6:

add_requires("tbox 1.6.*", "zlib", "libpng ~1.6")

After adding that line, the next build resolves and installs those packages. To see which toolchains Xmake can find on your machine, run xmake show -l toolchains, which prints a list including xcode, msvc, clang-cl, clang, gcc-family entries and others.

Where Xmake gets in the way

The strongest argument against Xmake is not technical, it is social. CMake is the default build system for a large part of the C++ ecosystem, and many libraries ship CMake config files that downstream projects consume. Xmake can generate CMake project files, but that is the opposite direction: it makes Xmake the source of truth and CMake the output, which does not help a consumer who expects to call find_package on your project. If your library is consumed by other projects, adopting Xmake means either maintaining two build descriptions or asking your consumers to install Xmake. The second constraint is the package repository. The built-in package manager resolves from xmake-repo recipes, and the README does not claim coverage of every library. A dependency that is not in the repository, or is present at an older version than you need, has to be handled by writing your own package description. That is a real maintenance cost, and it is invisible until the day you need a specific commit of a specific library. Third, Lua itself is a dependency on your team's skills. A build engineer who knows CMake may not know Lua, and the flexibility of a general-purpose scripting language in a build file is a double-edged property: it permits logic that is hard for the next person to follow. The README does not document rollback or downgrade procedures for the install scripts, so if an upgrade goes wrong you are on your own.

Xmake compared with CMake and Meson

The comparison people search for is Xmake versus CMake, and the difference is where dependency resolution lives. CMake describes targets and leaves fetching to an external tool such as Vcpkg or Conan, or to its own FetchContent module for source-level pulls. Xmake puts add_requires in the same file as the target definition and treats the package manager as part of the build utility, with xmake-repo as the recipe source. That is a genuine reduction in moving parts for a project that starts fresh. It is also a commitment: your dependency graph now depends on a repository maintained alongside the build tool. Meson takes a third position. It is Python-based rather than Lua-based, it is designed around Ninja as its backend, and it does not ship an integrated package manager of the same kind, relying instead on wraps and external package managers. Between the two, the practical question is which scripting language your team will maintain over years, not which produces faster binaries; the README makes performance claims about parallel compilation but gives no numbers, and no independent figures are available here. Xmake's distinguishing feature relative to both is the breadth of supported languages and target types in one tool, from WDK drivers and Linux kernel modules to CUDA, Qt, Protobuf and SWIG modules.

Licence, releases and what an upgrade costs

Xmake is licensed under Apache-2.0, and the repository carries both LICENSE.md and NOTICE.md at the top level, which is the standard Apache-2.0 arrangement. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices, but this is a description of the files present, not legal advice; if you redistribute Xmake or a derivative, have your own counsel read the licence text. The project is not archived, and the most recent push to the dev branch was on 2026-08-27, the same date as the v3.1.1 release. Before that, v3.1.0 landed on 2026-08-08 and v3.0.9 on 2026-05-19, so the release cadence visible in the repository is roughly monthly to quarterly. The default branch is dev, not a stable branch, which means the repository's tip is where development happens; if you vendor Xmake or build it from source, pin to a release tag rather than tracking dev. Upgrading the tool itself is the cheap part, since the installers are single commands. The expensive part is xmake.lua compatibility across major versions and the state of your dependency recipes in xmake-repo. The README does not describe a migration guide between major versions, so read CHANGELOG.md before moving a large project across a major release boundary.

Editorial conclusion

Adopt Xmake if your project is C, C++ or a supported mixed-language codebase, you want dependency resolution and project generation from one xmake.lua, and your team is willing to write build logic in Lua. Do not adopt it if your build depends on an existing CMake toolchain that downstream consumers already consume, or if you need to stay inside a single language's native tooling. Before committing, verify three things on your own machine: that the install script places xmake on your PATH, that your target toolchain appears in the output of xmake show -l toolchains, and that the dependency versions you need resolve from the xmake-repo package repository.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes