Date
Participants
Slides
Notes
Potential *.yml structure
FR: Does it mean in this flow the CPRJ is a temporary artifact?
RK: Can view it as a temporary file but can copy it and run a rebuild process without the project manager. An interim format not intended to be edited by users but can import/export it.
RK: Need a manual command line flow and an IDE flow. Daniel has prototyped this.
CMSIS Project Manager - MVP Prototype
DB: Link https://github.com/brondani/devtools/tree/mvp-prototype/tools/projmgr
FR: everything works based on $CMSIS_PACK_ROOT ?
DB: Yes. If not set it takes the default based on the platform Win/Mac/Linux
FR: Do you expect to give the option to locate the packs we want to use?
RK: Yes we need to define a way to be flexible how you locate the packs.
RK: Tool is written in C++ using CMSIS devtools libraries. It’s an experiment at the moment. Important to know if there are some requirements that are not fulfilled.
LM: Would expect from the project manager that it would give a list of components active in the project - a more “project active” view - a relationship with cpackget.
RK: Yes this is correct. It’s a very early proof of concept.
DB: Yaml.cpp parser used. In this case json is a strict subset. Can submit json and the tool just works.
RK: Did anyone review the ST requirements
DJ: Passed to colleagues at NXP - not responded yet.
RK: Need to see how our concept and ST’s requirements align. Also need feedback from NXP.
DJ: When do you want to publish this in the project scope to be reviewed by members?
DB: Need to clean it up and add some test cases and documentation. Then it will be able to be added into the main branches (link repeated: https://github.com/brondani/devtools/tree/mvp-prototype/tools/projmgr )
EF: Can we take 5 minutes to align on the discussions on GitHub
RK: My understanding is that the CPRJ file meets the requirements.
SH: Not solving the usecase of defining project in a flexible way. Want to keep the packs I’m using at a specific time. Have a definition of what you care about and what you are using. Also want to distribute it to colleagues.
RK: Project manager simply lists the files that composes the project. Is the CMSIS tool able to give the list of packs that it used.
DB: There is an audit file. In the fixed version it creates a new CPRJ that can be used to reproduce exactly that build. In Samuel’s version it would keep the log file separate from the CPRJ.
SH: The issue with locking things down is it becomes annoying to update packs. Could we also have the condition present in the log file. If add a component it may make other components resolve differently. Want to be able to see this. Log file is output. I need something that is input to the process.
DB: What’s the workflow to generate it?
RK: W ant to generate it in one run and then subsequently use it to see if something has changed. Could distribute it to colleagues and get them to use diff.
FR: Regarding the matching between our concepts and the flow : no major disconnect as immediate feedback. But we need to dig into how you plan to manage resources partitioning (~azone files) and also the direction for packs management (¨CMSIS_PACK_ROOT versus project-defined settings). Can't we have an option to say if we want to generate a "locked" cprj or "open" one ?
Feedback on Handlebars
RK: Doesn’t matter that it’s written in Java - JRE no longer an issue.
FR: What does it mean “missing evaluation language”?
RK: Saw this in comparison vs ‘Moustache'.
FR: Can have a further look at the file.
RK: Need to compare the two options more closely. This is initial feedback.