\uD83D\uDDD3 Date
\uD83D\uDC65 Participants
(To fill from Google meeting report)
Slides
Meeting Notes
JK reminds all about open review requests. The proposal for structure of project is rather important and shall be reviewed timely (#113).
#119
SH: presents ST’s ideas about lockfiles (#119).
SH: Want to align on high level requirements for a log file. Should be able to use a yaml based project. Stable part and reproducible, shareable. Contents of the logfile should not require any tool to understand.
JK: Take a look to current generation - contains a list of packs and components from those packs. Is this not sufficient?
SH: Component is not an exact match. Need some resolving to know which component you selected. Also not clear which pack the component comes from.
RK: Create new or expand cproject file in some way?
SH: Made a proposal not to have interim cproject. Straight from yaml to cmake. The purpose is to describe the project in an obvious way.
JK: Proposal better targetted do describe the conditions that led to the selection.
DB: Concerning the flags - assume they are important.
SH: User files, compiler flags and dependencies - all 3 not mentioned.
JK: Reproduce any time - can this file be used as an input file? Also some duplication vs a project template. Let’s keep going.
JK: Minimal change aspect is new.
SH: Priorities - be stable and provide least amount of surprises.
#82
VG: Purpose is to describe end user source file based on some patterns
JK: Would like people to take a look at this proposal now it’s been refined.
#276
HS: Not just about include but also macro definition - it’s already there.
EF: Is this an add on or is it replacing something?
JK: Would say it’s an extension. Don’t need to use it.
#26 see slide 6
Next Steps - CMSIS-Toolbox
DB: Details of next version 0.10.0
RK: Roadmap details
EF: We’re opening a new definition cycle in the beginning of May until the end of July, and those changes will be reflected in the tool in Q3?
RK: Yes. Will stop on implementing and focus on stability until we have clarity on what’s going to be implemented (next).
SH: What does this mean for project formats?
RK: These need to be stabilised. Enhancements to formats can be done.
JK: Would agree to set it to a fixed version (e.g. 1.0.0)
BD: It’s not complete - so does it make sense to call it 1.0.0?
RK: Needs to be a stable state. Can discuss offline what we call it.
Project Template
(see slide for link)
RK: pro of the cdefault can define which compiler - otherwise make a compiler agnostic project end up with multiple build types - it’s possible but the whole structure becomes complex. Idea is we minimise the usage of compiler specific options.
HS: Can we provide more templates related to multi processor solution.
RK: Yes, example targets NXP device with two processors. Intention is to get it to a stage where it’s reasonable.
Component Selection vs Configuration
RK Intention is not to have complete configuration options, just to select a different set of files which is used instead of a component. Try it out.
#114 Components and Interfaces - better definition
RK: Believe every component has a sort of API.
LM: Do you have an example of how interface would be used?
RK: Not at the moment.
LM: Don’t you foresee conflicts with the pdsc conditions.
EF: registry yaml file - is it a local file?
RK: Yes - in same directory as csolution file
Meeting Recording
(paste recording)