Live data from Hacker News

An Introduction to Modern CMake

cliutils.gitlab.io

21–30 of 43 posts

Re: An Introduction to Modern CMake

#21
post #8

Earlier quoted context omitted.

Unfortunately even if you're starting a new project chances are that your dependencies are using cmake and they expect their dependencies to use cmake... in the end of the day you spend a lot of time fixing the upstream projects build files. More than that CMake at this point is the ""standard"" and there are many others with a similar share of the market and selling points, it makes it harder to pick one that is not…

Meson supports CMake subprojects: https://mesonbuild.com/CMake-module.html#cmake-subprojects

CMake subprojects was far from reliable last time I tested it. But this might also have been due to meson targeting unreleased CMake versions...

Re: An Introduction to Modern CMake

#23
post #14

This has the same kind of infuriating quality that most cmake documentation does. It explains in detail how to do obvious stuff but has nothing to say about what the execution model behind the syntax is. I mean, if you learn classic make, one of the very first things you learn is "this is a target; it's just a file; the stuff on the right are dependencies; the commands below will be run whenever the dependencies are…

I'm glad I'm not the only one finding cmake's "magic" approach to software building totally unhelpful, and more on the problem rather than solution side of things. You know there's gone something out of hand if your very meta build tool's build itself takes much longer than the project you wanted to build in the first place.

Re: An Introduction to Modern CMake

#24
What's wrong with just a real language as a build system? Speaking for Scala, everyone just uses sbt, which is just Scala. Nothing special about it. I'm not saying you should use Scala to compile your C project, but maybe we could settle on some Lisp dialect or something for compilation, regardless of the language? That would seem ideal to me. Programmers in general have this problem of creating non-turing complete shit to solve problems that require turing completeness. And sometimes it gets worse: first a non turing complete language is created and then when it finally becomes necessary, some loops and shit are grafted on (or a shell script is called in the middle). It's a mess.

Re: An Introduction to Modern CMake

#26

Nice to see a CMake guide here, but I don't see any discussion of generators at a cursory glance, even in the "IDEs" section. CMake is used a lot in embedded development with large or cross-platform projects, like an RTOS or the famous ESP-IDF. Unfortunately, the embedded development space is a messy hodge-podge of IDEs. There are shiny commercial ones like Keil which support most kinds of devices, but most vendors a…

I think the kind of embedded development you are doing is not the same as I am doing.

Where I work we were looking at CMake and were "forced" to start learning it when we embarked on a pilot project that needed to compile WebKit for several embedded platforms (the kind that can usefully use WebKit to display something). There were at least 3 ways to build WebKit but someone before me chose CMake.

Fast-forward to today, and our main build system is actually a wrapper around buildroot, which can use CMake projects for the packages if desired. We use CMake for one of our Linux kernel modules and for our middleware. We don't use generators, or to be precise we only use the Unix Makefile generator. For the CMake projects we adapt the compilers of our various platforms by using toolchain files, which we write ourselves. Toolchain files are chosen by an option to the initial CMake command and primarily describe the location and preferred settings of the toolchain's tools.

There is a temptation, a very practical temptation, to merge toolchain considerations with the ways targets vary, and handle both subjects with the toolchain file. We have resisted that temptation across over a dozen target platforms. We create platform files separately and we have devised a convention for specifying which one to use.

Our developers all have their own IDE/non-IDE ways of working with the source code and the build system has not asked to integrate in any way with that.

A lot of our developers work primarily within the middleware, and we have a documented way to make that work easy. Others have to cope with buildroot as much as with the build system of the buildroot package they are working on, and that is not refined yet.

Post reply on HN