Open-CMSIS-Pack Technical Meeting 2022-05-17
Decision Committee Charter & Stages of Change Process
Request for Review
#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.
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.
RK: Generic example projects are based on a unified layer. It’s a phrase invented for projects that use a common interface.
cpackget 0.5.0 available now