[Generator artifacts] inherit attribute for generated files

[ameltalbi]

The Problem To Be Solved

The principle of read-only “Generator artifacts” is that generated code is fully managed by the generator, so that generated files are in read-only mode access (earased and regenerated from scratch when regenerate).
Nevertheless, we need to consider the case of generated files that need to be modified by user to manage its application part, like “generated user templates”
==> Generator artifacts could be also modifiable (same as configuration file)

The need is to be able to tag modifiable generated files.

Accordingly we need to introduce a mechanism so that attributes are inherited to generated file (generated based on a "genAsset" file).

Suggest A Solution

Add a new child element named "inherited" to be added to <file> with attribute "category" set to genAsset from where generated file will inherit attributes defined inside.

example:

<file category="genAsset" name=".config/template/compX/app_init_template" attr="modifiable">
	<inherited attr="modifiable" category="source"/>
</file>

these attributes should be then transferred as attributes of the generated file inside the .GPDSC (similar solution will be also needed for .cgen.yml option)

<file category="source" attr="modifiable" name="app_init.c" />

[ReinhardKeil]

It is up to the generator to set the RO attribute on files in the generator output (see Generator Integration).
Some IDEs (i.e. uVision) show this RO attribute clearly - VS Code unfortunately informs the user only when he attempts to save the modifications.

Two initial asks:

• How should this affect the user flow during application development. How would be the user informed that a file is user modifiable? Any idea how VS Code could be improved to support the workflow?

• could you provide an example (a small mockup is just fine) of a *.PDSC file.

[ameltalbi]

Hello,

Here is an example of .psdc and .gpdsc implementing our proposal for an inherited modifiable attribute.
It shows how the attribute is inherited to the generated file description.

my_pack.zip

attached the .pdsc and .gpdsc as example.

[jkrech]

@ameltalbi , thanks a lot for sharing this example.
I am wondering, whether you insist on adding a sub element <inherited>?
We could add another attribute to <file> e.g. customizable="true". The generator would just replicate this attribute when "converting" the template into the final file.
Is there anything we would loose with this approach?

[mdortel-stm]

@jkrech
For the moment, we talk about only one attribute to apply to the output file.
It is not impossible that some others have to be added later, with the risk that the attribute on the asset has a different meaning.
In addition, this "modifiable" attribute is not meant to be used on other types of files: putting attributes on a new node looks more adapted to support validation and further extensions.

[jkrech]

In addition, this "modifiable" attribute is not meant to be used on other types of files: ...

The schema for a *.pdsc and *.gpdsc regarding <component ...><files><file ...> is currently the same.
Looking at the gpdsc example above:

<file category="source" attr="modifiable" name="app_init.c"/>

the "modifiable" attribute is used for a regular C source file and what it means for a source file is currently not defined.

[ameltalbi]

@jkrech, Yes you are right, that's why we request that this attr="modifiable" is to be allowed (valid) only in a .gpdsc file.

[iomint]

[After Open-CMSIS-pack weekly call held 25w07, when ST was asked to provide an update]
ST continues to support this proposal. However, we are not ready to work on this topic again yet.