![]() * 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. Implement a few functions and you'll quickly have something workable. It was an absolute nightmare I don't recommend to anyone, but not for any of the reasons you'd imagine. I've built and maintained a generator for one of those vendor-specific eclipse IDEs. 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. 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. What they use now doesn't seem to be very easy to re-use. 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. 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. My pet peeve is, it seems like nobody does that. 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.ĬMake does have a nice way to add support for a new IDE or compiler in a modular way you write a "generator": Unfortunately, the embedded development space is a messy hodge-podge of IDEs. 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.ĬMake is used a lot in embedded development with large or cross-platform projects, like an RTOS or the famous ESP-IDF. In particular it fails to mention that a target is is not the same thing as a file in cmake, and that this has implications that are likely to be surprising to make experts. And it barely tells you how to do this at all (this being a topic I've actually struggled with in the past). What docs there are on creating a custom target are buried in two paragraphs inside a subsection named "Running a command at build time". Cmake understands your compiler better than you do. But what is it going to do with that stuff? It's all just magic. Now, how do I do that in cmake? It's almost not even here! It's all about C++ files and libraries and how to define variables and write functions and include other cmake files. ![]() Now, there are implications to learn, but that is the model, and it's obvious: make runs programs to create files when the stuff needed to create the file changes. 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 newer than the target". It explains in detail how to do obvious stuff but has nothing to say about what the execution model behind the syntax is. This has the same kind of infuriating quality that most cmake documentation does.
0 Comments
Leave a Reply. |