The least painful C/C++ build tool I've used is xmake
https://github.com/xmake-io/xmake
The reason why I like it (beyond ease-of-use) is that it can spit out CMakeLists.txt and compile_commands.json for IDE/LSP integration and also supports installing Conan/vcpkg libraries or even Git repos.
set_project("myapp")
set_languages("c++20")
add_requires("conan::fmt/11.0.2", {alias = "fmt"})
add_requires("vcpkg::fmt", {alias = "fmt"})
add_requires("git://github.com/fmtlib/fmt v11.0.2", {alias = "fmt"})
target("myapp")
set_kind("binary")
add_files("src/*.cpp")
add_packages("fmt")
Then you use it like # Generate compile_commands.json and CMakeLists.txt
$ xmake project -k compile_commands
$ xmake project -k cmake
# Build + run
$ xmake && xmake run myappAgreed, xmake seems very well-thought-out, and supports the most modern use-cases (C++20 named modules, header unit modules, and `import std`, which CMake still has a lot of ceremony around). I should switch to it.
I would happily switch to it in a heartbeat if it was a lot more well-documented and if it supported even half of what CMake does.
As an example of what I mean, say I want to link to the FMOD library (or any library I legally can't redistribute as an SDK). Or I want to enable automatic detection on Windows where I know the library/SDK is an installer package. My solution, in CMake, is to just ask the registry. In XMake I still can't figure out how to pull this off. I know that's pretty niche, but still.
The documentation gap is the biggest hurtle. A lot of the functions/ways of doing things are poorly documented, if they are at all. Including a CMake library that isn't in any of the package managers for example. It also has some weird quirks: automatic/magic scoping (which is NOT a bonus) along with a hack "import" function instead of using native require.
All of this said, it does work well when it does work. Especially with modules.