[csolution] Investigate new CMakeLists.txt generation

[brondani]

In csolution it's possible to describe several projects and build-types/target-types resulting in several contexts and several build artifacts which may have inter dependencies.

Instead of extending the CPRJ specification (#171) we have decided to establish a new format, the cbuild.yml, and to re-implement the CMakeLists.txt generation.

In this scenario the following topics must be investigated:

• generating CMakeLists for inter-dependent multi-context solutions, deprecating *.cprj intermediate format for a single context​
• handling multiple toolchains in the same solution
• modular generation of CMake targets allowing its integration with other CMake based projects and/or build plates
• integration of existing images (that are i.e. generated using CMake)​
• pre/post build steps​

[Torbjorn-Svensson]

During the meeting today, I mentioned the following ideas/remarks:

• I think that it should be possible to define the the pre/post build steps on the cproject level in order to make it easier to reuse the same cproject in several csolutions without having to duplicate the configuration. I'm not sure if it makes sense to also have this possibility on the clayer level or if cproject should be enough.
• Mixing 2 different compilers (from different vendors in this case) is usually a bad idea as it's not certain that all the types has the same size and it would cause strange runtime behavior that is really hard to debug if the application is linked at all.
  Mixing 2 different version of the same compiler, GCC10 and GCC11 for example, is a different story and should perhaps be supported.
  Then again, this is not something that the typical user would do/need.
• If it's possible to avoid absolute paths etc in the CMakeList.txt file, without a ton of extra work/validation, then I think it would be sane to do it.
  In addition to support sharing the file, although I'm not sure this is a normal use-case, it would also allow the project to be moved on disk without requiring to regenerate the file.

[brondani]

The first results of the investigation have been captured in the document below alongside a practical example:
https://github.com/brondani/devtools/blob/cmake-proposal/tools/projmgr/docs/CMakeListsProposal/RevisionHistory.md

Comments, questions, remarks, all sorts of feedback are much appreciated.

[tomoveu]

I find it very difficult to use CMSIS using Cmake. Is it possible download CMSIS and build natively with Cmake?

Top results in google lead to CMSIS-build tool which is 🛑 deprecated. Afterwards, CMSIS documentation points to CMSIS-toolbox that speaks of a new tool named cbuild but without an example project. My impression is that using CMSIS natively is not possible. We need some extra non-cmake tool to compile CMSIS using cmake - this feels wrong. I hope my feedback is useful in some way and please let me know if there is any way I could help to make this process better.

Real-life use case: Getting CMSIS to work with Cmake based project is painful and prevents us from using nice projects like arm-2d that depends on CMSIS.

[brondani]

@tomoveu Thanks for the feedback.
The CMSIS-Packs features have some complexity which includes conditional software components encapsulation making it hard to be translated in plain CMake libraries.
Basically to benefit from CMSIS tooling such as Keil Studio, CMSIS-Packs should be used and the projects should be described/formatted accordingly.
Having said that, we are aware of several use cases involving CMake that could be desired by developers, for examples those willing to access just a component's build information ignoring all other side benefits. The investigation/proposal in this GH issue, which concerns specifically a replacement for the cbuildgen tool and the related CPRJ format, tries to cope with them. In particular I believe your use case is described as
"Add CMSIS components into stand-alone CMake based project".
Concerning the current CMSIS-Toolbox contents, an overview is given in its documentation.

[massonal]

Hi,
I've just taken a look at your proposal, and I thought I'd share some feedback.

The architecture proposed in this issue look much closer to idiomatic CMake code (vs the current cbuild, v.2.0.0 on my machine). This would mostly solve #648 #649.

So, big 👍 there.

However, I agree with @Torbjorn-Svensson's views from earlier in this thread, notably on this point:

Mixing 2 different compilers (from different vendors in this case) is usually a bad idea as it's not certain that all the types has the same size and it would cause strange runtime behavior that is really hard to debug if the application is linked at all.
Mixing 2 different version of the same compiler, GCC10 and GCC11 for example, is a different story and should perhaps be supported.
Then again, this is not something that the typical user would do/need.

I don't think it's a good idea to allow several toolchains in the same CMake project. It may lead to issues at compile-, link-, or run-time that are often very obscure and hard to debug.
If a user ever needs this, I think they should have two separate CMake projects and call a post-buildS script on their own... So, no need to support it in CMake, considering the complexity it would add.

[jlonnberg]

It's a good idea to align the models and I believe that it would be really beneficial to try to align the model as much as possible with CMake as possible. For me, this translates into a 1-to-1 relation between the csolution.yaml and the CMakeLists.txt, i.e, keeping a combined CMakeLists.txt for all projects and configurations.

This will allow cmake to keep track of interproject dependencies out of the box and aligns the csolution model more with CMake. Moreover, I believe that mixing toolchain is a really poor choice. Keeping one single CMakeLists.txt for the entire project will also align the toolchain usage and help with possible problems that may arise if different subparts are built using different compilers.

[jlonnberg]

Moreover, many modern IDE:s utilize CMakes file apis to drive the UI, e.g., CLion uses this but this requires a unified cmake project for the entire csolution. Creating a single CMake file for the entire project will automatically give support for the CMSIS Toolbox concept in such environment as well

[brondani]

The investigation is concluded, the work packages will be defined and tracked in #1237.