[projmgr] enforced component selection using extended component identifier

[jkrech]

The fundamental principle of CMSIS-Pack components is that componentIDs are unique after the filter conditions for each component have been checked.
This proposal is introducing a way to uniquely identify a component independently of the filter conditions by specifying the full <packID> and <conditionID> in addition to the <componentID>.

Extend the components node in cproject.yml/clayer.yml :

  components:
    - component: <componentID>
      from-pack: <packID>
      condition: <conditionID>

Note: this is the notation being used in cbuild.yml already today.

A component with such an extended component identifier will be always be included in the processing, regardless of the result of the condition evaluation just like any other component.

• convert (write: *.cprj, *.cbuild.yml)
• generator (read: *.cbuild.yml)
• build (read: *.cprj)

If several components with the same <componentID> exist in the pack, it is required to add the <conditionID> to identify the exact component to be included otherwise an error will be issued.

[edriouk]

I've got some remarks and questions to this issue:

1. I would suggest using term "primary key" for full component identification, similar to relational database model
2. Should the tool issue a warning if the enforced component does not pass filtering?
3. Should the component's files be filtered or also enforced?
4. May two or more components be enforced if they belong to the same exclusive API or cause conflicts?
5. Should generated components have priority over the enforced ones?

[jkrech]

1. "primary component ID" to make it more specific to the subject
2. probably not by default but maybe in a dedicated validation mode or verbose mode of list dependencies ?
3. In the absence of the condition evaluation, we have no criteria to choose the files. I suggest not to copy configuration files that have a condition
4. In my view, having multiple components being selected for a single exclusive "api" needs to be checked and reported regardless how a component is specified.
5. Similar to point 4 I think we should not have different rules ... but open for feedback.

[ReinhardKeil]

1. component + condition must be unique for the selected meaning that just one component fulfills this filter.
2. specifying a pack: for a component bypasses component filtering by conditions.
3. I believe we should copy config files for the component for consistency, but open for discussion.
4. yes that should cause a conflict (-> error or warning message)
5. when a pack: is specified, the component is taken from the pack:; if there is a conflict with other components issue error or warning.

[mcgordonite]

In the absence of the condition evaluation, we have no criteria to choose the files. I suggest not to copy configuration files that have a condition

I believe that all files from a component can have conditions, not just config files. E.g. two copies of the "same" source file, one for ARMC6 and one for GCC. In that case I think we'd need to take some filtering into account when running the build.

[ReinhardKeil]

@mcgordonite you are right, so a filter for conditions at file level needs to be applied.

[jkrech]

@slhultgren please review the updated implementation for 1.7.0 and raise a new issue in case this does not meet your expectations.