Update to latest MLEK pack v26.06

[kshitij-sisodia-arm]

Bump up pack versions and use new taxanomy for the MLEK CMSIS-pack. Use full mlek/... include paths for headers provided by the new pack now that source/lib is the pack include root. Update logging, framework, common, KWS, and object detection header references to match the generated 26.6.0 pack layout.

[jkrech]

I have not fully understood the reasoning behind changing the component names and why the includes require to specify the full relative path within the MLEK pack.
I wonder whether we should fix the pack versions or instead check-in the *.cbuild-pack.yml so people have a migration path from one pack version to the next. Do we always expect breaking changes from one version to the next? The drawback of using year and month based version numbers is that it does not tell you anything about the compatibility which is derived from Semantic Versioning.

[kshitij-sisodia-arm]

I have not fully understood the reasoning behind changing the component names and why the includes require to specify the full relative path within the MLEK pack.

Thank @jkrech. The reasoning behind the full paths is avoiding name clashes and generally enforcing hygiene with includes. As an example, a header called "Classifier.hpp" could come from any pack. We need to be more deliberate about which module it comes from. It's the same with tensorflow pack - you provide the full path, as you would do from a local build/installation. We want to have the same structure for include paths in all projects - canonical CMake project, CMSIS-pack or with Zephyr.

Provenance of this change: https://gitlab.arm.com/artificial-intelligence/ethos-u/ml-embedded-evaluation-kit/-/commit/26573fb34c1d238a0ecf308f9a6e71c2d76f891c

I wonder whether we should fix the pack versions or instead check-in the *.cbuild-pack.yml so people have a migration path from one pack version to the next.

Open to fixing the pack version in another version. We can either merge this and do that as a next step, or leave it for later. I'm not fussed if this change goes in before or after.

Do we always expect breaking changes from one version to the next?

I expect this to be a one off breaking change. Not something that will happen every release.

[kshitij-sisodia-arm]

Apologies, I realised I didn't actually answer this bit

reasoning behind changing the component names

This is so the "Software Components" view presents the packs in a more intuitive way. Tensorflow Lite Micro, the NPU driver and our pack's components all show up under the "Machine Learning" class. And ExecuTorch and the individual ML pipelines are "variants" that can be selected from a pop down as seen below:

For framework:

And for the samples:

[jkrech]

Thanks for the explanations. I think we can discuss versioning with the next update.
I noticed that the alif target is excluded from the CI build test. We will need to update this in another step as it uses a rather old DFP version.

Configuration files and their *base@version files in the RTE directories are currently missing. This leads to errors when loading the solution as it will not run with --update-rte.
We should address that in a separate PR.

common/RTE/Machine_Learning/*
device/corstone/RTE/Device/*
device/frdm-k64f/RTE/Device/*
device/stm32f746-discovery/RTE/Device/STM32F746NGHx/*
device/alif-ensemble/RTE/Device/*

LGTM

[jkrech]

LGTM

[kshitij-sisodia-arm]

We will need to update this in another step as it uses a rather old DFP version.

Agree. We tested the Alif E7 board before pushing the PR. Should add support for Alif E8 with newer DFP.

Separately, I'd like to understand this better

Configuration files and their *base@version files in the RTE directories are currently missing.