Add all_configs make target to build all FC configs
To improve pre-merge testing this adds support for make configs_all to build all targets in the src/config/configs directory.
Do you want to test this code? You can flash it directly from Betaflight Configurator:
- Simply put
#13660(this pull request number) in theSelect commitfield of the Configurator firmware flasher tab (you need toEnable expert mode,Show release candidatesandDevelopment).
WARNING: It may be unstable. Use only for testing!
Warnings in the build are not obvious (fixed in 13659)
Should we add
BASE_TARGETSto line 468 instead ❓
That was my first thought but then all becomes onerous to build. Figured a separate make target was better.
Wondering what this is for...
If it is for a user to run through and do a build of all config targets... it will take forever... but I can see the application.
If it is for CI then it too will take forever, and as a consequence is undesirable.
The idea behind the configs and why we have CI_TARGETS is to pick a few select targets that give sufficient coverage for testing.
This is more a check on the config repository than betaflight. It does take a long time to run, but it's a good sanity check now and again.
It highlights that the DRONIUSF7 target is broken, for example.
./src/main/sensors/acceleration_init.c:99:2: error: #error At least one USE_ACC device definition required
And of course we can invoke it with EXTRA_FLAGS to simulate a cloud build too, thus:
make configs_all EXTRA_FLAGS="-D'BUILD_KEY=e96807233c7110836d297d663fc6b71c' -D'RELEASE_NAME=4.6.0-dev' -DCLOUD_BUILD -DUSE_ACRO_TRAINER -DUSE_DSHOT -DUSE_GPS -DUSE_GPS_PLUS_CODES -DUSE_HEADTRACKER -DUSE_LED_STRIP -DUSE_OSD -DUSE_OSD_HD -DUSE_OSD_SD -DUSE_PINIO -DUSE_SERIALRX -DUSE_SERIALRX_SBUS -DUSE_VTX"
might be a good PR "CI" check as well, like a unit-test, but not really. can be executed, but not a merge-requirement. :man_shrugging:
This is more a check on the
configrepository thanbetaflight. It does take a long time to run, but it's a good sanity check now and again.
I am ok with it in principle, but it should not become a "requirement" for a PR.
We do get existing sanity checks (all cloud builds that fail are posted to discord) - the benefit of this is that it is essentially crowd sourced and means only those in frequent use by users are tested (the crowd source in action).
Generally due to CI_TARGETS giving good coverage, we would only need to modify the config file, and all is good - unlikely to need core code changes.
DRONIUSF7
In this example it would almost be better to have a CI build step in the CONFIG repository - to ensure the config file compiles before it can be merged.
bump. i like this for local testing purposes. needs merge master or rebase.
Rebased.