Open-CMSIS-Pack Technical Meeting 2022-05-03

 Participants

Dragos

Jaeden Amero

Jonatan Antoni

Daniel Brondani

Kyle Dando

Evgueni Driouk

Eric Finco

Bill Fletcher

Vincent GRENET

Samuel Hultgren

Reinhard Keil

Joachim Krech

Charles Oliveira

Frederic Ruelle

Sophie Williams

David Jurajda

Erik Lundin

Sourabh Mehta

Slides

 

 

Meeting Notes

JK: Request for review. Make sure issues don’t get lost or forgotten about.

Label “Proposal”: believe more people should have access and permission to set labels.

#314/#308 Proposal for shorter file/pathname

RK: Helps in the out name with the need to build part of system as release and part in debug mode but use a common out directory. Could be a configuration option.

JK: People would need to know what their last build was.

RK: Would not need both debug and release version of blinky at the same time.

SH: Might need to compare optimisation levels.

RK: then would need to be a configuration option.

SH: would prefer it was in the yaml file.

DB: It helps to keep cmake targets shorter. Also have Windows characters limitation on filenames. Windows 10 (version?) has a work around to disable the mechanism.

[JK: https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd ]

RK: Should write guidelines for how pack names are composed.

#313 Version Control of RTE Folder

FR: Not something that should be in the spec. More of a recommendation

JK: Tools require to have the version information. How does the user figure out the reason for failure if there’s an incompatible change in a component.

FR: If the tool can find the reference file can give some indication to the user.

RK: Without revision control, the tool doesn’t know there’s a new version.

JK: Version number relies on this file.

FR: Just wondering what should go in the spec.

JK: Fully specced project is what you need to give someone else and they can build it.

SH: Also .config file is not automatically hidden on Windows - need something cleaner like a separate folder.

#315 Usage of cdefault.yaml

RK: Use to define default compiler

[FR: .cdefault.yml is not defined here: https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/projmgr/docs/Manual/Overview.md

RK: you are right, documentation is broken as it is called 'csettings.yml' ]

SH: What if specified already?

RK: Could give a warning. cdefault is taken first. csolution would override. BTW in the documentation csetting and cdefault is the same file.

[DB: here there is some info: https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/projmgr/docs/Manual/YML-Format.md#default ]

#119 Using existing .cprj as a lockfile

RK: Make a gap analysis of what’s not in cprj currently.

ED: Can always keep track in version control repository.

[DJ: "Managing a requirements.txt file can be problematic, so Pipenv uses Pipfile and Pipfile.lock to separate abstract dependency declarations from the last tested combination." ]

AOB

FR: (linked to logfile discussion) Need a mechanism to resolve disagreements.

RK/JK: Agreed. Can be a board of representatives locked in a room until they make a decision and Linaro could be involved in ‘peacemaking’.

 

Meeting Recording