As someone who has also spent two decades wrangling C/C++ codebases, I wholeheartedly agree with every statement here.

I have an even stronger sentiment regarding cross compilation though - In any build system, I think the distinction between “cross” and “non-cross” compilation is an anti-pattern.

Always design build systems assuming cross compilation. It hurts nothing if it just so happens that your host and target platform/architecture end up being the same, and saves you everything down the line if you need to also build binaries for something else.

Agree with the feedback.

Also the problem isn't creating a cargo like tool for C and C++, that is the easy part, the problem is getting more userbase than vcpkg or conan for it to matter for those communities.

> Never ever build in '-03 -march=native' by default. This is always a red flag and a sign of immaturity.

Perhaps you can see how there are some assumptions baked into that statement.

> -march=native is always always a mistake

Gentoo user: hold my beer.

since you have a lot of experience, can I ask what do you think about this:

- skipping cmake completely? would this be feasible?

- integration of other languages in the project?

- how to handle qt?

>15000

15000 what?

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.

Agreed, 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.

Similar to premake I have never been a fan of the global state for defining targets. Give me an object or some handle that I call functions on/pass to functions. CMake at some point ended up somewhat right with that to going to target based defining for its stuff and since I've really learned it I have been kinda happy with it.

actually looks very similar to Meson [https://mesonbuild.com/], which is getting a lot of traction in FOSS [https://mesonbuild.com/Users.html]

e.g. from their docs:

  project('sdldemo', 'c',
          default_options: 'default_library=static')
  
  sdl2_dep = dependency('sdl2')
  sdl2_main_dep = dependency('sdl2main')
  
  executable('sdlprog', 'sdlprog.c',
             win_subsystem: 'windows',
             dependencies: [sdl2_dep, sdl2_main_dep])

I've had some experience with this but it seems to be rather slow, very niche and tbh I can't see a reason to use it over CMake.

There are so many reasons why C/C++ build systems struggle, but imo power is the last of them. "Powerful" and "scriptable" build systems are what has gotten us into the swamp!

* Standards committee is allergic to standardizing anything outside of the language itself: build tools, dependency management, even the concept of a "file" is controversial!

* Existing poor state of build systems is viral - any new build system is 10x as complex as a clean room design because you have to deal with all the legacy "power" of previous build tooling. Build system flaws propagate - the moment you need hacks in your build, you start imposing those hacks on downstream users of your library also.

Even CMake should be a much better experience than it is - but in the real world major projects don't maintain their CMake builds to the point you can cleanly depend on them. Things like using raw MY_LIB_DIR variables instead of targets, hacky/broken feature detection flags etc. Microsoft tried to solve this problem via vcpkg, ended up having to patch builds of 90% of the packages to get it to work, and it's still a poor experience where half the builds are broken.

My opinion is that a new C/C++ build/package system is actually a solvable problem now with AI. Because you can point Opus 4.6 or whoever at the massive pile of open source dependencies, and tell it for each one "write a build config for this package using my new build system" which solves the gordian knot of the ecosystem problem.

I will categorize this as a pattern I've seen which leads to stagnation, or is at least aiming for it. Usually these are built on one or more assumption which doesn't hold. The flow of this pattern:

  - Problem exists
  - Proposals of solutions, (varying quality), or not
  - "You can't just solve this. It's complicated! This problem must exist". (The post I'm replying to
  - Problem gets solved, hopefully.

The world is rich in complexity, subtlety, and exceptions to categorization. I don't think this should block us from solving problems.

I agree with you to a degree, but I frame it slightly differently because there is a solution.

The problem is one of Tooling & Methodology. Not just tooling.

There is no divide between tools/methods - although there is often a massive conflict over methods, and thus tools, implying a relationship - but in fact both tooling and methodology need to be aligned or else poor tools are created.

There is much discussion about ‘the build problem’, but it is just as much an issue of solving ‘the method problem’.

For example, a vast majority of the problems of building software can be solved by using Docker (a method), or indeed adding new methods for various situations - i.e. embedded: compiler-onboard vs. cross-compiling, games: —march, etc.

I think the “I and Your” part of your position is ineffective - better to think of it as ‘a tool I/others want to use’ and ‘a method I/others agree to use’, where: tools and methods are aligned in equilibrium for the duration of the project (in an ideal case).

It’s ineffective because of the difference in effect between ‘want’ and ‘agree’ on that equilibrium.

Some methods, a person may not necessarily want to use - but agree to do so, because there is a local tool to assist with the method. Some tools, people will violently refuse to use because they despise the implied method and will never agree to it; sometimes, people get fired for not aligning methodology - but also often for writing a tool nobody (or hardly ever anybody) ever uses/can use/wants to use. (There’s a whole world of software that only one guy knows how to wrangle because they ‘built a better build system’…)

Apropos the “Yet Another C/C++ Configuration/Combobulator” problem, I tend to think the ‘problem with build systems’ is due to the avid desire to just build a new tool to force a new method rather than adopting an existing method and thus using existing tools, and, therefore in my opinion, the fewer new tools in this department, the better… but that’s just me, I’ve been wrangling C/C++ codebases since they were new languages, and I’ve seen some shit, kids ..

The solution is _always_ to align your methods with your fellow user-developers first and then work together on the tooling, old or new… because all software is social, and has a social responsibility to the user, and user-developer tools built to construct software socially, even more so.

this project is something i'd do, i had the idea about the same time as you did, "why something like cargo for c++ doesn't exist?" and you did it, thanks I guess.

> For example, Cmake can use vcpkg to install a package but then I still have to write more cmake to actually find and use it.

I have this solved at our company. We have a tool built on top of vcpkg, to manage internal + external dependencies. Our cmake linker logic leverages the port names and so all you really do is declare your manifest file (vcpkg.json) then declare which one of them you will export publicly.

Everything after that is automatic including the exported cmake config for your library.

I find that conan2 is mostly painful with ABI. Binaries from GCC are all backwards compatible, as are C++ standard versions. The exception is the C++11 ABI break.

And yet it will insist on only giving you binaries that match exactly. Thankfully there are experimental extensions that allow it to automatically fall back.

Yup, I read "— think Cargo, but for C/C++." and closed the tab.

They did say it was inspired by cargo, which is often installed using rustup as such:

    curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

I don’t love this approach either (what a security nightmare…) - but it is easy to do for users and developers alike. Having to juggle a bunch of apt-like repositories for different distros is a huge time sink and adds a bunch of build complexity. Brew is annoying with its formulae vs tap vs cask vs cellar - and the associated ruby scripting… And then there’s windows - ugh.

I wish there was a dead simple installer TUI that had a common API specification so that you could host your installer spec on your.domain.com/install.json - point this TUI at it and it would understand the fine grained permissions required, handle required binary signature validation, manifest/sbom validation, give the user freedom to customize where/how things were installed, etc.

This is fitting for something simulating cargo, which is a huge supply chain risk itself.

Given you're about to run a binary, it's no worse than that.

Cmake might suck, but is arguably the de-facto now. It's not standard, since the C++ committee does not want to deal with the real world (tooling).

I'm intrigued by the idea of writing one's own custom build system in the same language as the target app/game; it's probably not super portable or general but cool and easy to maintain for smaller projects: https://mastodon.gamedev.place/@pjako/115782569754684469

While I do get why CMake is a scripted build system, I cannot help but notice that other languages don't need it.

In Rust, you have Cargo.toml, in go, it's a rather simple go.mod.

And even in embedded C, you have platformio which manages to make due with a few .ini files.

I would honestly love to see the cpp folks actually standardizing a proper build system and dependency manager.

Today, just building a simple QT app is usually a daunting task, and other compiled ecosystems show us it doesn't have to be.

Cmake is doing a lot of underappreciated work under the hood that would be very hard to replicate in another tool, tons of accumulated workarounds for all the different host operating systems, compiler toolchains and IDEs, it's also one of few build tools which properly support Windows and Visual Studio.

Just alone reverse engineering the Xcode and Visual Studio project file formats for each IDE version isn't fun, but this "boring" grunt work is what makes cmake so valuable.

The core ideas of cmake are sound, it's only the scripting language that sucks.

Another fresh example of what you don't like: https://www.youtube.com/watch?v=ExSlx0vBMXo Building C++: It Doesn't Have to be Painful! - Nicole Mazzuca - Meeting C++ 2025

Build systems don't plan to converge in the future =)

My thoughts exactly. I thought this was going to be some new thing, but it's just yet another reason that I'll stick with Makefiles.

When you need a configuration step, cmake will actually save you a lot of time, especially if you work cross platform or even cross compile. I love to hate cmake as much as the next guy, and it would be hard to design a worse scripting language, but I'll take it any time over autoconf. Some of the newer tools may well be more convenient - I tried Bazel, and it sure wasn't (for me).

If you're happy to bake one config in a makefile, then cmake will do very little for you.

> most of the time CMAKE is just overkill and does not play well the compiler/binutils provided

You need to define a CMake toolchain[1] and pass it to CMake with --toolchain /path/to/file in the command-line, or in a preset file with the key `toolchainFile` in a CMake preset. I've compiled for QNX and ARM32 boards with CMake, no issues, but this needs to be done.

[1]: https://cmake.org/cmake/help/latest/manual/cmake-toolchains....

For toy projects good old Make is fine...but at some point a project gets large enough that you need something more powerful. If you need something that can deal with multiple layers of nested sub-repositories, third-party and first-party dependencies, remote and local projects, multiple build configurations, dealing with non-code assets like documentation, etc, etc, etc - Make just isn't enough.

For simple projects. Make is easier for simple things I will grant. However when your projects gets complex at all make becomes a real pain and cmake becomes much easier.

Cmake has a lot of warts, but they have also put a lot of effort into finding and fixing all those weird special cases. If your project uses CMake odds are high it will build anywhere.

Why do you say this? I respect it, I'm just curious.

Craft has project management and generates starter project structure. You can generate header and source files with boilerplate starter code. Craft manages the building of the project so you don’t need to write much CMake. You can also save project structures as templates and instantiate those templates in new projects ready to go.

Yes, many libraries are system wide that is true. This is something I had on the list of features to add. System dependencies. Thank you for the feedback!

This is a fair and valid point. However, why leave your workflow to write a prompt to an AI when you can run simple commands in your workspace. Also you are most likely paying to use the AI while Craft is free and open source and will only continue to improve. I respect your feedback though, thank you!

You're missing finding library/include paths, build configuration (`-D` flags for conditional compilation), fetching these from remote repositories, and versioning.

The same AI tool could have written a de-facto CMakeLists.txt file for you.

AFAIK, Craft is only the most popular tool to build KDE software on (or perhaps for) Windows. On Linux, it's kdesrc-build (OG, Perl) or kde-builder (more recent, Python).

Yes! This is definitely on the list of features to add. Thank you for the feedback!

I believe it supports only projects having a working cmake setup, no extra magic

I suspect it depends on a specific directory structure, e.g. look at this generated cmake file:

https://github.com/randerson112/craft/blob/main/CMakeLists.t...

...and for custom requirements a manually created CMakeLists.extras.txt as escape hatch.

Unclear to me how more interesting scenarios like compiler- and platform-specific build options (enable/disable warnings, defines, etc...), cross-compilation via cmake toolchain files (e.g. via Emscripten SDK, WASI SDK or Android SDK/NDK) would be handled. E.g. just trivial things like "when compiling for Emscripten, include these source files, but not those others".

CMakes piles up various generations of idioms so there are multiple ways of doing it, but personally I’ve learned to steer away from find_package() and other magical functions. Get all your dependencies as subdirectories (whichever way you prefer) and use add_subdirectory(). Use find_package() only in so-called "config" mode where you explicitly instruct cmake where to find the config for large precompiled dependencies only

As much of a dog as cmake is, "just use make!" does not solve many of the problems that cmake makes a go at. It's like saying go write assembler instead of C because C has so many footguns.

CMake does three main things: Compilation with dependency tracking, finding external dependencies, and platform-independence. Make only does one of them.

Another comment suggested batch files - these do zero out of three.

This is very true. My thought process was that since majority of projects already run on CMake, I would simply build off of that and take advantage of what CMake is good at while making the more difficult operations easier. Thank you for your feedback!

I'm all for shitting on CMake, but Jesus, to suggest Make as a replacement/improvement is an unhinged take.

> The tough truth is that there already is a cargo for C/C++: Conan2

Is it though?

When I read the tutorial: https://docs.conan.io/2/tutorial/consuming_packages/build_si...

It says to hand write a `CMakeLists.txt` file. This is before it has me create a `conanfile.txt` even.

I have the same complaint about vcpkg.

It seems like it takes: `(conan | vcpkg) + (cmake | autotools) + (ninja | make)` to do the basics what cargo does.