Makefile.features: add driver_% provided features and FEATURES_REQUIRED_DRIVERS#12952
Closed
fjmolinas wants to merge 7 commits intoRIOT-OS:masterfrom
Closed
Makefile.features: add driver_% provided features and FEATURES_REQUIRED_DRIVERS#12952fjmolinas wants to merge 7 commits intoRIOT-OS:masterfrom
fjmolinas wants to merge 7 commits intoRIOT-OS:masterfrom
Conversation
Contributor
Author
|
NOTE: github is not showing the commit history in the proper order. |
384a4b6 to
8d135bc
Compare
Drivers can now be required by an application by setting FEATURES_REQUIRED_DRIVERS += driver_%. This allows avoiding running tests or compiling applicaitons for boards that don't have the necessary BSP or driver integration. Since drivers/% code should be BOARD independent FEATURES_REQUIRED_DRIVERS is not included in the dependency resolution by default. To include INCLUDE_FEATURES_REQUIRED_DRIVERS must be set. This keeps the same default behaviour for `info-boards-supported`. This way the application code is still compiled for all boards.
BOARDS can know provide driver_% features to specify that a specific driver is wired to the BOARD. Since they all translate into a MODULE we include that MODULE by default when the driver FEATURE is USED.
Add an extension of pba-d-01-kw2x which declares itself as providing driver_grove_ledbar so at least one board is supported by the application when calling: `INCLUDE_FEATURES_REQUIRED_DRIVERS=1 make info-boards-supported`
8d135bc to
07ba51b
Compare
Contributor
Author
|
Rebased with #12183 in. |
Contributor
Author
|
Splitthe |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
Contributor
Author
|
I still like this.. |
5 tasks
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contribution description
Drivers can now be required by an application by setting
FEATURES_REQUIRED_DRIVERS += driver_%. This allows avoiding running tests or compiling applications for boards that don't have the necessary BSP or driver integration.Since drivers/% code should be
BOARDindependentFEATURES_REQUIRED_DRIVERSis not included in the dependency resolution by default. To includeINCLUDE_FEATURES_REQUIRED_DRIVERSmust be set. I did not include them by default becausemurdockcurrently relies oninfo-boards-supportedto decide when to build an application. If included by default a lot of test applications could be built by only a handful, one or no BOARD at all. IMO we wan't to compile on at leat on board of every arch to verify code portability.This is done so that the test applications are still built for all boards in architectures, if not we could have driver tests that are only built for one application.
This still allows setting
INCLUDE_FEATURES_REQUIRED_DRIVERSso only when the required BSP is supported the application is compiled or tested, e.g.I used the feature on
tests/driver_grove_ledbar. I chose that applicator because it's a driver test with an automatic script and because noBOARDactually has the driver integrated so I could show how #12183 could be used to still have a supportedBOARDfor the test.Testing procedure
Review should be focused on commits f6efa41and 4ad994b, 8d135bc and 684ae17 show a use case.
The first commits are showcasing how we can handle cases where no
BOARDsupports the driverFEATURE. c895b44, 76a7e87, 8cb5e10 are some modifications/extensions I had to do to #12183. Will PR them to that PR.This PR wants to introduce the concept of required drivers, migrating applications would be done on a second step.
I would be happy to document this more extensively, but I think the place for this would be the same one as for #12473. I could extend that PR afterwards.
make -C tests/driver_grove_ledbar/ info-boards-supported --no-print-directory
INCLUDE_FEATURES_REQUIRED_DRIVERS=1 make -C tests/driver_grove_ledbar/ info-boards-supported --no-print-directory
Issues/PRs references
Doesn't depend but is currently using #12183 to show how to handle bordercases.