No more comparing yamls and local cmake-variants! There’s only one single source for build configurations and options. With this, we’re now using those on our Azure DevOps pipelines. The next great thing about CMake Presets is that they can be passed directly to CMake CLI when building. Here’s how the presets for the local tools look like in the template, before being replaced with the correct values for the local configuration: Plus, there are also CMake User Presets which are meant to store “local” configurations that can be based on the official ones or contain entirely new sets. Here’s an example of a couple of our base presets: These json files go into version control and, all the sudden, everything gets updated and goes in sync, auto-magically. In a nutshell: CMake Presets offer centralized storage of build configurations with json files that can inherit from other json files with unlimited levels. With the introduction of CMake Presets feature all this goes way! It was tedious (at best!) to maintain and pretty easy for changes in configurations to go unnoticed and, therefore, not being updated locally by developers. Any changes in the configurations there had to be manually copied over to the respective template, which, in turn, had to be copied by developers (on their machines) to the real cmake-variants.json file, as already explained.īy now, it should be more than clear that all this was far from being practical. This was useful for local builds and, upon any changes in the options, a developer had to copy over those changes from each template to the real cmake-variants.json file.įor the CI-CD pipeline builds (we’re using the awesome Azure DevOps), the build configurations for each target were stored in the Yaml file along with the pipeline configuration. vscode folder and concatenated with the templates for the other targets. This was merely a storage because at that location, CMake couldn’t use it to perform the actual build. Worth mentioning that this was the only available mechanism to deal with these matters when the project was started.Įach target had its own configuration “template” file, stored in the respective folder. Until now the build configurations were stored using cmake-variants.json files. We’ve made a major move last week in our build system and CI-CD pipelines and migrate the build configurations of all our reference and community targets to use these.Īnd what’s so exciting about all this, you may ask… Actually, a lot, I can tell you! Let’s go through it and understand the changes and implications. One of the recent improvements there, was the introduction of CMake Presets, which allows storing and sharing build configurations in a very convenient way. NET nanoFramework is typically done inside VS Code or Visual Studio, which have now a seamless and tighter integration with this build system, fully supporting projects based on it. NET nanoFramework‘s build system uses the well known CMake tool, which is constantly evolving. It could be because they want to experiment and tinker with the code, fix a bug, add a new feature, start working on a port to a new platform or create their own custom image. One of the reasons for this is that it decreases the friction for anyone that wants to build it locally. NET nanoFramework firmware is something that is at the top of our concerns since the project foundation.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |