\uD83D\uDC65 Participants
(Can be filled from Zoom meeting report)
Slides
Meeting Notes
#450 Local support in cproject.yml for build-type and target-type
HS: Got some suggestions from Joachim for for-type.
RK: for-type is not required
HS: Think it (#450) meets our requirements. It’s very important for multicore projects in RT platforms.
RK: We have agreement that #450 is the framework we’re going to implement. Will rename for-type to for-context to make it clearer. Will work to get it into the specification.
#175/#176 File category mapping
RK: Backward compatibility vs older versions of the tools is the compelling part.
ED: If a file is for both C and C++ how do we specify that?
JK: Would have needed to specify it twice
RK: My opinion - have C-CPP to cover both
#615 Guidance for compiler agnostic projects
#607 ‘defines’ are used by all build tools
HS: Think the yaml file should have the same requirements as #175/#176
RK: Don’t think this is a big deal (to add it).
#618 way to rename build output in cproject/csolution
HS: Think not only about output, but also about output name.
JK: in this proposal you have file-path file extension
CMSIS-Toolbox Version 1.4.0
FR: Just for the naming, I think we should avoid saying "variant" when we say that they are all valid at the same time. With components, variants are exclusive.
JK: alternative
FR: I'm still confused - sometimes it is values, sometimes drivers instances ?
JK: Alternative layers need to be used exclusively like variants...
DB: Could be named ‘capabilities’ if interfaces is too confusing.
EF: Is there a way to describe how components are configured? Interested to know how it can work and how to use it.
RK: Have some demos in preparation.
JK: Still need to get to a taxonomy.
Meeting Recording
(Zoom recording uploaded via Files & Images)