Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything You Never Wanted to Know About CMake

izzys.casa

Post reply on HN
Print view View original

71–80 of 91 posts

Re: Everything You Never Wanted to Know About CMake

#71

Post by Teknoman117 »

dfgdghdf wrote: post #51

CMake 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…

Cargo (and Rust tooling in general) still have an annoying design flaw in my mind -> they all pretend that system package managers don’t exist.

Admittedly with rust not having an ABI you’d still have to rebuild all the packages whenever the compiler was updated, but I’d like to see rustup support toolchains installed to the system.

Re: Everything You Never Wanted to Know About CMake

#73

Post by klodolph »

01100011 wrote: post #65
klodolph wrote: post #50

Earlier quoted context omitted.

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.

Repeatability definitely does not mean some long time frame, it's over any time frame. Short time frames have the largest impact, because it allows you to use a shared cache for build products.

One big chroot around your whole build system isn't enough, you can run into nondeterminism problems due to relative ordering of different build steps during execution. This is why it's nice that the new build systems make each individual step hermetic, because you can make a separate chroot for each individual step (Bazel executes each build step in a separate sandbox).

This allows you to cache all intermediate results, share the cache, and get the same results both for clean and incremental builds, repeatably. It's also easier to remove nondeterminism from individual build steps rather than looking at the whole build.

Re: Everything You Never Wanted to Know About CMake

#74

Post by Rusky »

Teknoman117 wrote: post #71
dfgdghdf wrote: post #51

CMake 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…

Cargo (and Rust tooling in general) still have an annoying design flaw in my mind -> they all pretend that system package managers don’t exist. Admittedly with rust not having an ABI you’d still have to rebuild all the packages whenever the compiler was updated, but I’d like to see rustup support toolchains installed to the system.

This is a rustup issue, not a Cargo issue. You can use a system-installed Cargo/rustc just fine.

Re: Everything You Never Wanted to Know About CMake

#75

Post by stefan_ »

dfgdghdf wrote: post #53
shmerl wrote: post #52

Earlier quoted context omitted.

Many C/C++ projects are switching to Meson these days. Mesa for example.

My experience with Meson is that it is much better designed than CMake but very slow.

I've used Meson to build mesa, as complex a project as you are going to find/make, and as entirely expected, from invocation to Ninja build files it's.. maybe a second?

Safe to say, if you are building any C++ specifically, that is entirely and utterly negligible.

Re: Everything You Never Wanted to Know About CMake

#76

Post by shmerl »

stefan_ wrote: post #75
dfgdghdf wrote: post #53

Earlier quoted context omitted.

My experience with Meson is that it is much better designed than CMake but very slow.

I've used Meson to build mesa, as complex a project as you are going to find/make, and as entirely expected, from invocation to Ninja build files it's.. maybe a second? Safe to say, if you are building any C++ specifically, that is entirely and utterly negligible.

Mesa surely builds a lot faster with Meson+ninja than with autotools.

Re: Everything You Never Wanted to Know About CMake

#77

Post by stefan_ »

ryanianian wrote: post #44

CMake suffers from a lack of conventions. If you want to follow some set of conventions and have one directory for your headers and another for your sources and another for your tests etc you still end up having to write a hundred lines or more of error-proned CMake. As ugly as things like Maven and Gradle are, if you follow all of their conventions they get out of your way. In addition: - no cross-platform way to re…

They recently added a convention: target-based CMake!

Now, because they are switching to what every sane build system was 5 years ago, but over the course of 10s of 3.x versions, your CMake buildfiles are about to explode in complexity and frankly, stupidity. Lots of "does this target exist already because I need to support some older version alongside bleeding edge" and usually, if not, just copy that stuff over from their HEAD.

Everything they touch goes terrible. We just need to stop with like version 3.10, pretend CMake is dead and slap a DEPRECATED warning at the beginning. It's the only way out.

Re: Everything You Never Wanted to Know About CMake

#78

Post by tom_ »

dfgdghdf wrote: post #51

CMake 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…

There's just literally nothing good that can come of calling your product "pants". I don't care if it's amazing! - because I already know that, actually, it isn't, simply on the basis that its authors' judgement is clearly unsound.

Re: Everything You Never Wanted to Know About CMake

#79

Post by jarjoura »

I used Makefile in university and that was simple enough until you needed to do something more complicated and then it started to become unwieldly fast. Back then, GNU was popular and automake/autoconf were attached to every project. If you were building on a Linux system, it worked, but being a Mac user, it always came with gotchas. It was quite a pain to use honestly and required a very deep understanding of it's .m4 design if you wanted to do anything clever.

Cmake seemed to work well, meaning, I could just open the GitHub project and generate an Xcode project file and bam, it just worked. However, agreeing with everyone here, holy hell, trying to start a new project with it, or migrate another project over to it is quite a futile experience.

It has several escape hatches in the weirdest places. Need to pass a conditional compiler flag? Good luck with that exercise. A compiler flag was added from a previous macro and there doesn't seem to be a way to keep it from doing that. I don't know, the whole system seems nice when you don't have to touch the make file, it just works, but I can only imagine the hair splitting effort it took to get that make file in a workable state.

Re: Everything You Never Wanted to Know About CMake

#80

Post by 01100011 »

klodolph wrote: post #73
01100011 wrote: post #65

Earlier quoted context omitted.

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.

Repeatability definitely does not mean some long time frame, it's over any time frame. Short time frames have the largest impact, because it allows you to use a shared cache for build products. One big chroot around your whole build system isn't enough, you can run into nondeterminism problems due to relative ordering of different build steps during execution. This is why it's nice that the new build systems make eac…

Cool, didn't know that. I like the idea of breaking things up into steps.

So you're saying this takes care of race conditions in the build where things may happen out of order even if you have a fixed environment?

Post reply on HN