Close to half of C++ developers in that survey regularly use something other than CMake and I’ve seen projects at Microsoft and Epic Games use xmake. Why are you being such a pecker?

And yet lots of people use xmake and other alternatives…

Yup, Cargo is a good baseline to compare to. I don’t get the CMake arguments since:

• xmake isn’t trying to replace CMake
• xmake can create CMake files from an xmake project
• xmake can consume CMake files
• xmake can use CMake packages
• you can use xmake packages in a CMake project
• a lot of people quite obviously don’t like CMake

It’s working with the ecosystem, not against and is good for C++ especially since people are comparing C++ building with tools like Cargo now.

So it offers nothing over cmake…

In your opinion, I’d say the overall integration and being an actual build system are offerings for starters.

It also supports other languages like Zig, Pascal and Rust too. Here’s an example of C++ calling Rust, note the easy inclusion of Cargo crates…

https://github.com/xmake-io/xmake/tree/dev/tests/projects/rust/cxx_call_rust_library

xmake is just nicer, more concise and 100% less shouty. People in general use cmake because it’s the de facto standard, not because they like cmake and its DSL.

xmake can generate cmake files too so it’s not going against the grain. There are plugins for popular IDEs as well.

I’ll give some bullet points that might be of interest, I agree that they need a funky infographic or similar.

• it’s a build system itself, it doesn’t need make or whatever and compilation speeds are similar to ninja

  • which means it can do things like distributed building
  • and implement local caching, like ccache but supporting msvc as well as gcc/clang (actually msvc might be disabled at the moment)
  • … likewise remote caching, like Mozilla’s sscache for teams (again supporting msvc/gcc/clang)

• it has its own package manager but also works with pretty much all other popular package managers

  • the build system will default to any matching installed system libs unless you say otherwise ({ system = false} on a per-included package basis)
  • it downloads and installed necessary packages when first building a project
  • package manager can use pre-compiled Windows artefacts
  • can use the hosted online repo, or our own online or local repos (multiple if we want)
  • location of alternative repos can be set in xmake.lua file or configured on command line (or config file).

• can configure project with a TUI menu xmake f --menu

It just feels more straightforward and logical to me too. I know that’s subjective, but the objective part of that is it’s a unified build system, cache system and package manager that sets out to work with other tools.

(edited: tidied bullet lists)

Ditching libraries with very long build times unless they are absolutely essential too.

Interesting, thanks for sharing. I didn’t know such a speed up was possible and LTO doesn’t matter when we just want something built.

You can quickly get the args into a vector like this:

auto args = std::vector<std::string_view>(argv, argv + argc);

Checking equality etc directly instead of using strcmp stuff is better. There are libraries available for handling command line args too.