This is my life now, until I finally understand Cmake.
Which will probably be never.
Which will probably be never.
I mean, all cmake does is run some commands for you. You not understanding cmake errors (mostly) means you don't understand the errors given to you by the C/C++ compiler.
Partly, yes. But I also think their documentation is a bit hard do read. Maybe this will get better with time.
CMake can also emit its own errors during the configure step though, particularly if you have complicated build logic and/or lots of external packages.
Did you know that there is a debugger in Jetbrains CLion (and I think VS as well) that allows you to step through your CMake scripts? As ridiculous as this may seem, actually it is really useful.
Life is and will always be better writing your own Makefiles. It's literally so easy. I do not get the distaste. Cmake is arcane magic. Bazel is practically written in runes. Makefile is a just a glorified build script, but where you don't have to use a bunch of if statements to avoid building everything each time.
really anyone worth their salt should write perl code to generate makefiles depending on the phase of the moon and if you sacrificed a $chicken, a @chicken, or a %chicken at runtime.
It's one of those massively elegant concepts of the past that's become unfashionable to learn pretty much just do to time and ubiquity.
That works until you need to support Visual Studio or Xcode. Then you either maintain their stuff manually too, or you get CMake to generate all three. I don’t love it but it solves the problem it’s meant to solve. The issue is people using it when they don’t need to.
Xcode implies MacOS, you can use make there too, just beware that some commandline tools take different arguments on BSDs.
I'm not familiar with either why can't you use Make with VS or Xcode? Can you not set them up to have whatever build bind call Make ?
You can build with mingw64 built with msvc and use more or less the same Makefile. As for Xcode... well, there's not really a good reason to support Mac. On principle I wouldn't even try
Manual makefiles don't scale though and you end up needing some other bootstrap framework pretty quick.
Thanks for the laugh.
That was also my experience, but it ended when I stopped using cmake.
I'm not mad at anyone for using cmake, but I consider myself blessed on each day that I don't have to collaborate with them (on cmake).
Which is weird, because someone will have to pry a Makefile from my cold dead hands, someday.
In case anyone wants to know the actual answer, it stands for cross platform make, and my understanding is that it’s for generating build project files for various development environments. For instance, with one CMake file you can generate a Visual Studio Solution file, an XCode project file, a Makefile, etc. Several IDEs are also able to read CMake files directly.
This thread is wild, I'm here like "cmake is by far the simplest way to cross compile to ARM and x86, with and without Cuda build targets" and y'all are talking about IDEs for some reason.
Professional CMake: A Practical Guide by Craig Scott is an excellent guide to modern cmake usage. Well worth the $30 if you need to build, maintain, or modify a CMake project.
This was solved by moving to bazel. It's a bit more verbose and resource heavy, but the language is sane and how you structure your build code makes a lot of sense
Based on this comment*, I'll migrate a large project to bazel now. I'll report how it goes.
Good luck, from my experience with bazel it may go smooth if you have someone who can into bazel to help you, and you create the project from scratch to then maintain small changes. Then there was my attempt to migrate an existing Java project to bazel without external help that failed hard (maybe the situation improved from 2021).
Not sure about java, but I migrated a fairly big c++ project knowing only the basics of Bazel. Disclaimer: I know the codebase extremely well and we don't have any third party dependencies and the code is c++ and some python generators, validators, etc (which fits the bill for Bazel perfectly)
What I found super hard were toolchains. It's very verbose to define a toolchain
cmake debugger
I use this one in vscodium https://open-vsx.org/vscode/item?itemName=ms-vscode.cmake-tools
I never finished reading my CMake book that weights about two kilos. It's now outdated, except for the core concepts.
Imo just use something else. If your build system is really simple just write the Makefiles yourself. If the build system tho needs to be really complex I would use something like meson or scons (Having worked on some gigantic fully GNU make build systems it can get pretty out of hand).
This is all a personal preference thing but cmake in my experience is really non intuitive and a pain to debug. I know it works for a lot of people but I definitely prefer particularly like scons since its python I have a bit easier time understanding what's happening.
If you really need to use cmake, use a debugger like another user commented. There's also a GNU make debugger in case you need to debug makefiles
I forgot to assign a variable, now it crashes %5 of the time. It's wild how c doesn't default variables to null or something.
default variables to null or something
That is such a bad idea. Better to have the compiler warn you about it like in Rust, or have the linter / IDE highlight it.
If it's going to compile without any warnings I'd rather the app crash rather than continue execution with rogue values as it does now.
There is so much room for things like corrupted files or undocumented behavior until it crashes. Without the compiler babysitting you it's a lot easier to find broken variables when they don't point to garbage.
Just enable all compiler warnings (and disable the ones you don't care about), a good C compiler can tell you about using unassigned variables.
Still learning, they just covered compiler flags in cs. They didn't go into detail yet though.
Edit: I've used python for years and they have something equally dumb. You can have a function in a massive application that is broken and the moment it's called, the application crashes.
At any other point the application will just run as if nothing is wrong even though python evaluates everything at runtime. I'm sure they can't do much because the initial launch would be slow.
C does exactly what you tell it, no more. Why waste cycles setting a variable to a zero state when a correct program will set it to whatever initial state it expects? It is not user friendly, but it is performant.
Except that this is wrong. C is free to do all kinds of things you didn't ask it to, and will often initialize your variables without you writing it.
Machine code would be a better example of what he's talking about imo. Not an expert or anything of course.
Odds are that your computer doesn't export any language where it will do exactly as you say (amd64 machine code certainly won't execute exactly as written). And how much difference it makes varies from one language to another.
But the specific example from the OP, of uninitialized variables, is one of those cases where the C spec famously goes completely out of line and says your code can do whatever, run with a random value, fail, initialize it, format your hard drive, make a transaction on your bank account... whatever.
Coding in C but if I don't initialize a Variable the compiler formats my drive! (Not Clickbait)
It wouldn't be that much processing compared to the rest of the app. It would lot more efficient than running an effectively infinite loop or arithmetic on an arbitrarily large number as a result of an unsigned variables.