Currently we use a Typescript tool to convert YAML configuration files into CMake compilation options, and then build the firmware using this. This is not scalable as we have to include options for every driver and architecture and feature, etc. This is OK for some options, but for a highly configurable system, it is cumbersome and error-prone.
We need feedback on the following:
should the Typescript tool (y2kParser) be a hard dependency for firmware generation?
should the build tool be able to load arbitrary YAML, from any location, or must it be in the keyboard config repository?
should the Typescript tool handle generating intermediate files only, or also firmware compilation, etc?
The outcome of this card should be a design document for the journey of building firmware from config files. The design document should cover:
[ ] answers to the questions posed above, in this card
[ ] example scenarios
[ ] inputs and outputs of the y2kparser including any generated files
[ ] how our build tool for firmware will be configured and executed
[ ] a diagram showing a high-level overview of how components interact
Currently we use a Typescript tool to convert YAML configuration files into CMake compilation options, and then build the firmware using this. This is not scalable as we have to include options for every driver and architecture and feature, etc. This is OK for some options, but for a highly configurable system, it is cumbersome and error-prone.
We need feedback on the following:
The outcome of this card should be a design document for the journey of building firmware from config files. The design document should cover:
y2kparserincluding any generated filesBlocked by #2 and #3