Scons is really good

We use in a cross-platform project (Linux, Windows, Android) plain gnu makefiles with includes for different toolchains and flags for each arch platform, Conan v1 to handle library dependencies and bash scripts to orchestrate the builds. Now we're porting the makefiles to CMake to integrate with Conan v2 that uses cmake presets to inject dependencies and Conan profiles to set the toolchains for each architecture platform for cross-compiling. The issue is that you need to run "conan install ...." to build dependencies and generate cmake presets before you can run cmake. That is something odd when you have integrated CMake plugins in your IDEs like VSCode

Visual Studio build tools are so frustrating!! Due to Windows being such a widely used platform makes it a target for high grade nation-state and cartel malware (I refer to the nation crippling kind). I routinely download game engine source code and my antimalware scanner ultimately deleted my final executable project because I had unknowingly compiled a W32.infostealer.Trojan *into* one of my shipping DLLs... ...F**** Windows man!!

TLDR - Cmake is not as good as Meson, but is best for compatibility, if you don't have a lot of dependencies, use Meson. More often then not, it is best to take the time to learn Cmake.

i love c++ for syntax, freedom and some of the features, but absolutely hate it for build systems and that there is no good package manager. tbh, i do not get why makefile exists in the first place, i think all that make can do , can be recreated with a bunch of shell/Powershell scripts. actually shell scripts are even more powerful, becuase you can download dependencies with wget.

CMake is most popular, but it's awful language that's mixture of declarative and imperative paradigms, it's awful language that changes every year and make it's patterns obsolete very quickly. Everyone uses CMake in their own way what creates tons of incompatibilities between libraries. It's a maintenance nightmare, especially as you ever did something with cargo.

Meson looked promising, so I started trying to get into it. Then I found that the documentation site sets up the current document's "navigation sidebar" on the right and then automatically hides all the nested sections which AREN'T IN VIEW, expanding things that come into view and collapsing things that go out of view... unless you block the JS and have no right sidebar at all. So, one way or another, you don't know what subheadings there are until one of them is already on your screen, making the thing an insult to the very concept of navigation sidebar. I was so unhappy that I merely walked away.

awesome. thanks buddy. your awesome

where were you 5 years ago. kea sigma delta, the last endian bender. please also teach how to use an hex editor. youre awesome.

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.

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?

i just do cargo add x and cargo build

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.

Please make daily problem set like this, this very interesting and enjoyable

I was about to take a very interesting C++ project (SOCKS5 proxy, DNS, a lot of good stuff to challenge). After 10 hours of trying to make the cmake to work (on ubuntu, so not Win32 to blame) I met with the owner and told him no. If he would not insist to use cmake (and ACE, for some reason)... I had the first PoC working. But spending 70% of time on build only is insanity. Same for winget. Unusable. Then fired up a console and build OpenSSL and others in minutes. D'oh.

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

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

Nobody recommends/likes SCons?

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

Premake5?

Visual Studio includes pretty decent CMake support in its latest versions but the best IDE for CMake is probably CLion from JetBrains. Both have CMake debuggers and both support remote development but CLion also supports building and debugging inside Docker containers.

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

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.

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.

Here's what I've learned in 40+yrs of coding. Visual Studio is the way to go. It's all simply self-contained and you can just hit build and voilá, out pops an executable. The problem with CMake is that there's so much farting around. Everybody does things differently and rarely can you get CMake to immediately work out of the box. Something always breaks somewhere because of something that isn't installed, or not on the path, or in a different location etc etc. Then you also have a dependency on CMake itself etc. I just want to download a solution file and just build, simples. This does mean, you're locked into Windows, but if you learn Make, you can create a Makefile and have that look after you forever. It's not like you'll be changing it everyday or something. Then there's the automatic downloading of dependencies, which is a terrible idea from the outset. Firstly, you're at the mercy of that resource going away, being broken and a myriad of other things that could break your build. It's far easier to add that dependency as a library that is built as part of the solution. CMake only really exists because people couldn't read the Make man file; oh and because it's free. The same reason Git is the most common repo.

Thanks for the effort. While the topic is both important and interesting, I find several important problems with the findings presented. First - as it is also mentioned - CMake is a build system generator (not a build system), which targets multiple make systems (like make, Ninja and msbuild). Thus comparing CMake and say make or Ninja is really comparing apples and oranges. CMake is worthless without a build system like make or Ninja. Mentioning Nuget but not vcpkg is a significant omission. Vcpkg is more for C++, while Nuget is more for .NET. An important aspect of evaluating build systems and build system generators is how does the systems work at larger scale (for professional usage). It is not really that important how easy it is to make a Hello World project, but rather to know that you wont get stuck after a significant investment. Also how to integrate 3rd party code, is important. Since CMake is the industry de facto standard today, it has a huge advantage. Regardless if whether someone like it or not. How to write Ninja files is not really important, since that is not the intension (as mentioned). Reading Ninja files may be important for troubleshooting, and that is straight forward. But really the point of Ninja is speed (and it is fast), thus a comparison of build speed for reasonable sized projex4 between say Ninja, make and msbuild would be interesting. A tricky part of build systems for C++ is how modules is supported. It may not be common today, but will be soon. My understanding is that CMake with Ninja (and probably msbuild) is supports modules, while it is difficult (maybe impossible) using make. How does say Meson handle C++ modules ?

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

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.

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

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

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.

build.zig

I've been using CMake for a couple of years now and maintain a CMake build system for rather large multi-platform project during my day job. CMake is such an incredibly hot mess. So many bad decisions, so much confusion, broken dependencies, debuggability sucks... But then again, it is so common and has so much functionality there is nothing comparable atm. I should really look into Meson, because we need to extend CMake with Python anyway,

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

We use MS Visual Studio for all C++ projects. It is a "propper" build system and it beats the pants off of CMake in my opinion. VS can build these C++ projects without any of the crappy 3rd part tools like CMake. I tear my hair out whenever we encounter an open source lib e.g. PoDoFo. It comes with CMake files that never work without a massive amount of pain. And even when they eventually work, all CMake does is create the .sln and revent dependencies. And it does it badly. Why do this? Why not distribute sources with VS .sln and .prj files. It's nuts. I should add that we only build for Windows. There's no other OS worth bothering with in our case.

Hi, Nice video! I'm using xmake. It's Lua based, it can handle dependencies, C++20 modules, so simple and works great on every platform

What about the zig build system

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 🤷

Similar experience, tried to use Bazel with a third-party library. Even after spending a significant amount of time, I couldn't make things work (tried the workspace and bazelmod both) and had to switch back to CMake (glad).

im watching it after openai has announced that o3 has achieved agi lol

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.

have you tried the nob library from the channel tsoding? it’s quite different and simpler

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.

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.

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

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

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

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++.

I've had far too many problems with CMake, Meson and Ninja to ever recommend them. I only update when I need to for security's sake, and CMake hates me as a result. But the number of times I've fixed other people's projects refusing to build by changing the minimum version number "required" tells me it's a garbage system. The minimum version should be set by the features used, not just willy nilly based on the current version number in use. Regular old Make isn't difficult and you can write a template and copy it at the start of every project and adding to it is easy. Of course, there are other build systems you should try, such as Tsoding's nobuild which he's now renamed as nob.h and converted to a single header drop-in. It's an intriguing concept using the language itself to build a project, although you could use it for any language other than C if you know how to issue the compiler commands to build them.

Another package manager that works with Visual Studio is vcpkg, which also has Raylib available. Fun fact: vcpkg uses CMake behind the scenes.