Oct 5, 2021
Actions from last meeting related to evolution for configuration files:
The pdf doc is available here: https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack/files/7279772/Multi-Context_Concepts_OpenCMSIS.pdf
Link to the glossary: https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack/wiki/Glossary
Issues #30, #31, #32 created
Yaml & Json
RK: Need to start creating tools: in my view yaml has one feature over json - can add comments.
Discussion on way to make decisions in the group?
FR: my inputs for this YAML topic : https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack/issues/12#issuecomment-929065226
Here are (also) my inputs for templating engine: https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack/issues/12#issuecomment-929118878
LM: Could take Frederic’s benefits as pros
FR: For json can create a key with a comment.
MG: There is “json with comments” that supports //. Find that much easier to use than the key-style comment.
RK: Many tools use yaml as a configuration file format. Ultimately it’s just a vehicle to provide data to the tools.
MG: Worked on a project used yaml and found it beneficial for users to hand edit files. We are moving back to json for consistency with other tools.
RK: Does it matter?
FR: Scheme, path, library? Do we have similar things for yaml?
RK: Is a schema repository. Not sure if we already experimented with that.
JA: Haven’t yet tried it. Yaml can use the json schema store. Worth having a browse to see how the languages are used.
FR: If we use the full features of yaml are we consistent with the json schema?
RK: Don’t think we’ll use all the possible features. Just think it’s easier to edit. Test tools use python a lot. Have positive feedback from packgen tool.
DJ: Using yaml for internal description. Also using json schema for validation. Experience is positive for yaml format.
EF: VSCode is able to consume json file quite easily. Are you able to consume a yaml file when it fulfills the json schema?
DB: For VS Code, Red Hat provides yaml support. We are experimenting with using the json libraries. Seems quite straightforward if there’s a fixed schema. They are quite similar.
DJ: Yaml format supports comments but not all libraries are able to load a yaml file and dump it back whilst preserving the comments.
FR: Concerns: we select yaml just to get the comments, we end up with something difficult to maintain, even if familiar with python, not so fond of indent-based languages.
DJ: Yaml is generally acceptable for NXP
LM: Do we want to exercise a decision process?
DB: Don’t have objections to use yaml cpp library.
RK: Proposal to use yaml.
EF: ST not completely comfortable to use yaml. Can’t see the consequences for us. ST issues mentioned here https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack/issues/12#issuecomment-929065226
Discussed aligning checking on some kind schema.
JA: Easiest way to work with Daniel and show the schema validation work we are doing. Use Red Hat yaml support.
RK: Propose to cut short the discussion here.
RK: Know that ST has a lot of experience with Freemarker. Any reasons why Freemarker is not the right way?
MD: Quite a powerful templating language
RK: Could you take an action to show it to us.
FR: Does FTL have the same features as Handlebar?
MD: In FTL you have macros. Don’t think there’s a major difference. Freemarker is a classical way to address templates.
Potential Tool Flow - STMicroelectronics
RK: Have other people reviewed it? Should we take the action to review it again.
LM: If there are any other alternate naming then please make them known or if some concepts are missing/overkill. Want to see where we can converge.
FR: Should we use the github issue to exchange views about this document https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack/files/7279772/Multi-Context_Concepts_OpenCMSIS.pdf
RK: Will start a new github issue.
DB: Very basic prototype https://github.com/brondani/devtools/tree/mvp-prototype/tools/projmgr