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

[Generator artifacts] inherit attribute for generated files #315

Open
ameltalbi opened this issue May 22, 2024 · 6 comments
Open

[Generator artifacts] inherit attribute for generated files #315

ameltalbi opened this issue May 22, 2024 · 6 comments
Labels
In Discussion Discussion for this issue is open and ongoing Proposal Issue that contains a proposal for change of specification

Comments

@ameltalbi
Copy link

ameltalbi commented May 22, 2024

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
Copy link
Collaborator

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.

@jkrech jkrech added In Discussion Discussion for this issue is open and ongoing Proposal Issue that contains a proposal for change of specification labels May 27, 2024
@ameltalbi
Copy link
Author

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.

image
my_pack.zip

attached the .pdsc and .gpdsc as example.

@jkrech
Copy link
Member

jkrech commented May 31, 2024

@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
Copy link

@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
Copy link
Member

jkrech commented Jun 3, 2024

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
In Discussion Discussion for this issue is open and ongoing Proposal Issue that contains a proposal for change of specification
Projects
None yet
Development

No branches or pull requests

4 participants