It always pisses me off when I have to build a GitHub project or something with cmake. Just use a Makefile and autoconf, dammit.
Everything You Never Wanted to Know About CMake
61–70 of 91 posts
Re: Everything You Never Wanted to Know About CMake
#62Earlier quoted context omitted.
This idea of having a "front-end" build system and a "back-end" build system is a bit of a throw-back. It is better to integrate the two for better optimization and configuration management.
I don't know if that's true. Don't you gain all the usual advantages of decoupling systems (clarifying responsibilities, documentation, independent growth and optimization, interoperability with other programs, easier testing) if you are forced to define a clear interface between the two? It certainly seems like specifying a build process and performing a build process are two distinct things.
They are different stages of the build, yes (although in a hermetic system you could in theory run the build process in parallel with the configure step for different targets). The challenge is integration. Things are much simpler when you ship the two programs together since they need to be compatible in terms of folder structures etc. It is also nice to keep things in memory sometimes. In other words, I think they should be different modules of one build system, rather than completely different programs.
To your point, integration will allow the two to be iterated upon faster, since changes can be more easily released together.
Re: Everything You Never Wanted to Know About CMake
#63Is there a good way to debug CMake build rules (especially in the presence of add_custom_command and friends)? I've got a case which builds differently in Make vs Visual Studio---in VS, dependencies get messed up and some files don't even get built at all (and then the build fails later on because those files are missing). I can't for the life of me figure out how to debug this, it's absolutely infuriating.
Re: Everything You Never Wanted to Know About CMake
#64CMake is awful, and the fact that the C++ community seems to be settling around it will be a massive disadvantage in the long run. Why do you think so many WASM examples use Rust? It's because Cargo is a sane build system that makes cross-compilation easy. Issues with CMake: - The DSL is not very good. It needs proper functions, for one. - Non-hermetic builds (also mentioned in this thread) - No ability to easily que…
My only experience using Bazel involved discovering that build instructions from August have already been broken by deprecations. It was not a good first impression.
Re: Everything You Never Wanted to Know About CMake
#65Earlier quoted context omitted.
In my experience, this is usually handled with a combination of source control and containers(Docker, but more commonly just a chroot image).
I'm not sure how source control is connected. Normally, I want hermetic builds whether or not the files I am building are checked into source control yet.
Well if you want repeatability, I'm assuming that means over some long timeframe, which means you need a way to get the code as it was at some point.
You then need to build that code using a consistent set of tools and libraries, which is where the chroot comes in.
Re: Everything You Never Wanted to Know About CMake
#66Is there a good way to debug CMake build rules (especially in the presence of add_custom_command and friends)? I've got a case which builds differently in Make vs Visual Studio---in VS, dependencies get messed up and some files don't even get built at all (and then the build fails later on because those files are missing). I can't for the life of me figure out how to debug this, it's absolutely infuriating.
cmake --trace and --trace-expand maybe. Because a typical build of a sizable project runs order of magnitude 10k lines of CMake script, you can just dump it all and search. Worked pretty well for me a couple of times.
Re: Everything You Never Wanted to Know About CMake
#67I want to upvote this for solid info, but I want to flag it so fewer people have to know about CMake. It blows my mind that experienced software developers would develop yet another pseudo-language DSL vs creating a portable library (python, java, go, whatever) that has a sensible interface.
CMake is very powerful but unlike most things there’s no underlying principle or theory that when you grasp it, everything just clicks, and you also can transfer the knowledge to other languages. It’s just a matter of memorising lots of tricks and special cases.
This is mostly true about the language but not about the way build artifacts and their dependencies work. That part is pretty solid.
Re: Everything You Never Wanted to Know About CMake
#68I want to upvote this for solid info, but I want to flag it so fewer people have to know about CMake. It blows my mind that experienced software developers would develop yet another pseudo-language DSL vs creating a portable library (python, java, go, whatever) that has a sensible interface.
I'm not sure what you mean. If for whatever reason I need to set up a big C/C++ application so that it can compile on diverse systems, CMake is one of my best bets for getting that to happen. If anyone would like to suggest a better option I would gladly switch, but as it stands I think CMake is pretty useful to know about.
Meson?
Re: Everything You Never Wanted to Know About CMake
#69Earlier quoted context omitted.
Comparing anything against plain Makefiles is a really low bar. Makefiles have been around since 1976. I think the hate for CMake comes from other directions entirely. The CMake scripting language is especially bad. Out-of-source builds were never really that hard in the first place. I think people hate CMake either because they were doing something slightly more unusual than CMake tolerated, or because they hated CM…
I wonder how Makefiles got such a bad reputation. After decades of reading how bad Makefiles are, I recently tried writing one for a moderately complex build, just for fun. I was pleasantly surprised: make is very fast, it's well-documented, and the execution model is so simple that I found it very easy to figure out how to script the things I needed to do. I'm not saying it's great, but there are a lot worse build s…
How about significant whitespace with a difference between tabs and spaces, for starters?
Re: Everything You Never Wanted to Know About CMake
#70Earlier quoted context omitted.
Meson itself though is just a meta build system, it's used in combination with Ninja that does the actual build. Ninja is quite fast. But they claim at least that they are working on making Meson itself fast too.
This idea of having a "front-end" build system and a "back-end" build system is a bit of a throw-back. It is better to integrate the two for better optimization and configuration management.
Better integrate may be, but not merge into one. Since super optimized build systems also increase complexity of their usage. So the idea is to have user friendly front end, which produces complex input for very fast backend.
Ninja view their build idea as "assembly like". While assembly surely allows you producing very fast results, it's not easy to use at all, if you are using it directly.