I was curious about xmake architecture so I looked into the source code.
xmake doesn’t “require” or “depend upon” Lua. Instead, xmake embeds Lua. Specifically it embeds LuaJIT 2.1, based on what I could tell in their repo source.
So, when you run xmake, you’re actually running a a full-blown Lua implementation that is self-contained in the xmake binary, that has some automatic imports for the xmake embedded build DSL. If you want to run arbitrary Lua using xmake, there is a built-in “lua” plugin, shorthand “xmake l”, described here:
So, it would be a bit like if you built a build language atop Python, but rather than depending on Python, you made your whole build tool embed the entire CPython interpreter, pinned to some version. Lua is used in this way more commonly than Python is, of course.
This means xmake itself is just a C program with large submodules written in Lua, running inside that embedded Lua context. The upside here is that xmake’s releases are just plain platform-specific native binaries that bundle everything you need, and that make no assumptions about your base system. This is a nice benefit in a build tool, as it aids in reproducible builds.
Instead, xmake embeds Lua.
Instead, xmake embeds Lua.
Isn’t that sort of the main purpose of Lua, to be embedded like this?
Yes, it is completely independent.
Out of interest. Could it run with different (non-C) Lua implementation? Because I find it interesting to check out if this would work with luerl for using as a “semi-native” build tool in Erlang.
I’ve been putting up with CMake for years, in our complex cross-platform (pretty much every major platform) C++ codebase. Xmake looks wonderful … as though someone finally listened to my rant about how build systems should use a real programming language instead of awkwardly extending their syntax into a pidgin.
Is it as good as it looks on the surface?
I keep hoping that Jon will finish Fabrique. I like the fact that CMake + Ninja has a clean separation of responsibility, one doing responsible for configuring a build, the other responsible for running that build as fast as possible. This means that it’s possible for CMake to export IDE projects if I want a richer debugging experience. Ninja itself is great and I don’t see any point in trying to recreate it. The nicest thing I can say about CMake is that it’s not autoconf.
CMake is a macro system, so everything is a string. Sometimes you interpret it as a number (which is fun when it’s a version string like 10.10 vs 10.2) or a list (with the inherent problem of using a valid character as the list separator). CMake also randomly hard-codes things. For example, the back end to use the Visual Studio compiler always passes /TC or /TP (C or C++ input), so if you want to compile Objective-C on Windows with clang-cl from a CMake build system you have to use an undocumented feature of the clang driver intended for debugging to tell it to remove these flags: they don’t appear in any variable visible in your CMake scripts.
In contrast, Fabrique is a strongly typed language with high-level types such as files (so your build system has enough information to drive a sandboxing framework, for example), actions, lists, and so on, along with functions. It is designed to be possible to drive from an IDE’s GUI or a configuration file and includes concepts such as modules and delegation so you can easily express ideas such as ‘the C compiler flags in this module should be these, plus any from the command line, but not the ones from the parent directory’ (at least, in the design - this is missing so far) and, because those options are passed as a list (not a string), they’re easy to filter without having to escape / unescape.
If anyone finds build system generators interesting and has spare time, please contriute to Fabrique! The design is great, the implementation is incomplete and I don’t think Jon has had time to work on it for over a year.
Yes, you can try it.
Xmake doesn’t generate VS projects which I think is why CMake is still so popular. vcpkg supports CMake out of the box. I was wrong see below.
xmake also support to generate vs projects, cmakelists, build.ninja, makefile, compile_commands and etc.
You can see https://xmake.io/#/plugin/builtin_plugins?id=generate-visualstudio-project
xmake project -k vs
xmake project -k vsxmake (generate vsproject and wrap xmake, recommanded)
And xmake also support vcpkg, conan, clib, homebrew packages. You can see https://xmake.io/#/package/remote_package?id=add-a-vcpkg-dependency-package
Awesome, it’s been a while since I looked again and I should have checked it :)
It’d be lovely if it generated Xcode projects too.
I think Stroustrup’s quote about there only being two kinds of languages applies to build systems as well. I must admit I haven’t looked into xmake much yet, are there any larger projects using it?
There is an excellent talk by Jussi Pakkanen (Meson) from CppCon 2019 about the rabbit hole of complexity build systems have to handle.
Yes, there are not many larger projects using it at present, because I didn’t do much to promote it.
But there are still some outstanding projects using xmake.
see more https://github.com/xmake-io/awesome-xmake/blob/master/README.md#projects
I’ve been doing Lua development for a while, but just recently have moved over to doing more C development. And Makefiles have been something I struggled with. I will learn them eventually because so many projects use it, but getting started with my own project and trying to figure out how to use a Makefile was such a headache for me.
Once I found xmake, my productivity when way up. Thank you so much!