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.
CMake Part 1 – The Dark Arts
11–20 of 70 posts
Re: CMake Part 1 – The Dark Arts
#12TFA 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…
Re: CMake Part 1 – The Dark Arts
#13CMake is legitimately the worst software I've ever used. cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake
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
#14TFA 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
#15TFA 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
#16This 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.
Re: CMake Part 1 – The Dark Arts
#17This 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.
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
#18CMake is legitimately the worst software I've ever used. cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake
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
#19TFA 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…
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
#20CMake is legitimately the worst software I've ever used. cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake
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.