XMake supports both.
https://xmake.io/guide/extensions/builtin-plugins.html#gener...
C++ Modules examples:
https://xmake.io/examples/cpp/cxx-modules.html
https://github.com/xmake-io/xmake/tree/dev/tests/projects/c%...
It took just a couple of minutes to have a working example that fully supported C++ modules and `import std`:
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)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?
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?
A better wording would be "what advantage does this have over premake which is also Lua based".
Anyways, not going to die on that hill and I'll keep using it because it's simple and works well for my needs. One thing I do like is that I am not having to constantly keep a skeleton CMake project around to copy paste and setup.
It supports this syntax.
https://xmake.io/guide/project-configuration/syntax-descript...
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" },
})
which suits Lua better. Unfortunately you cannot do target {
name = "foo",
kind = "binary",
files = { "src/*.cpp" },
includedirs = { "src" },
defines = { "FOO", "BAR=BAZ" },
}
which would be the lua-est lua of all. target("foo", {
kind = "binary",
files = { "src/*.cpp" },
includedirs = { "src" },
defines = { "FOO", "BAR=BAZ" },
})
https://xmake.io/guide/project-configuration/syntax-descript...* 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.
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.
We have so many build utilities out there.
MobiusHorizons•1w ago
ash-b-dev•1w ago