There’s one feature of make I use that I do not see mentioned here (or in any other make replacement)—that of implicit rules. At work, I embed Lua, and as part of that, I also embed all the modules required into the final executable. It’s easy enough to add an implicit rule:
%.o : %.lua
$(BIN2C) -9 -o $*.l.c $<
$(CC) $(CFLAGS) -c -o $@ $*.l.c
(Yes, we use GNU Make), add:
foo.o : foo.lua
and have make do the right thing (and there’s a way to do this in POSIX make as well).
As usual when another build sysem compares themselves to Meson in terms of package management, nobody knows that Meson also has that.
The most usable feature of xmake is the abstraction layer it has.
For me a good build system behaves the same with any compiler (At least for the common flags of compilation).
So I want to be able to use OpenMP, Floating Point Precision (Fast Math), Optimization level, etc… without worrying which compiler is used.
I think xmake is the only build system which provides this.
I was put off xmake by the fact that it seems to strongly encourage the antipattern of building from within the source directory. Separate build directories have a lot of advantages:
It looks as if the io.replace example here is explicitly patching the source files. I’d be very nervous of a build system that makes this something that’s easy to do. It’s encouraging you to make the kinds of build systems that people will grumble about when they have to maintain them in a decade’s time.
you can do build in non-source directory.
xmake -P /home/projectdir
You can, but the docs all discourage this and at least some of the things in this article won’t work correctly if you do. It’s clearly a build system that’s been designed for in-tree builds and then had support for out-of-tree builds added, rather than one that’s thought about builds with immutable sources from the start.
This actually made quite a compelling case in my opinion.
I wasn’t sure if I would before, but now I am definitely going to try out xmake.