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
An Introduction to Modern CMake
21–30 of 43 posts
Re: An Introduction to Modern CMake
#22Re: An Introduction to Modern CMake
#23This 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…
Re: An Introduction to Modern CMake
#24Re: An Introduction to Modern CMake
#25I sure wish Qmake had won over CMake.
Re: An Introduction to Modern CMake
#26Nice 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…
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.
Re: An Introduction to Modern CMake
#27Re: An Introduction to Modern CMake
#28Or we can also try xmake. https://xmake.io/
Re: An Introduction to Modern CMake
#29Re: An Introduction to Modern CMake
#30I sure wish Qmake had won over CMake.