Details
-
Task
-
Resolution: Done
-
P3: Somewhat important
-
None
-
None
-
8
-
QUL Sprint 1.5/2022, QUL Sprint 1.6/2022
Description
Currently McuPackage is an abstraction that loosely represents a 3rd party dependency. Some dependencies are implicitly set up in the Kit creation functions of McuSupportOptions.
Currently the McuSupportPlugin:
- creates a special McuPackage representing the SDK itself
- pre-generates a list of packages, and reads their values from the QtCreator configuration if exists
- parses json files with kit descriptions, and fills in a McuTargetDescription structure
- matches some loose data from the json files with the pre-generated packages, filling-in missing data with own hard-coded information, and inferring some of the information from other missing data
- Creates McuTarget objects, based on the combination of the packages with the inferred info. When creating these, some new packages are also created on-the-fly.
- The information displayed in the dialog is based on the packages as owned by a given target. Later kits can be created based on that as well.
Should be:
- "Packages" should be rethought as representing one variable each. It could be an environment variable, a cmake variable, a path entry, or something else.
- Each one of those "variable containers" has a separate ID, user-facing description, actual variable name (as needed by cmake), current value, default value.
- They are created "on-demand" as parsed from json, not pre-populated. Since each has a unique ID, they can be stored in a pool and pulled from there when needed if they are used by more than one "target"
- the information that goes inside one has to be pulled from the json kit descriptions, not hard-coded.
Attachments
There are no Sub-Tasks for this issue.