Tools: Scan for "components"

[theotherjimmy]

Description

Requested by @sg-

Creates the COMPONENT_ scanning rule to match the target.components,
target.components_add and targets.components_remove configuration values.

@sg- to provide justification

Pull request type

[ ] Fix
[ ] Refactor
[ ] New target
[x] Feature
[ ] Breaking change

[sg-]

Great, naming TBD but otherwise looks great 👍

[theotherjimmy]

@sg-, when you say naming TBD, are you referring to the scan rule? the config variables? both?

[sg-]

@sg-, when you say naming TBD, are you referring to the scan rule? the config variables? both?

both

[bulislaw]

I think we need a strong documentation to match these changes. It'll confuse people, we should explain what's the difference between feature and a component.

[SeppoTakalo]

I'm unsure is this really needed.
Feels like we have too many different ways to selectively compile things in. For example, what this PR achieves, could have been done by just target.extra_labels_add which is what our test application used for a while.

(Sorry, not public links)

• https://github.com/ARMmbed/mbed-os-cliapp/tree/master/libs contains "components" but using name TARGET_*
• Enable the component: https://github.com/ARMmbed/mbed-os-cliapp/blob/master/mbed_app.mesh0_atmel.json#L41

If I could vote on this design, I would have gone to direction where we use more generic ways of flagging buildable stuff. For example all TARGET_*, TOOLCHAIN_* and FEATURE_* could be just using one single build rules. Now FEATURES and TARGETS use different rules, and behave little bit differently. FEATURES cannot be nested but TARGETS and TOOLCHAINS can. How about COMPONENTS?

[theotherjimmy]

@SeppoTakalo

If I could vote on this design,

Luckily, your info is out of date:

would have gone to direction where we use more generic ways of flagging buildable stuff.

If you look at all that I changed to add another one, it's pretty generic.

For example all TARGET_, TOOLCHAIN_ and FEATURE_* could be just using one single build rules.

This is currently the case.

FEATURES cannot be nested but TARGETS and TOOLCHAINS can. How about COMPONENTS?

All scan rules can be nested on current master branch. Give it a shot!

[0Grit]

@theotherjimmy I assume components refer to "on board" components versus "on die" components?

[0Grit]

@theotherjimmy also are component sources intended to exist within mbed-os or externally?

[cmonr]

@SeppoTakalo @loverdeg-ep If it helps, this is an example use case of why having this descriptor would help: #7774

[cmonr]

@sg- @bulislaw @theotherjimmy Any more thoughts on the naming, since it this PR has been open for a while? Imo, "Components" seems a bit too generic, but I also don't have any better suggestions.

@theotherjimmy Be advised this still needs to pass Travis.

[bulislaw]

Looks good. That needs to be documented in Handbook including some guidance what belongs in TARGET, FEATURE, COMPONENT and TOOLCHAIN even if you think it's obvious.

[adbridge]

@theotherjimmy could you please respond to @cmonr comments ?

[0Grit]

Would the build system support using this scan rule to have a "target support package" pull a sensor driver, for example, from an external repository?

My thinking,

• For boards with particular sensors the current required approach is to bring the sensor driver in as part of the application.
• I'd prefer the BSP pull in recommended/default sensor drivers from an external repository.
• I want to reduce redundant effort as much as possible by taking BSP/target support very literally

Probably wandering a little too far down a side road, but this is what I want as a user.

[0xc0170]

@theotherjimmy What is the status ? There are few dependent PR targeting also 5.10 release. Documentation PR?

[cmonr]

Making a note here that this is a dependency for #7774, which will need some TLC to get in.

[theotherjimmy]

@cmonr @0xc0170 @adbridge I can't answer any questions about how I intend this to be used, because I don't know the answers. @sg- should be asked instead.

[cmonr]

/morph build

[mbed-ci]

Build : FAILURE

Build number : 2935
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7644/

[cmonr]

Wow. License issue.

/morph build

[mbed-ci]

Build : ABORTED

Build number : 2936
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7644/

[cmonr]

Looks like something's happened to the ARM compiler license server.

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 2937
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7644/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 2555
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/7644/

[mbed-ci]

Test : SUCCESS

Build number : 2686
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/7644/2686