Open-CMSIS-Pack Technical Meeting 2021-10-12

Date

Oct 12, 2021

Participants

Joe Alderson

Jonatan Antoni

Daniel Brondani

Maxime Dortel

Eric Finco

Bill Fletcher

Marc Goodner

Graham Hammond

Samuel Hultgren

Reinhard Keil

Martin Kojtal

Laurent Meunier

Frederic Ruelle

David Jurajda

Petr Hradsky

Slides

Notes

Potential *.yml structure

FR: Does it mean in this flow the CPRJ is a temporary artifact?

RK: Can view it as a temporary file but can copy it and run a rebuild process without the project manager. An interim format not intended to be edited by users but can import/export it.

RK: Need a manual command line flow and an IDE flow. Daniel has prototyped this.

CMSIS Project Manager - MVP Prototype

DB: Link devtools/tools/projmgr at mvp-prototype · brondani/devtools

FR: everything works based on $CMSIS_PACK_ROOT ?

DB: Yes. If not set it takes the default based on the platform Win/Mac/Linux

FR: Do you expect to give the option to locate the packs we want to use?

RK: Yes we need to define a way to be flexible how you locate the packs.

RK: Tool is written in C++ using CMSIS devtools libraries. It’s an experiment at the moment. Important to know if there are some requirements that are not fulfilled.

LM: Would expect from the project manager that it would give a list of components active in the project - a more “project active” view - a relationship with cpackget.

RK: Yes this is correct. It’s a very early proof of concept.

DB: Yaml.cpp parser used. In this case json is a strict subset. Can submit json and the tool just works.

RK: Did anyone review the ST requirements

DJ: Passed to colleagues at NXP - not responded yet.

RK: Need to see how our concept and ST’s requirements align. Also need feedback from NXP.

DJ: When do you want to publish this in the project scope to be reviewed by members?

DB: Need to clean it up and add some test cases and documentation. Then it will be able to be added into the main branches (link repeated: devtools/tools/projmgr at mvp-prototype · brondani/devtools )

EF: Can we take 5 minutes to align on the discussions on GitHub

RK: My understanding is that the CPRJ file meets the requirements.

SH: Not solving the usecase of defining project in a flexible way. Want to keep the packs I’m using at a specific time. Have a definition of what you care about and what you are using. Also want to distribute it to colleagues.

RK: Project manager simply lists the files that composes the project. Is the CMSIS tool able to give the list of packs that it used.

DB: There is an audit file. In the fixed version it creates a new CPRJ that can be used to reproduce exactly that build. In Samuel’s version it would keep the log file separate from the CPRJ.

SH: The issue with locking things down is it becomes annoying to update packs. Could we also have the condition present in the log file. If add a component it may make other components resolve differently. Want to be able to see this. Log file is output. I need something that is input to the process.

DB: What’s the workflow to generate it?

RK: W ant to generate it in one run and then subsequently use it to see if something has changed. Could distribute it to colleagues and get them to use diff.

FR: Regarding the matching between our concepts and the flow : no major disconnect as immediate feedback. But we need to dig into how you plan to manage resources partitioning (~azone files) and also the direction for packs management (¨CMSIS_PACK_ROOT versus project-defined settings). Can't we have an option to say if we want to generate a "locked" cprj or "open" one ?

Feedback on Handlebars

RK: Doesn’t matter that it’s written in Java - JRE no longer an issue.

FR: What does it mean “missing evaluation language”?

RK: Saw this in comparison vs ‘Moustache'.

FR: Can have a further look at the file.

RK: Need to compare the two options more closely. This is initial feedback.

Recording

Open