Closed DunderRoffe closed 4 years ago
In general, good and easy to understand.
Consider to either move the bblayers-
(This should be a comment on the commit message. Github can not handle that, it seems.)
Restructure conf/variant/common -> conf/sample
Is it not a bit weird to call all our configuration's "samples"? I do not have a better suggestion though and we called them samples before as well. Or is it something from the bitbake world? Hum... feel free to ignore this comment. :)
It's from the bitbake world. The files have to be called bitbake.conf.sample and local.conf.sample
rebased on master
See https://github.com/Pelagicore/pelux-manifests/pull/474 for suggestion on how to do CI for this solution
Closing due to inactivity
This is a suggestion on how to restructure the variant system to reduce duplication when adding new variants and hardware. I do NOT want this to be merged. I just want feedback.
Overview
In this setup we only have special files containing bblayers for bsp or features (such as QtAuto). Everything else is either located in sample/local.conf.sample or classes/core-image-pelux.bbclass
Benefits of this solution
Meaning using this setup it is possible to add support for a new hardware and only have to add one bblayers-new-hw.conf file in order for the new hardware to be able to use all features (such as qt-auto). The same goes for features (since they are basically the same thing).
Easier to understand what is tweakable as all is in the same local.conf file
Drawbacks of this solution are:
Two additional manual steps are now required to setup pelux bitbake:
Unknowns
This solution does not offer the possibility to treat arp as a separate thing out of the box as there is no MACHINE called arp (and there should really not be either). One idea to solve this is to treat arp as a "feature" and added using dynamic-layers when meta-arp is present like we do with QtAuto.
Required future work: