Skip to content

Update to latest MLEK pack v26.06#12

Open
kshitij-sisodia-arm wants to merge 1 commit into
mainfrom
feat/mlek-cmsis-pack-26.06
Open

Update to latest MLEK pack v26.06#12
kshitij-sisodia-arm wants to merge 1 commit into
mainfrom
feat/mlek-cmsis-pack-26.06

Conversation

@kshitij-sisodia-arm

Copy link
Copy Markdown
Collaborator

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.

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.

Change-Id: Iea7ec6f24c284fb90d5f25c2e99e99222856463a
Signed-off-by: Kshitij Sisodia <kshitij.sisodia@arm.com>
@jkrech

jkrech commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

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

kshitij-sisodia-arm commented Jul 1, 2026

Copy link
Copy Markdown
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants