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

CMake Part 1 – The Dark Arts

blog.feabhas.com

Post reply on HN
Print view View original

31–40 of 70 posts

Re: CMake Part 1 – The Dark Arts

#31

Post by wheybags »

timeinput wrote: post #2

This is a pretty nice article. CMake is a pretty nice tool and this is a good article for its good parts. One thing I *hate* with build systems is having to enumerate all of my files. I have a file system. It knows about the files. If I organize my code appropriately (say a lib, inc, and prog directory) the organization says how to build the source code. I often make my build system support finding all the files in d…

They recently added a CONFIGURE_DEPENDS flag to file(GLOB...), which will automatically rebuild the file list when new files are added.

Re: CMake Part 1 – The Dark Arts

#32

Post by h_anna_h »

yakubin wrote: post #28
h_anna_h wrote: post #23

Earlier quoted context omitted.

I think I had the best experience with Meson/Ninja so far. I am also interested in using Nix for building. As for Cargo, I did not like how it recompiled all dependencies when I changed a warning flag on my project. I also found it unusable because it provided no way to check for the hash or signature of the dependencies that it downloads. I don't think that I have ever been able to successfully compile a project tha…

> As for Cargo, [...] I also found it unusable because it provided no way to check for the hash or signature of the dependencies that it downloads. Afaik Cargo does it out of the box, based on Cargo.lock. UPDATE: This doc page seems to confirm that: https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lo... >

I did not know about rev, thanks. Though, since there is no way to specify a signature you are forced to use potentially outdated packages.

Re: CMake Part 1 – The Dark Arts

#33

Post by maccard »

enriquto wrote: post #10
zelly wrote: post #8

CMake is legitimately the worst software I've ever used. cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake

handwritten makefiles have a certain kind of deep, pure beauty if you are in the right mindset

If you have a project that you don't want to embed in another project, doesn't build on windows, doesn't have any spaces in filenames, and do'nt mind manually ordering dependencies wrt the quirks of your toolchain.

Re: CMake Part 1 – The Dark Arts

#34

Post by maccard »

enriquto wrote: post #22
rualca wrote: post #21

Earlier quoted context omitted.

Handwritten makefiles can be the best option on the table in scenarios not involving a lot of boilerplate code or having to do any platform check at all. Once you stray out of that niche, anyone is better suited if they just automate all the boilerplate generation and compiler checks. And that's what CMake does.

Maybe it wasn't your intention, but your comment is the most scathing critique I've ever read of cmake. Boilerplate code and "compiler checks" are strongly negative anti-patterns. Maybe the worst in programming. That cmake makes it easy to do these awful things just shows how evil it is! People: write simple, portable code!

> People: write simple, portable code!

How do you memory map a file, or spawn a subprocess simply and portably? Every way that I've seen it done that doesn't hand the logic off to the build system is an unmaintainable error prone mess.

Re: CMake Part 1 – The Dark Arts

#35

Post by yakubin »

h_anna_h wrote: post #32
yakubin wrote: post #28

Earlier quoted context omitted.

> As for Cargo, [...] I also found it unusable because it provided no way to check for the hash or signature of the dependencies that it downloads. Afaik Cargo does it out of the box, based on Cargo.lock. UPDATE: This doc page seems to confirm that: https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lo... >

I did not know about rev, thanks. Though, since there is no way to specify a signature you are forced to use potentially outdated packages.

"cargo update" will update the packages along with Cargo.lock content. As for not updating them without a manual trigger, I consider it a feature, but I guess it's a matter of opinion.

Re: CMake Part 1 – The Dark Arts

#36

Post by maccard »

h_anna_h wrote: post #23
zelly wrote: post #8

CMake is legitimately the worst software I've ever used. cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake

I think I had the best experience with Meson/Ninja so far. I am also interested in using Nix for building. As for Cargo, I did not like how it recompiled all dependencies when I changed a warning flag on my project. I also found it unusable because it provided no way to check for the hash or signature of the dependencies that it downloads. I don't think that I have ever been able to successfully compile a project tha…

> I think I had the best experience with Meson/Ninja so far. cmake lets you use ninja as the backend if that's your cup of tea. You can even set it to the default generator , by setting the CMAKE_GENERATOR environment variable to ninja. (I have no meson experience, so can't compare it).

> I don't think that I have ever been able to successfully compile a project that uses CMake.

That's quite the statement. In practice, I've found cmake -h. -Bbuild && cmake --build build

to work about 90% of the time. Far more luck than I've had with autotools.

> Its code is horrifying too, for example:

1) I'm sure I could find some horriffic code in meson too if I went digging. 2) The alternative to this is you having to write something equivalent in your own code, meaning that in my code I don't need to do stuff like [0] in my code to detect features; my build system handles it for me. 3) CMake supports more platforms and targets than I've ever seen in my life, and likely supports more compilers than are necessary. that's a blessing and a curse, but it means that if I write simple program to run on some crufty microcontroller with a bastardised gcc toolchain from the 90s, it's fairly likely that cmake supports it out of the box. Code like that is the price to pay for that level of support.

[0] https://github.com/boostorg/beast/blob/b7344b0d501f23f763a76...

Re: CMake Part 1 – The Dark Arts

#37

Post by humanrebar »

wheybags wrote: post #31
timeinput wrote: post #2

This is a pretty nice article. CMake is a pretty nice tool and this is a good article for its good parts. One thing I *hate* with build systems is having to enumerate all of my files. I have a file system. It knows about the files. If I organize my code appropriately (say a lib, inc, and prog directory) the organization says how to build the source code. I often make my build system support finding all the files in d…

They recently added a CONFIGURE_DEPENDS flag to file(GLOB...), which will automatically rebuild the file list when new files are added.

...which comes with a cost (extra reconfiguration of the project), but it 's worth it for many projects.

Re: CMake Part 1 – The Dark Arts

#38

Post by user-the-name »

maccard wrote: post #33
enriquto wrote: post #10

Earlier quoted context omitted.

handwritten makefiles have a certain kind of deep, pure beauty if you are in the right mindset

If you have a project that you don't want to embed in another project, doesn't build on windows, doesn't have any spaces in filenames, and do'nt mind manually ordering dependencies wrt the quirks of your toolchain.

I don't see how make is at a disadvantage with relation to other tools with embedding. No build tool is easily embedded in a project that uses a different build tool.

And I've used make on Windows for years and years, so not sure why that is a problem?

Re: CMake Part 1 – The Dark Arts

#39

Post by volta83 »

AlotOfReading wrote: post #13
zelly wrote: post #8

CMake is legitimately the worst software I've ever used. cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake

I used to agree, but I eventually needed to add support in CMake for a particular IDE and got far too familiar with it. It's easy to debug and the syntax could be worse. Whoever came up with the list representation needs to be arrested though. It might be stockholm syndrome, but I'd rank it worse than Meson and better than Makefiles. Autotools can go die in a fire. Cargo is wonderful, but having something that user-f…

> Cargo is wonderful, but having something that user-friendly and well designed in C would feel incongruous with the rest of the ecosystem.

You really did say this.

Cargo does get some flak from C and C++ build systems. It is definitely not perfect, but which build system is?

The coolest thing about cargo is that it can be and is significantly improved over time. The whole dependency resolution was improved to resolve some long standing issues lately in a backward compatible way and that’s just astounding that they managed to ship this.

Do I like cargo? No. Do I like it better than CMake Meson Bazel Auto tools and make files? Hell yeah, by far, I’d rather get shot than go back to cmake or Auto tools .

Re: CMake Part 1 – The Dark Arts

#40

Post by humanrebar »

rualca wrote: post #30

I wish all the CMake haters invested a fraction of their energy putting together a tool that they feel was superior to CMake, or at least a better alternatice. CMake has been around for a few decades, and perhaps a dozen alternative makefile generators and higher-level build systems already popped up, but still each and every single one of them failed miserably in gaining any traction. Why is that, given that CMake i…

Build systems are harder and more complicated and messier than user of build systems understand.

Say a group of smart engineers start designing the perfect build systesm.

Usually there is some sort of design constraint added for correctness that works for, say, 99% of projects, which seems like a good tradeoff. Until it turns out that openssl is in that other 1%.

Or maybe the build system assumes everything can build from source, which maybe works for 90% of cases, forgetting that proprietary vendors often ship prebuilt binaries.

Or maybe the build system is written in , which means , written in C, now needs a different build system. Also, doesn't have a compatible version of available.

Or maybe the build system requires a lot of boilerplate to support the typical project structure of . Instead of having verbose build recipes in hundreds, thousands, or tens of thousands of projects, just sticks with its legacy custom build scripts.

The fact of the matter, CMake is pretty good. It lets you do basically anything you need to. It has basically no dependencies to build and use it, so it works anywhere. And it has extensibility that's actually fairly rare in build systems.

Anyway, my theory is folks see the downsides of some tradeoffs CMake made (awkward basic DSL) without appreciating the upsides (available everywhere), especially because they don't realize "works on my project and box" doesn't cut it for maintaining projects in the C and C++ ecosystem. I'll be bold enough to predict that the build systems of Go and Rust will be just as complicated if they ever need to start supporting things like juggling BLAS versions.

Post reply on HN