Xmake: A cross-platform build utility based on Lua

This is an interesting system that I studied closely a few years ago, along with a few others based on Lua or Python.

What surprises me enormously about all these systems is the fact that, in builds that can become enormously large and complex systems in themselves, we voluntarily forego most of the advantages we have learned over sixty years of software engineering. I am thinking, for example, of strong typing and type checking by the compiler, which then also enables better support from IDEs and analysis or visualization tools.

It's kind of like other scripting languages. For small applications, it all looks practical and efficient, but woe betide it if it becomes as big as Qt or other systems with several hundred thousand lines of code.

I think a syntax example on the homepage would be a good idea. Also comparison charts for things like cmake, ninja, meson, and bazel. If you have a dependency finding strategy, highlight the pros and cons of that. Basically the only reason states for why I should use this is lua, and that’s not inherently compelling to me for build tooling.

A teammate evaluated this and the experience was night and day compared to cmake + vcpkg. However, there wasn’t a lot of motivation to cutover our existing large project over because of the unknown unknowns. I think projects like these looking to dethrone the status quo definitely need some case studies or examples of larger projects using it to increase confidence because I’d much rather use xmake over cmake if it can get the job done

  target("foo", function ()
      set_kind("binary")
      add_files("src/*.cpp")
      add_defines("FOO")
  end)

    target("foo", {
      kind = "binary",
      files = { "src/*.cpp" },
      includedirs = { "src" },
      defines = { "FOO", "BAR=BAZ" },
    })

    target {
      name = "foo",
      kind = "binary",
      files = { "src/*.cpp" },
      includedirs = { "src" },
      defines = { "FOO", "BAR=BAZ" },
    }

    target("foo", {
      kind = "binary",
      files = { "src/*.cpp" },
      includedirs = { "src" },
      defines = { "FOO", "BAR=BAZ" },
    })

Just yesterday someone was telling me xmake does a lot of what bazel can do (hermetic, deterministic, optionally remote builds) while being easier to use.

I took a look at the docs later and couldn’t find a direct comparison. But there does seem to be a remote build system. And there were a few mentions of sandboxing.

Can anyone provide a head to head comparison?

Does xmake strictly enforce declared dependencies? Do actions run in their own sandboxes?

Can you define a target whose dependency tree is multi language, multi toolchain, multi target platform and which is built across multiple remote execution servers?

Can anyone explain xmake in terms of Build Systems a la Carte?

I apologise for this:

What's wrong with premake which is also Lua based?

when I meant:

What advantage does this have over premake which is also Lua based?

So, digging through the website git repo a bit, some basic facts:

* The project started almost 11 years ago, in 2015.

* It can be both a build-system generator like CMake, or a 'builder' like Make or ninja.

* Code is almost exclusively by one person, waruqi: https://github.com/waruqi , with several other people making a few contribution.

* Prima facie, the API seems to be less flexible/rich than CMake's, but I'm not sure.

* It supports quite a few languages, despite saying "C/C++" on the website.

* It has a built-in REPL.

As @MobiusHorizons points out, a comparison with other build system generators would be appropriate, mostly CMake, but I did not find it.

At my work we use MSBuild and vcpkg. What would a transition from that to XMake be like?

    set_languages("c++23")

    add_rules("mode.debug", "mode.release")

    target("mytest")
        set_kind("static")
        add_files("src/*.cpp")
        add_files("src/*.cppm", {public = true})
        set_policy("build.c++.modules", true)

My work uses this and it's slooooooow. Would not recommend.

I am deeply distressed that this doesn't require Xlib.

[dead]