4 ms·

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 d

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 also provide a free Eclipse-based option which targets their chips, and there are usually flavors of GCC for the adventurous. CMake does have a nice way to add support for a new IDE or compiler in a modular way; you write a "generator": https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html https://cmake.org/cmake/help/latest/manual/cmake-generators.... My pet peeve is, it seems like nobody does that. Instead, they try to re-write all of the logic which generates build files either using CMake's internal logic, or one-off scripts which get called from CMake. If (for example) Espressif provided a CMake generator for their style of `xtensa-elf-gcc` Makefiles, everybody could use that to quickly add build support for ESP32s to their CMake systems. What they use now doesn't seem to be very easy to re-use. Ditto for companies like ST/TI/Microchip/etc; if they provided CMake generators for their Eclipse IDEs, people wouldn't have to keep re-inventing the wheel and making it square-shaped. It makes me dread using embedded libraries that use CMake-based build systems, even though I really like CMake as a cross-platform build system.

tjoff 7y ago
Not sure you want to tie yourself to a buggy inconsistent IDE and force that upon all developers. Why wouldn't you do it with CMakes internal logic? Isn't that the point, especially since it is cross-platform.
- leggomylibro 7y ago
  I don't think I understand the question. Generators are CMake's way of creating IDE-specific build files, and I wish that people used them instead of writing their own scripts to create IDE-specific build files from CMake. Generators are there so that you don't get tied to any one IDE; you select a different generator when you want to use a different IDE or compiler, but your CMake logic can largely stay the same besides that. If I were a cynic, I would say that the vendors probably don't mind it being difficult to interoperate with their competitors' products, so there's little incentive to support things like that.
cardiffspaceman 7y ago
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.
AlotOfReading 7y ago
I've built and maintained a generator for one of those vendor-specific eclipse IDEs. It was an absolute nightmare I don't recommend to anyone, but not for any of the reasons you'd imagine. CMake itself is easy to build / read. Implement a few functions and you'll quickly have something workable. The issues came from elsewhere: * None of the graphical CMake tools allow you to select the CMake binary, so you'd get users using the wrong binary and not seeing the generator mentioned in docs. * When things break elsewhere, it's "your responsibility" to fix it in the generator. People put meaningless, nonsensical junk in their CMake files and expect it to output something that builds. Doesn't matter that the build script or the IDE are fundamentally broken, people just want the output so they can get back to their work. They don't want to yak shave. * Vendor tooling code quality is somehow even worse than the actual product they provide. Dropping every 4096th character from stdin? Why not? Not generating debug info for files with uppercase letters in the filename? Sure. I won't name names, but they're a billion dollar EDA vendor whose initials are MG. Avoid CMake generators like the plague unless you want to spend the next bit of your life debugging your vendor tools and supporting every workflow quirk your coworkers have.
- leggomylibro 7y ago
  Interesting perspective, thanks for sharing your experience! That doesn't sound too much worse than working with modern CMake build systems, but it also doesn't sound mucn better. >People put meaningless, nonsensical junk in their CMake files and expect it to output something that builds. Doesn't matter that the build script or the IDE are fundamentally broken, people just want the output so they can get back to their work. When you put it that way, maybe that's my real pet peeve with CMake in big projects :)

tjoff 7y ago

Not sure you want to tie yourself to a buggy inconsistent IDE and force that upon all developers. Why wouldn't you do it with CMakes internal logic? Isn't that the point, especially since it is cross-platform.

leggomylibro 7y ago
I don't think I understand the question. Generators are CMake's way of creating IDE-specific build files, and I wish that people used them instead of writing their own scripts to create IDE-specific build files from CMake. Generators are there so that you don't get tied to any one IDE; you select a different generator when you want to use a different IDE or compiler, but your CMake logic can largely stay the same besides that. If I were a cynic, I would say that the vendors probably don't mind it being difficult to interoperate with their competitors' products, so there's little incentive to support things like that.

cardiffspaceman 7y ago

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.

AlotOfReading 7y ago

I've built and maintained a generator for one of those vendor-specific eclipse IDEs. It was an absolute nightmare I don't recommend to anyone, but not for any of the reasons you'd imagine. CMake itself is easy to build / read. Implement a few functions and you'll quickly have something workable. The issues came from elsewhere: * None of the graphical CMake tools allow you to select the CMake binary, so you'd get users using the wrong binary and not seeing the generator mentioned in docs. * When things break elsewhere, it's "your responsibility" to fix it in the generator. People put meaningless, nonsensical junk in their CMake files and expect it to output something that builds. Doesn't matter that the build script or the IDE are fundamentally broken, people just want the output so they can get back to their work. They don't want to yak shave. * Vendor tooling code quality is somehow even worse than the actual product they provide. Dropping every 4096th character from stdin? Why not? Not generating debug info for files with uppercase letters in the filename? Sure. I won't name names, but they're a billion dollar EDA vendor whose initials are MG. Avoid CMake generators like the plague unless you want to spend the next bit of your life debugging your vendor tools and supporting every workflow quirk your coworkers have.

leggomylibro 7y ago
Interesting perspective, thanks for sharing your experience! That doesn't sound too much worse than working with modern CMake build systems, but it also doesn't sound mucn better. >People put meaningless, nonsensical junk in their CMake files and expect it to output something that builds. Doesn't matter that the build script or the IDE are fundamentally broken, people just want the output so they can get back to their work. When you put it that way, maybe that's my real pet peeve with CMake in big projects :)