Handling of CMake versions

[PhilippvK]

The new muriscvnn has a relatively strict requirement on the used CMake version (3.22 or so) which leads to erros on most OSes.

Currently this results in an error during mlonmcu setup which is quite hard to read so we should catch stuff like this earlier.

Two ideas:

• Add cmake as managed dependency to the environment (like llvm etc.) and always use this cmake executable when utils.cmake() is called instead of the system one.
• Add a check in the _validate_muriscvnn() function which throws an more-readable error if the version of CMake installed on the system is too low.

@rafzi @fabianpedd what do you think?

[rafzi]

@fabianpedd do we really have to use such a recent cmake version? it would be nice to stick with 3.16 which is available in ubuntu 20

[fpedd]

@rafzi I think I was using some recent feature only available in newer CMake versions. I will have a look and check if it's actually necessary. But the unit tests run just fine on the GH action machines (both on Ubuntu 18 and 20). Do they have newer CMake versions on their machines?

[PhilippvK]

I think there was some strange behavior where CMAKE_OBJCOPY and CMAKE_OBJECTDUMP would not be populated automatically when cross-compiling (by providing a toolchain file which sets CMAKE_C(XX)_COMPILER which was resolved by going to the latest version. However this approach was rather lazy because setting the variables manually in the toolchain file would have also worked out.

i can double check with the version of cmake installed on the chair computers by default and report if the issue still exists.

[PhilippvK]

Unrelated to muriscvnn:

Managing the cmake version used by MLonMCU would still be a good idea as some of the main design aspects of the project have been:

• Reproducible end-to-end flow by freezing the used versions of the dependencies used in an environment
• Do not mess with any software installed on the host
• Make the usage as easy as possible e.g. do not require him to install stuff using apt-get unless necessary.

However there are also some disadvantages:

• Increased install time PER ENVIRONMENT
• Increased size of deps directory PER ENVIRONMENT
• To be consistent we would also do this for the python interpreter,… where it might get tricky.

In the end we could go with a hybrid approach as also possible with all the other dependencies (riscv_gcc, tflmc,…)

• Download an manage CMake during mlonmcu setup if cmake.exe was not provided by the user in the vars section of the environment.yml.
• Setting cmake.exe: cmake Would then use the default system version looked up in the PATH
• We could agree on adding this default value to the environment templates.

[PhilippvK]

See #97