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
            $(RM) $*.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:

• The build configuration can be stored in the build directory so it’s easy to keep multiple build configurations around at the same time.
• The build can run without the privileges required to write to the source directory, which prevents bugs in the build system from trampling over changes.
• You don’t need to put a load of things in .gitignore and equivalent for build artefacts and then have exemptions if you actually do need to ship a file of the same type as a build artefact, so your revision control system integration is simpler.
• Overlapping with the last two points: if your build never modifies anything in your source tree, your revision control system doesn’t have to roll things back or do partial-file commits and your dependency tracking is simplified (if you need to modify a file in the build, don’t modify in-place, modify a copy in the build directory and then add the output as the dependency for the other things).
• If your source tree is immutable for the build, you can replicate it easily for distributed builds with aggressive local caching.
• You can have different backup and FS properties for source and build directories. For example, I turn off fsync to the ZFS filesystem mounted in ~/builds because everything in a build directory can be recreated from source and so I don’t care if I lose some data there in the event of a system crash.

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.

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.