\uD83D\uDC65 Participants
(To fill from Google meeting report)
Slides
Meeting Notes
Decision Committee Charter & Stages of Change Process
Bill’s slides
Request for Review
#331
#334
#335 ( was #171 )
HS: Want to provide out of the box debugging experience for customers. Need to pre-configure debug. In existing CMSIS mechanism there is an extension point “environment” and maybe we can produce debug information. We need to find a place to put the configuration for examples where the default configuration isn’t the right one.
TB: csolution can have multiple configuration including a debug configuration.
JK: Can link debug configuration to context.
VG: There are some insertion points available in yaml now. Let’s use those and then see if we need to extend the specification.
JK: Need more inputs/discussion on this.
#332
HS: Have comments in the issue. We directly provide information on the dependencies in/between the examples. Out IDE will automatically do some loads. Want to retain this feature when we move to Open-CMSIS-Pack.
HS: Not sure if a solution yaml can contain (only) 2 projects. If we have 4-5 pairs of projects it’s hard for the IDE to follow.
JK: Have the build type and target type. Doesn’t need to be a pair. Can have projects dependent on build and target type. These are the dependent projects. Can we have an example?
HS: In csolution docs I don’t see a practical way to figure out the relationship between 2 targets. In some cases one target depends on another target.
(multicore usecase example)
JK: Will take an action to go through the example and then NXP can feed back why existing mechanism isn’t sufficient.
#122
RK: Generic example projects are based on a unified layer. It’s a phrase invented for projects that use a common interface.
Other Updates
cpackget 0.5.0 available now
Meeting Recording
(paste recording)