6 Months of Testing C++ Build Systems: Here’s What You Need to Know

[@GuillermoH77]

Comment before watching: my experience of 25+ years of dealing with them is they range from bad to terrible. Really, one of the worsts downsides of C and C++.

[@GuillermoH77]

Comment after watching it: I still think the same about C++ BS (Build Systems), but you present some interesting thoughts at the end. Nice video!

[@FLMKane]

Cmake is the number one reason why I don't touch c++ For C? I'd rather use a plain old makefile

[@KeaSigmaDelta]

Thanks.

[@toby9999]

Not if you're using VS. It eliminate the agony. It just works.

[@toby9999]

​​@@FLMKaneHow about using C++ without CMake. That's what I've been doing for 30 years. I will never touch CMake again. It is total garbage and heart attack inducingly difficult to use. That said, if you're stuck on Linux, you don't have that option.

[@WizardofWestmarch]

As someone who's been (re)learning C++ recently after over a decade of not really touching it, I appreciate the time you put into this video. Seems in line with what I'd gathered reading elsewhere. CMake has its flaws but the fact the vast majority of projects are using it means the easiest path forward is to stick with that, and once you learn it it isn't awful, just getting it understood is rough. Thank you for putting this video together.

[@KeaSigmaDelta]

Thanks, and you're welcome.

[@toby9999]

I absolutely loath CMake. It's a total piece of crap, in my opinion. I've struggled with it far too many times and suffered too many migraines doing it. The process is made harder than it needs to be due to crappy documentation. We now just use MSVC / Visual Studio mostly... it just works. No dramas. The only time we encounter CMake these days is when importing an open source library such as PoDoFo into VS. It's a dog of a job and it renders the whole library unusable outside of the original folder structure. No one else in the team can debug it. It's just awful.

[@oserodal2702]

Bazel has been the bane of existence of nixpkgs maintainers, so I'm not surprised...

[@KeaSigmaDelta]

Oh, so it gets worse? Mind you, it's hard to keep things simple when you have such ambitious large-scale goals...

[@oserodal2702]

@@KeaSigmaDelta The only section in the nixOS wiki that gets some snark comes from Bazel.

[@rursus8354]

The largest problem with CMake is that there are no real tutorials. There are some three purported tutorials that actually just twaddle, presuming we already know what CMake does. Like written by an expert that are unable to actually teach the nitty-gritty details.

[@hiedtchannel]

True. CMake is free but the company owning it is for-profit. I once asked a question with work email and they come back suggesting a whole course for my team.

[@KeaSigmaDelta]

That's why I created The CMake Tutorial: cmaketutorial.com/

[@__kvik]

CMake is horrible to learn and to use, and for me there's no satisfaction at all in knowing how and why it works. Mostly because of 1) being a language that somehow feels worse than shell scripting in terms of robustness, and 2) failing very hard, or rather refusing, to provide and to educate people about a sensible default workflow which works for 90% of the projects from development to packaging / installation -- something that Meson recognizes and is loved for. This results in basically every project inventing their own approaches for some thing or the other and ultimately forcing one to read through the dependency's CMake code if they wish to depend on it, or just throwing in the towel and rewriting the build outright... My references here are I've been working for the last three years with a body of code that's built by some 70k lines of CMake in total.

[@KeaSigmaDelta]

Ugh! 70K lines of build script. That's a monster regardless of build system. CMake has a lot of poor and outdated tutorials out there, and the documentation is still hard to read (and littered with legacy stuff). That's why I created The CMake Tutorial (cmaketutorial.com/), to teach the best way to use modern CMake. And yes, I recommend scripts have sensible defaults, and keep things as simple as possible.

[@jikkentomato7751]

Especially packaging is a nightmare. It's difficult to come up with a more convoluted system. And then they complain that project maintainers are not doing packaging properly. Probably they dont want to spend a week figuring out how packaging works with cmake.

[@KeaSigmaDelta]

@@jikkentomato7751 I haven't tried CPack. IMHO, generating installers/packages is a separate task to building the code.

[@FLMKane]

... You're gonna need a static analysis tool just for your build files 😂

[@NCBob]

Gradle miles ahead in being garbage build system. Zero docs, breaks everything in every version, and plugins/scripting are opaque mudballs because of 1.(Zero docs). Even error reporting feels obtuse on purpose, no wonder since they sell the separate stacktrace explainer.

[@VolkerGoller]

GNU make, or make in general, is a good idea turned into a nightmare. Too many hidden properties, too many hidden defaults

[@nic37ry]

Good look even trying to run it on windows, it will fail even with a simple mkdir

[@ulrich-tonmoy]

What about the zig build system

[@KeaSigmaDelta]

A few people have asked/suggested that. Maybe later, when I finally get around to trying out Zig itself.

[@apprenticerocker9885]

I don’t know Zig build system but your avatar brings me back to my childhood 😊

[@ulrich-tonmoy]

@@apprenticerocker9885 its one of the reason im in this sector and theres a guy building a game in unreal engine looks quite good

[@andrewdunbar828]

@@KeaSigmaDelta Trying Zig is great, especially if you're interested in newer languages like Zig, Rust, and Odin. And of course the Zig build system is Zig. But you probably don't have to learn Zig that much separately beforehand. There's some biggish projects out there that are not in Zig but use Zig as their build system already.

[@pantium98]

I like xmake

[@gabrielkwong1878]

I suspect not much but good enoigh build process comtrol with premake and xmake?

[@KeaSigmaDelta]

I can't say, because I haven't tried premake or cmake. Right now I'm at the "I really want to write code instead of try another build system" stage...

[@gabrielkwong1878]

@KeaSigmaDelta understandable, I had another comment mentioning if you could do a conan2 review, of the experience and xommunity, but maybe whwn you've taken a break. Jest mentioning as that would be interesting to watch.

[@N....]

Visual Studio also supports Linux and Android the same way as it supports Windows, and it's a lot easier to switch between different configurations and CPU architectures than with generators like CMake. Though, actually maintaining and comparing the properties for those different configs/archs in VS is a bit slow and tedious compared to just writing some if branches in CMake. VS does support .props files though which can simplify sharing properties between multiple projects.

[@KeaSigmaDelta]

Do you mean Visual Studio itself? Or VS Code? While sharing the same (base) name, those two are different products. AFAIK, Visual Studio exists on Windows & MacOS X. VS Code works on many platforms.

[@N....]

@@KeaSigmaDelta I mean Visual Studio, not VS Code. Yes, Visual Studio only runs on Windows currently, but it supports targteting Windows, Linux, and Android using C++.

[@maxgordon3194]

aweosme video, if you find the time can you show some practical applications how to use c++ properly in the industry work. most universities and colleges teach console applications then you're screwed. please guide what to do next, I tried direct x programming but its a huge jump from a console application straight there. please guide what to do next.

[@abarocio80]

A good comparison would be between cmake and auto tools (not make).

[@KeaSigmaDelta]

Comparing make with cmake is useful to those who use Make directly (which I suspect is far more than use autotools). If someone does do a cmake vs autotools comparison, then please share the link here.

[@chmod0644]

Meson is the one for me!

[@Mzkysti]

Comparison to for example cargo would be nice. Also unit testing and integration testing should be part of the build system?

[@KeaSigmaDelta]

Cargo is for rust. I see testing as a separate task to building, although build systems can have testing facilities (e.g., CTest). Regardless, covering that too would make the video too long-winded for most people.

[@Mzkysti]

@KeaSigmaDelta The Rust build system would be good reference for C/C++, it still uses GCC, Clang, etc. I would never build anything without unit tests, so I see as integral part of it.

[@andreyv116]

I've done make-level build control in cmake when porting a makefile build system to cmake as part of work a while back. It was tedious but the reward was 3x faster build

[@quantumapprentice8120]

You mentioned a "cmake vs make" video at 5:05, do you have a link to it?

[@KeaSigmaDelta]

There are two videos: kzbin.info/www/bejne/hoi8hKx6Z9eJmK8 kzbin.info/www/bejne/fXuXgJKcoaylj9k

[@quantumapprentice8120]

@@KeaSigmaDelta thank you!

[@aniolmarinatares8807]

For serious projects I've found a pretty good balance by using GNU Make as the higher scripting language (on top I still have neovim bindings), I use it to call CMake commands, which at its turn uses ninja as the target build system.

[@KeaSigmaDelta]

Interesting way of working.

[@hedlund]

I've been at it since the early 00s and still haven't found anything to knock CMake off my top spot, yet. Unless it's a tiny thing, in which case I tend to write a justfile with a few recipes to call clang/gcc directly. It's absolute ass to get even remotely comfy with CMake, but the ROI on the time spent learning it makes it well worth it, at least for me.

[@VioletGiraffe]

CMake being the most used is a big mistake. Some kind of a "sunken cost" fallacy. Just because we spent time on a bad tool doesn't mean we have to keep using the bad tool forever now.

[@seawardspy-jl4hz]

Premake5?

[@KeaSigmaDelta]

I didn't test that one, but it looks interesting.

[@lemna9138]

Great video, only thing I'd add is that the visual studio built system is very resistant to debugging. So please avoid writing software with complicated build steps in it, you will eventually hit a wall of the build becoming unreliable

[@KeaSigmaDelta]

Thanks. I agree with keeping things simple, including the build script.

[@talideon]

Pants and Buck2 are quite similar to Bazel, but I found both much easier to get up and running.

[@KeaSigmaDelta]

Pants? Who on earth calls their build system pants?

[@JkaBG]

no premake?

[@KeaSigmaDelta]

Sorry, after 6 months of trying build systems I want to write more code instead of try more build systems. Premake is interesting, though. I've mentioned it in my build system comparison doc. If I do decide to test more build systems, it would definitely be the next one.

[@drizer76]

Hey what about promake, scons, Conan and vcpkg?!?!?

[@KeaSigmaDelta]

After doing these comparison videos for 6 months I really want to write code instead of try another build system. I do mention premake and scons in my build system summary doc. Conan and vcpkg are package managers not build systems.

[@lemna9138]

​@@KeaSigmaDelta I would strongly recommend zig/rust/odin then (although the community of the last has left me with a bad taste) they're all very different and have some fun ideas

[@georgehelyar]

Probably a skill issue (I'm ok in C and C++ but they are not my main languages) but I struggled with protobuf in cmake. I got there eventually but it was painful. For example can't glob files that don't exist yet. In another project I had a nice little re2 dependency, and then re2 later took abseil as a dependency and I had to make changes to my cmake, which seems wrong.

[@RichardEricCollins]

I took the other option. 😂 I made my own build tool. Calls GCC directly. No intermediate files created. Uses one file to define the project. Does all the dependency work. Not as powerful as cmake. But for simple projects just works. A file that lists source files, include paths, libs and build options. Job done. All written in c++. Am I mad. Yes. But my tool needs no other tool or environment other than GCC to work. And does not fill your project with a million temporary files.

[@Wosser1sProductions]

Sounds like NOB from tscoding

[@WlOlW1]

What about zig build?

[@KeaSigmaDelta]

I had a few people suggesting Zig build. Interesting idea. I might try it out later, when I finally get round to trying the Zig language itself...

[@ivanmoren3643]

The zig build system is used for some established pure C projects already, could be worth looking into for examples :-)

[@WlOlW1]

@@ivanmoren3643 indeed, like raylib used in this video for example

[@NotMarkKnopfler]

Meh. I just write my make files by hand. All these build systems seem to be more trouble than they're worth, to be honest 🤷

[@KeaSigmaDelta]

use whatever works best for you...

[@yingshenyu]

no xmake？it might be the most closest thing to cargo now.

[@KeaSigmaDelta]

Sorry, I haven't tried that one.

[@software_development_os]

I do not know where to start (:->) But my first question would be, why someone should use a build-system at all nowadays? And if, why not just use a build shell script? Even with projects with 50+ files, this would only take a few lines of script code (depending what you actually want to do by the script) and make a separate script for each platform. Secondly, the main usefulness of buildsystems is when a project grows over a certain size (maintaining all the dependencies, buildtimes, libraries, etc.) comparing buildsystems with projects < 10 files, is like comparing sorting algorithms with just 3 elements to sort ... But I appreciate the effort to focus at least on the differences between C/C++ buildsystems ... we need more of these kind of videos.

[@KeaSigmaDelta]

Shell scripts don't do incremental builds, and that matters a lot when the project gets large. Fair point about the limitations of comparing build systems with small projects. I kept them small to be easier to understand (important for videos like this), and because I have limited time to work on this. The two projects do show/test the two fundamentals of any project: building multiple files, and linking to libraries.

[@software_development_os]

@@KeaSigmaDelta Yes, for large codebases I totally agree, a build-system is a must, but for small to "medium" projects any buildsystem IS the bloat and does not help anymore. This is totally different compared to the past where indeed incremental builds are essential, but nowadays the hardware is so fast that there is an optimum size of a project where just building every c(pp) file for every build is almost indistinguishable from an incremental build. Your example Raylib is a good example, on my old i5, I just download the raylib version I need, remove all the build-bloat, create a build-script with 2 functional lines (one to build all the obj-files and one to build the library) and that builds in 1 to 2 seconds. What is there to gain with incremental builds or a build-system? No need to install CMake, no need to include a hardcoded url in my build-files, no need to learn CMake syntax, no need to adapt a makefile when adding c[pp] or h-files, no need to remove bloat-files before making backups, etc.. Even for a larger project like SDL2 (150-200 c-files), on my old PC it builds in ca. 20 sec., and most of the work was to remove the build-system bloat to get it building like that .... Don't get me wrong, if I had to wait 20 sec every time if I worked at the project, it would really bother me. But I would first look for other solutions to speed it up, before introducing a make-system, replacing the two functional lines in a shell-script.

[@SergLapin]

This is how autotools started, just write a shell script, keep adding macros and etc to reuse parts for different projects. Wuala, you are an owner of a hairy ball of shell scripts like autotools.

[@ArtemShoobovych]

i tried a lot of C++ build systems, but for slightly more complex cases, involving a few 3rd party dependencies. my main preference is CMake solely because VCPKG (syntax and the user experience are just garbage in my opinion). XMake is much better (at least it is a simple and usable syntax) plus it supports both VCPKG and a few more, but it really lacks good IDE support. bazel and buck are both better (than XMake) in terms of syntax, but buck is somewhere in a limbo between a working but deprecated v1 and non-working future v2. neither supports VCPKG. but both have an insanely big benefit of a parallel compilation, which you do not normally get with other build systems. the idea of CMake where it only generates build scripts for target system is just wrong in my opinion - why should a developer bother with this intermediate step?

[@KeaSigmaDelta]

The only reason that a developer should bother with the intermediate step of generating the "native" build script, is because that's how CMake (and Ninja, Meson, Premake, Bazel, etc.) work. You don't really need to know that this is how it works. Just run the configuration step with "cmake ..", and then do the actual build with "cmake --build . --parallel". I've seen some nitpick and obsess over the fact that CMake is a "meta build system" or a "build script generator." Personally, I don't care that it's a "meta build system, because that's NOT why I use it. I use it because it enables me to build my software on multiple platforms.

[@ArtemShoobovych]

@@KeaSigmaDelta i know about the CLI flags, i was just expressing an opinion as a rhetorical question =)

[@whiitehead]

Definitely would have liked to see premake in this video but otherwise great comparison, thanks!

[@rj7250a]

Premake should not be used, it is barely maintained.

[@KeaSigmaDelta]

That's a pity. I thought that premake looked interesting.

[@KeaSigmaDelta]

Yeah, sorry. After 6 months I decided that's enough build systems. Premake does look interesting, though.

[@SuperGauravgautam]

didn’t even put xcode in the thimbnail. its good though. definitely better than visual studio.

[@KeaSigmaDelta]

Sorry about that. It isn't there because I didn't try it out (don't have a Mac). I did mention it, though.

[@SuperGauravgautam]

@ i know, thats why i said its not in the thumbnail and not that its not mentioned

[@mygamesm]

i just do cargo add x and cargo build

[@KeaSigmaDelta]

Yeah, because you use the Rust language (which I have not yet been able to properly try out).

[@funkydiddykong]

Nix?

[@elcugo]

Nix is a packaging system, not a build tool.

[@drizer76]

Gradle would be a better choice, Bazel is enterprise level build system…

[@KeaSigmaDelta]

Interesting. I didn't even think about Gradle for C/C++ projects. It felt overly complicated to me when i encountered it, and I thought it was more Java centric.

[@NCBob]

Gradle is shit choice because saying it's good without any supportive statement is not a valid argument

[@DanieleNiero]

Nobody recommends/likes SCons?

[@KeaSigmaDelta]

Not that I know of. I've heard about it because the Godot game engine uses it.

[@ShimoriUta77]

Bro: "[Bazel is] needlessly complicated" Me: "sudo pacman -S bazel" Guess the problem, in this case, is not Bazel, it's Windows... again.

[@KeaSigmaDelta]

Maybe, but Windows didn't decide how Bazel should be installed on Windows. Nor did it decide to create a separate tool called Bazelisk and make that the recommended way to install Bazel.

[@JoeDiPilato]

Bazelisk is just an optional tool that allows the version of the build system (bazel) itself to be automatically downloaded and used dynamically according to a file checked into a repo. This is particularly impactful if the bazel version is updated during the life of the project, since checking out historical commits can be rebuilt without needing to worry about the bazel version. (Similarly useful when a project is being worked on by multiple devs, or when working on different projects that use different bazel versions)

[@yokozombie]

I can confirm that Bazel is pain in the ass to get on Windows because authors didn't care a bit

[@guilherme5094]

👍