Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide full, readable and editable "condition" element directly in component and file element #279

Open
tcsunhao opened this issue Jan 24, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@tcsunhao
Copy link
Contributor

tcsunhao commented Jan 24, 2024

In existing pdsc, the dependencies of components are specified through "condition" mechanism. On component level, just a condition refer id is provided, the detailed definitions of the condition are defined in "conditions" element. If user needs to know details of one component dependency, he needs to search up to down, down to up, many times in the "conditions" to figure out the whole picture which is quite inconvenient. When he/she tries to update it, sometimes it is possible. Here is snap of existing NXP DFP conditions:
image

Suggested way to improve:

  1. Generally, put full picture of condition into component
  2. component dependencies shall be explicitly specified
  3. device, board and other hardware related dependency can still refer condition id.
    In this way, users can directly get full picture of the dependencies at the first glance with the most addressed component dependencies and without making the conditions too long and messy with too many hardware data.
    Here is one simple example:
    image

The same way applies to "files" element.

We believe that an human easily readable and editable pdsc files can better populate OCP solution especially in directly github repo daily development usage (not ready packs way)

GitHub repository as pack source

@tcsunhao tcsunhao changed the title Provide full, visible and editable "condition" element directly in component element Provide full, readable and editable "condition" element directly in component element Jan 24, 2024
@tcsunhao tcsunhao changed the title Provide full, readable and editable "condition" element directly in component element Provide full, readable and editable "condition" element directly in component and file element Jan 24, 2024
@jkrech jkrech added the enhancement New feature or request label Jan 25, 2024
@tcsunhao
Copy link
Contributor Author

The introduction of individual “conditions” element or something like that can be implemented in a backward compatible way.

Here is one NXP manifest dependency example:
image

@DavidJurajdaNXP
Copy link

DavidJurajdaNXP commented Jan 30, 2024

NXP manifest schema: sdk_manifest_v3.14.txt
See line 1661: <complexType name="componentDependenciesType">

@edriouk
Copy link

edriouk commented Jan 30, 2024

Moving component dependencies directly into component description body is relatively easy to implement, however that will break backward and forward compatibility for several tools, in particular :
uVision, CMSIS-Toolbox, packchk: all share the same C++ RTE Model
Arm DS , IAR Embedded Workbench (Java/Eclipse RTE Model)
MDK Arm CMSIS csolution VS Code Extension

@edriouk
Copy link

edriouk commented Jan 31, 2024

Readability can be improved by applying the following rules when constructing conditions:

  1. Use component ID as component condition
  2. Separate different types and domains of condition expressions into dedicated sub-conditions
  3. Avoid/minimize further nesting of conditions - use short but descriptive names

Here is an example of readable conditions:

<component Cclass="Device" Cgroup="SDK Drivers" CSub="common" Cversion="2.4.0" condition="Device.SDK_Drivers.common">
 <!-- component body -->
</component>
<!-- ... -->
<conditions>
  <condition id="Device.SDK_Drivers.common">
    <description> Dedicated condition for Device.SDK Drivers.common component</description>
    <require condition="Device.SDK_Drivers.common_Device"/>
    <require condition="Device.SDK_Drivers.common_Toolchain"/>
    <!-- component dependencies -->
    <require condition="Device.SDK_Drivers.common_Dependencies_Require"/>
    <require condition="Device.SDK_Drivers.common_Dependencies_Accept"/>
    <require condition="Device.SDK_Drivers.common_Dependencies_Deny"/>
  </condition>

  <condition id="Device.SDK_Drivers.common_Device">
    <description> Optional device condition to enable Device.SDK Drivers.common component</description>
    <require Dname="MIMXRT1064*"/>
  </condition>
  <condition id="Device.SDK_Drivers.common_Toolchain">
    <description> Toolchain condition to enable Device.SDK Drivers.common component or its files </description>
    <accept Tcompiler="ARM"/>
    <accept Tcompiler="GCC"/>
  </condition>
  <condition id="Device.SDK_Drivers.common_Dependencies_Require">
    <description> Required dependencies by Device.SDK Drivers.common component </description>
    <require Class="CMSIS" Cgroup="Core"/>
    <require Class="Device" Cgroup="SDK Drivers" Csub="clock"/>
  </condition>
  <condition id="Device.SDK_Drivers.common_Dependencies_accept">
    <description> Accepted dependencies by Device.SDK Drivers.common component </description>
    <accept Class="Device" Cgroup="SDK Utilities" Csub="assert"/>
    <accept Class="Device" Cgroup="SDK Utilities" Csub="assert_lite"/>
  </condition>
  <condition id="Device.SDK_Drivers.common_Dependencies_deny">
    <description> Denied dependencies by Device.SDK Drivers.common component</description>
    <deny Class="CMSIS" Cgroup="SDK Drivers" CSub="another_common"/>
  </condition>
</conditions>

@tcsunhao
Copy link
Contributor Author

tcsunhao commented Feb 1, 2024

Thanks @edriouk, your suggestions indeed improve the readability to a certain extent.
About op3, honestly, we cannot guarantee about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants