Proposal: introduce ZeroCheck build step into generated CMakeLists.txt

[jkrech]

I great feature for the concept would be to add all the ingoing CMSIS Solution files, i.e., csolution, clayer, cproject etc, as dependencies to the generated cmake project. What this offers, is for a user to actually escape from the csolution world into the cmake world.

The way that cmake+ninja works is by adding the zero-check step to ninja, which checks if any of the underlying cmake-files has changed, and of so, runs a bootstrap step before performing the actual build.

This way, CMSIS-Toolbox might potentially add a zero-check step to the cmake-build-files which is able to regenerate the cmake files if the csolution file has changed. For a user who favours cmake, this allows them to convert a csolution project to a cmake project, which is automatically updated if anything changes.

[brondani]

@jlonnberg
Thanks for raising this, I believe it is valuable for your use case and I am supportive in case you want to discuss it further.

Some initial considerations:

1. The CMake ZERO_CHECK target re-runs CMake when the CMakeLists.txt changes, so the generated files (e.g. Visual Studio solution) get updated.
   In a certain perspective your proposed flow runs in the opposite direction: when something in csolution/cproject/clayer changes the CMakeLists.txt get updated.
   To avoid confusion I would avoid the term "ZERO_CHECK", a better name could be "CMakeLists auto regeneration".

2. In your zero_check_example.zip after building once and then removing func.cpp from the cmake_template.txt and from the file system the generate step fails. It means 'generate' and 'build' steps cannot be combined like this:

$ cmake -G Ninja S . -B ./ninja && cmake --build ./ninja
...
CMake Generate step failed.  Build files cannot be regenerated correctly.

3. When using "Unix Makefiles" instead of "Ninja" even the 'build' step fails, it seems to automatically trigger the 'generate' step first:

$ cmake --build ./makefiles
...
CMake Generate step failed.  Build files cannot be regenerated correctly.
make: *** [Makefile:202: cmake_check_build_system] Error 1

4. This approach is not fully decoupled from the CMSIS-Toolbox because the first CMakeLists generation and successive clean re-builds, where the full intermediate 'tmp' directory is removed, would require calling cbuild. Wanting to abstract it completely and to offer a full CMake user interface, wouldn't be a more solid approach to orchestrate all steps (first build, delta build, clean rebuild, etc.) behind your own CMakeLists wrapper?