Open-CMSIS-Pack Technical Meeting 2022-04-26

Participants

Jaeden Amero

Daniel Brondani

Kyle Dando

Evgueni Driouk

Eric Finco

Bill Fletcher

Samuel Hultgren

Reinhard Keil

Joachim Krech

Charles Oliveira

Frederic Ruelle

Holt Sun

David Jurajda

Erik Lundin

Maxime DORTEL

Sourabh Mehta

Slides

Meeting Notes

Request for review:

#296

JK: Are the requirements satisfied?

HS: Yes, believe rte folder can meet our needs. Do you have some examples?

RK: Yes but need some work before we show them.

JK: Don’t have a tool that automatically processes it yet.

(Agreed to close)

#2

JK: Our point of view - packs are part of the project. Basically abstracting that.

FR: Maybe cbuild remains the front end. Someone may need to skip the option to use cpackget.

JK: Flag only if cpackget is invoked. cbuildget won’t invoke cmake

DB: just generates cmake lists.

FR: Wuth other tools (Linux, npm) build fails and get status report but the tool never tries to resolve it.

JK: With meta information we know which packs we need - just part of the project.

FR: Not so sure. In theory any component can be replaced.

JK: As defined, it can’t as we’ve explicitly stated the pack

FR: Not obliged to state the pack - just the component.

JK: Think this is more theoretical.

FR: Had to investigate this today - used the flexibility to test latest delivery. Can still go back.

JK: Can do in cprj in yaml - have the flexibility.

RK: Would be nice to have an option to download packs or not (e.g. “-p”). Useful for slow download speeds also. Could be quick and dirty

SH: Or --offline

#165

JK: Not planning to make any changes for this iteration.

#119

SH: Fulfills many needs - readable, shareable and stable.

JK: The ambiguity is wanting if there’s an update, the use of the previously lockfile can surprise the user.

SH: For each tool you have a lockfile and record the version - put the lockfile in git and colleagues will take the same version. Loose definition is in the prj file.

If don’t have lockfile, create it. If have it try to use it. If there is an incompatibility - behaviour similar to npm in spirit.

JK: Would like to hear more voices.

FR: If there is a lock - it’s locked. Otherwise not.

EF: Need a way to make it obvious to the end user that there is a lockfile.

JK: In the IDE we show there’s a new version available.

SH: file is just one way to store the result of the loose description.

#115

JK: Want to understand what problem you’re trying to address

FR: Normal at component level to deal with software. Maybe I need more than one pack to describe the hardware. “To deal with this hardware, you need these packs”.

RK: Introducing pack types at this point might be quite difficult. Don’t think we have a big gap here.

FR: No way to say you need this pack not because of software but because of hardware - not defined what a bsp pack is.

RK: Maybe need to add the definition.

ED: Any pack can have the dependencies specified.

#116

RK: Config file is always required to configure a component. A template an example of how to use - it’s a user option to use the example or not. Interface would be a new type.

Update CMSIS Toolbox

(Daniel’s presentation)

EF: The pack check version is same as from CMSIS-Pack or are there some changes?

JK: Not an identical copy.

AOB

DB: Opinion on the way we are driving the development. Using directed GitHub issues. Would you prefer Shadowfax user stories and ADRs?

SH: Consider using labels for issues that contain proposals.

EF: User stories are sometimes helpful to understand. Think we can combine the two disciplines.