Live data from Hacker News

CMake Part 1 – The Dark Arts

blog.feabhas.com

11–20 of 70 posts

Re: CMake Part 1 – The Dark Arts

#11
TFA talks about CMake being widely used in embedded. This seems to be a difference between Europe and the US. It feels like every single embedded project I've encountered in Europe in the last decade uses CMake, and I've never seen an embedded project in the US that uses it.

It's the single biggest difference I've noticed. C++ is certainly more popular in Europe, but you see plenty of C projects in Europe and plenty of C++ projects in the US.

Re: CMake Part 1 – The Dark Arts

#12
post #11

TFA talks about CMake being widely used in embedded. This seems to be a difference between Europe and the US. It feels like every single embedded project I've encountered in Europe in the last decade uses CMake, and I've never seen an embedded project in the US that uses it. It's the single biggest difference I've noticed. C++ is certainly more popular in Europe, but you see plenty of C projects in Europe and plenty…

What do embedded projects in US use instead?

Re: CMake Part 1 – The Dark Arts

#13
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-friendly and well designed in C would feel incongruous with the rest of the ecosystem.

Re: CMake Part 1 – The Dark Arts

#14
post #12
post #11

TFA talks about CMake being widely used in embedded. This seems to be a difference between Europe and the US. It feels like every single embedded project I've encountered in Europe in the last decade uses CMake, and I've never seen an embedded project in the US that uses it. It's the single biggest difference I've noticed. C++ is certainly more popular in Europe, but you see plenty of C projects in Europe and plenty…

What do embedded projects in US use instead?

Plain ol' makefiles?

Re: CMake Part 1 – The Dark Arts

#15
post #12
post #11

TFA talks about CMake being widely used in embedded. This seems to be a difference between Europe and the US. It feels like every single embedded project I've encountered in Europe in the last decade uses CMake, and I've never seen an embedded project in the US that uses it. It's the single biggest difference I've noticed. C++ is certainly more popular in Europe, but you see plenty of C projects in Europe and plenty…

What do embedded projects in US use instead?

Some flavor of make (gnu and nmake are the two most common I've seen) usually wrapped with scripts written in perl/python/bash/.bat

Re: CMake Part 1 – The Dark Arts

#16
post #9

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…

I've been burnt by that convention pretty regularly: (1) build automatically scans and adds all files in a directory (2) I write a quick script foo.py in the directory to check something (3) Boom, binary contains foo.py I try to manually enumerate all files whenever I touch a build file.

A better solution is to a checkout of your build, then you wont have foo.py and you can be sure you haven't missed anything.

Re: CMake Part 1 – The Dark Arts

#17

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…

> CMake is a pretty nice tool It's pretty powerful. It'd be pretty nice if it didn't have such a god awful DSL.

Frankly, with the inception of modern CMake over a decade ago, the only reason anyone has to stray out of cmake's DSL happy path, comprised of all the tried and true declarative bits, is whether

a) they have to do a very niche/specialized/extremely custom extension to CMake, or

b) they have no idea what they are doing.

More often than not, b) is the case.

Re: CMake Part 1 – The Dark Arts

#18
post #8

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

I disagree, to the point I honestly doubt you are not trolling, specially taking into account how you decided to rank "the IDE" between autotools and handwritten makefiles, which makes absolutely no sense at all either way you look at it.

It's also dumbfounding how Bazel is ranked so high when it doesn't even support integrating system libraries as part of it's happy path.

The main reason why CMake, with all it's flaws, is the undisputed build system for c and C++ projects is the uncomfortable fact that all other alternatives are awful in comparison, even and specially in very basic happy path scenarios such as putting together a lib that any user can pick whether its static of shared and install it in the system folder or anywhere without even bothering with which compiler tool chain you're using. In CMake, anyone can get a complete project up and running with less than a dozen lines of code, and that project will assuredly work on multiple OSes as-is.

You'd be hard pressed to find another C++ build system that comes close to doing the same.

Re: CMake Part 1 – The Dark Arts

#19
post #11

TFA talks about CMake being widely used in embedded. This seems to be a difference between Europe and the US. It feels like every single embedded project I've encountered in Europe in the last decade uses CMake, and I've never seen an embedded project in the US that uses it. It's the single biggest difference I've noticed. C++ is certainly more popular in Europe, but you see plenty of C projects in Europe and plenty…

It is debatable how embeddable that is, in any case, official build system for NDK is CMake (ndk-build is kept around for backwards compatibility purposes), so no one doing US projects stuffing Android in places that don't look like phones?

Or GUIs on medical devices using Qt?

Cause there are some, so I would expect US companies to also having a go at it.

Re: CMake Part 1 – The Dark Arts

#20
post #8

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

Crazy, I'd definitely use CMake above autotools (does not even work natively on windows LOL), handwritten makefiles (not supporting filenames with spaces in 2021 LOL), "the IDE" (do you even do cross-platform?).

I'd use Bazel but afaik it mostly uses a rebuild-the-world approach.. I'm already getting flak from Linux distros maintainers because I use some vendored header-only libraries and not system ones so I don't see how that is even supposed to work.

Post reply on HN