thanks, not so much faster than my first impression was, but maybe it will be more difference with larger projects. And compiling under windows with NTFS is much slower, in WSL2 its nearly as fast as with native linux.
Its also interesting that the codesize with CLI2 is larger, it should use the same compiler flags.
@hudakz for CLI1 are you using .mbedignore? If so, can you try with an empty one?
Again, CMake and static libs will make a lot of sense for real project using multiple targets, bootloaders, etc., not just for blinky examples.
We have around 20 spikes + bootloader + main firmware and once mbed-os is built, adding a new spikes only adds one or two seconds to the compilation time.
Those results also improve a lot when using ccache which I highly recommend.
Yes, I use this .mbedignore file in each CLI1 project. Actually, what CMake does in CLI2 (selects which files shall be compiled) the .mbedignore file can do in CLI1. The main difference is that while CMake applies a distributed approach (directory wise CMakeLists.txt files) the .mbedignore file enables a sort of centralized configuration concentrated in one file. Of course CMake offers much more but it’s also more complex than the .mbedignore file.
But my main interest was to compare the performance of the Ninja build system with the GNU make.
If so, can you try with an empty one?
Sure. But in this case the number of uselessly compiled files (files which are not used by the linker to create the final binary file) is much higher in CLI1 than in CLI2:
yes, with mbed2 I was also happy with the simple build system. It was easy to use, just copy the files to the project and no hustle with include path. But with the large growth of Mbed, it wasted a lot of time with compiling unused stuff. mbedignore was also no perfect solution, the depencies made a lot of trial and error necessary. I think you spent a lot of time to create your sets of ignorefiles
Then you want to use network or other components and start again fixing dependencies. So cmake is a big milestone for Mbed. For small libraries, the configuration is really manageable,
.mbedignore prevents files from being compiled by ignoring them
CMake lets you choose the files you need to compile by choosing them, packaging them into library targets and then choosing to link against a target or not
There is no logic behing .mbedignore, you just ignore stuff.
There is logic with cmake in how you architecture your project, how you modularize your code, etc.
That’s why the two approaches are vastly different.
I tried to use the GNU make build system rather than ninja. CMake was used to generate the build environment and manage the build process with CLI2. It turned out to be working too:
