Open-CMSIS-Pack Technical Meeting 2022-06-07

 Participants

Mario

Frederic

Kyle

Eric

Maxime

Daniel

Luis

Charles

Sourabh

Holt

DavidJ

Tarek

Bill

Joachim

Slides

Meeting Notes

#133

JK: Would like to have feedback by next week. REVIEW 2 is an extension (not either/or).

FR: Applies to a C module only. For another language we’re not restricted by this change.

JK: Agreed.

FR: csolution will use this to produce the cprj. Will need to add additional filetypes for templating languages but they will not be impacted by this proposal.

FR: Question about PRs and version numbers. It’s possible to have collisions. Will the maintainer reconcile/assign the version numbers?

JK: May need to accumulate multiple changes into one version increment.

FR: Increment version only when published. Currently there’s a “1.78” from me and a “1.78” from Charles.

#127 Extensions

FR: Limited proposal to the component.

JK: Could we get 1 PR to cover the whole thing?

FR: Not sure if we need for more than components. Can go step by step or do all areas knowing we’re not going to use all of them. Can aim to clarify by this Friday (10th).

License

FR: It’s currently an issue that accepting the EULA on the Keil website doesn’t mean I accept the terms in the ST pack.

JK: The extension we’re discussing allows to specify multiple licenses per pack. It doesn’t necessarily cover the website.

FR: It’s also an issue that you can’t inspect the license without downloading the pack … and implicitly accepting the license.

JK: The command line allows to just extract the license. Can maybe provide a weblink to the license, but again this is out of scope for the issue.

How to specify component on a board

JK: Have moved this up. Would like people to review this so it can go to the committee.

#126

JK: Can now extend the semantic version pattern and allow a leading zero. Everything else is details and consequences. For comparisons, “01” = “1”.

FR: What really matters is the semantic versioning of the component rather than the pack

JK: Would rate it higher, but a major pack version change can imply incompatible component versions inside. Not aware of tools like PLM that takes decisions based on pack versions.

DJ: How to handle existing packs that have non-standard versions - some have e.g. embedded characters. Hard to force authors to use new schema. Would vote to relax the rules - although it’s nice to have a standard.

ED: Problem would how you show what is the most recent pack?

DJ: In NXP we are using a single known format, and are mapping versions from 3rd party authors (done manually rather than via a translation table).

Request for Review

#179

MP: Is there a place in the code where a CMake generator is chosen?

JK: Call CMake and select the generator. Not currently using a generator for IAR. All the symbols are mapped to compiler options. Ultimately we need to maintain this over time for new compiler versions.

TB: Need to maintain for new cores and warning translations.

MP: Is it just the CMake file we should take care of?

JK: Yes, but it would good to check that the whole flow works.

ED: Can run tests via github action in the cloud.

MP: Do you have documentation on running the github action.

ED: Not really. You can see simple examples using gcc.

Other issues where review is requested: #355 #356 #124 #352 #335 #122

VG: Also issue #119 - no progress since the beginning of May and it’s an important topic. We need a further iteration of the proposal.

Meeting Recording

Open