-
Notifications
You must be signed in to change notification settings - Fork 21
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
[GPDSC Spec clarification]: Do "csolution" uses the GPDSC file content to override the PDSC definition of components ? #317
Comments
Tests re-executed using csolution v2.3.0, I get the same result as csolution v2.0.0, only the PDSC defines are taken into consideration, GPDSC declared defines are not taken into account at the convert step RTE_Components.h generated file: /*
* CSOLUTION generated file: DO NOT EDIT!
* Generated by: csolution version 2.3.0
*
* Project: 'app6_SW.debug+main'
* Target: 'debug+main'
*/
#ifndef RTE_COMPONENTS_H
#define RTE_COMPONENTS_H
/*
* Define the Device Header File:
*/
#define CMSIS_device_header "stm32u5xx.h"
/* STMicro::Device:generated:[email protected] */
#define _RTE_COMPA_FROM_PDSC
#endif /* RTE_COMPONENTS_H */ Pre_Include_Global.h /*
* CSOLUTION generated file: DO NOT EDIT!
* Generated by: csolution version 2.3.0
*
* Project: 'app6_SW.debug+main'
* Target: 'debug+main'
*/
#ifndef PRE_INCLUDE_GLOBAL_H
#define PRE_INCLUDE_GLOBAL_H
/* STMicro::Device:generated:[email protected] */
#define PRE_INCLUDE_GLOBAL_COMPA_FROM_PDSC
#endif /* PRE_INCLUDE_GLOBAL_H */ Pre_Include_Local_compId.h /*
* CSOLUTION generated file: DO NOT EDIT!
* Generated by: csolution version 2.3.0
*
* Project: 'app6_SW.debug+main'
* Target: 'debug+main'
*/
#ifndef PRE_INCLUDE_DEVICE_GENERATED_COMPA_H
#define PRE_INCLUDE_DEVICE_GENERATED_COMPA_H
/* STMicro::Device:generated:[email protected] */
#define PRE_INCLUDE_LOCAL_COMPA_FROM_PDSC
#endif /* PRE_INCLUDE_DEVICE_GENERATED_COMPA_H */ Observed behavior: GPDSC definition of the same component is not overriding the PDSC component element. Extra tests: When updating the pack vendor name of the GPDSC template, or the component cgroup like displayed in the snapshot: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- ******************************************************************************
* File Name : GPDSC_template.gpdsc
* Description : Generator PDSC File generated by CodeGen (DO NOT EDIT!)
****************************************************************************** -->
<package xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" schemaVersion="1.0"
xs:noNamespaceSchemaLocation="https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/blob/main/schema/PACK.xsd">
<vendor>STMicro</vendor>
<name>packA</name>
<description>Pack A description</description>
<url>path</url>
<releases>
<release version="0.0.1">
{{lowercase "- First GPDSC template Model Release"}}
</release>
</releases>
<conditions>
<condition id="conditionC">
<description>condition C</description>
<require Cclass="fake" Cgroup="generated" Csub="compF" />
</condition>
<condition id="filecondition1">
<description>Condition 1</description>
<require Cclass="fake" Cgroup="generated" Csub="compB" />
</condition>
<condition id="filecondition2">
<description>Condition 2</description>
<require Cclass="fake" Cgroup="generated" Csub="compC" />
</condition>
</conditions>
<generators>
<generator id="GEN-1">
<description>GEN1 generator</description>
<exe>
<command host="win">gen.bat</command>
<command host="linux">gen.sh</command>
<!-- Generator Id -->
<argument>GEN-1</argument>
<!-- Generator Input File absolute path -->
<argument>$G</argument>
<!-- GPDSC Template File Name -->
<argument>template_model.gpdsc.hbs</argument>
<!-- Flag to indicate that this Generator is dry-run capable -->
<argument mode="dry-run">--dry-run</argument>
</exe>
<gpdsc name="$P/template_model.gpdsc" />
</generator>
</generators>
{{!-- SELECTED COMPONENTS LIST --}}
<components>
<component Cclass="Device" Cgroup="generated-updated" Csub="compA" Cversion="1.0.0" generator="GEN-1">
<description>TO BE DEFINED</description>
<RTE_Components_h>
<!-- the following content goes into file 'RTE_Components.h' -->
#define USING_CompA_GPDSC
</RTE_Components_h>
<Pre_Include_Global_h>
<!-- the following content goes into file 'Pre_Include_Global.h' -->
#define PRE_INCLUDE_GLOBAL_compA_GPDSC
</Pre_Include_Global_h>
<Pre_Include_Local_Component_h>
<!-- the following content goes into file 'Pre_Include_Local_<ComponentId>.h' -->
#define PRE_INCLUDE_LOCAL_compA_GPDSC
</Pre_Include_Local_Component_h>
<files>
<file category="source" name="stm32_compA.c" />
<file category="header" name="stm32_compA.h" />
</files>
</component>
</components>
</package> the new updated component description is taken into consideration /*
* CSOLUTION generated file: DO NOT EDIT!
* Generated by: csolution version 2.3.0
*
* Project: 'app6_SW.debug+main'
* Target: 'debug+main'
*/
#ifndef RTE_COMPONENTS_H
#define RTE_COMPONENTS_H
/*
* Define the Device Header File:
*/
#define CMSIS_device_header "stm32u5xx.h"
/* STMicro::Device:generated-updated:[email protected] */
#define USING_CompA_GPDSC
/* STMicro::Device:generated:[email protected] */
#define _RTE_COMPA_FROM_PDSC
#endif /* RTE_COMPONENTS_H */ Main Question
|
I reproduced a similar scenario in MDK uVision 5.40 and do see the expected behavior, that the Cversion attribute of the component definition in the GPDSC file needs to be larger or equal to the component version in the PDSC file to override it. I converted the uvprojx to csolution and repeated the test and I can see the defines from GPDSC if the component defined in the gpdsc is greater or equal to the Cversion of the component specified in the PDSC file. Otherwise I see the defines coming from the PDSC |
Thanks Joachim for the tests, I will re-check the tests following your described scenario about the component version in the GPDSC that should be greater or equal to the PDSC version and confirm the behavior. |
Following the above recommendations from @jkrech (The Cversion attribute of the component definition in the GPDSC file needs to be larger or equal to the component version in the PDSC file to override it), at the convert step, i can see in the RTE folder that the defines from GPDSC are taken into consideration if the component defined in the gpdsc is greater or equal to the Cversion of the component specified in the PDSC file. Otherwise I see the defines coming from the PDSC. . I think that this behavior should be documented in the GPDSC spec For the rest of the applied tests, the GPDSC template manual editing is very error prone since it can cause GPDSC .xsd schema inconsistancies which seems implicitly not detected by csolution (maybe warnings messages to the end user should be added to ease the debug step) |
Hi @jkrech, Thank you for your feedback
Following our discussion about the strange behaviors observed and described in this ticket, I re-adjusted the GPDSC template following your recommendation:
After following this scenario:
Observed results:
this would confirm our assumption that every PDSC element described in the spec (https://open-cmsis-pack.github.io/[Open-CMSIS-Pack](https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/index.html)-Spec/main/html/index.html) is supported via the GPDSC. |
Summary:
|
GPDSC Spec clarification
1. Assumptions:
2. Scenario example description:
a. Use a packA PDSC definition like the following:
b. Generate a GPDSC file with the following content:
3. Observed Result:
The content of the RTE_<context_id> Generated files is the PDSC list of defines, the GPDSC definition of <RTE_Components_h>, <Pre_Include_Global_h>, <Pre_Include_Local_Component_h> for the same component is not taken into consideration by csolution.
RTE_Components.h generated file:
Pre_Include_Global.h
Pre_Include_Local_compId.h
4. What is expected ?
The text was updated successfully, but these errors were encountered: