Closed 0xc0170 closed 7 years ago
bump
Should we add non-public targets too? In this example, adding non-public targets would add "Target"
to the list of labels.
Ah yes, the ever useful TARGET_TARGET
:stuck_out_tongue_winking_eye: (in this particular case I don't think this would be too harmful, it could easily be ignored).
One advantage of having non-public targets be added to the list of labels would be for targets like the Nordic boards. For example: https://github.com/ARMmbed/mbed-os/blob/master/targets/targets.json#L1344
It would remove the need to have MCU_NRF51_16K_BASE
as the target name and also specify MCU_NRF51_16K
as an extra label. You could instead just name the non-public target MCU_NRF51_16K
. At least, this makes sense to me, @pan- may have some concerns about this though.
Should we add non-public targets too? In this example, adding non-public targets would add "Target" to the list of labels.
As I understand, by default a target is set to private (public: false). Thus in my code snippet above MCU_K22F is private and its label is not polluted. Is that correct?
This taken from 2488 referenced above:
Yes, we were actually supposing that also the parent targets' name would appear within the labels of the sibling(s) ;-).
I assumed the same. When creating MCU family port, you want to have that label available but target should be private (not able to use it with scripts as it can't be built for various reasons).
I find having to add extra label as a workaround. It was not obvious to us while we were creating a new MCU family in the tree and were receiving error like "device.h" not found .and like hey, MCU target is correct, why it cant find it. Thus I created this issue.
@0xc0170 A target is by default set to public (public: true) https://github.com/ARMmbed/mbed-os/blob/master/docs/mbed_targets.md#public
so hey everyone ( @0xc0170 @bridadan ), Is the 'add all parents except for Target
' option a viable strategy? If so, I could add that to targets.py to ease new board bring up.
I spent a few minutes trying to think of a time when this would cause problems and I honestly can't think of a case. It may even be useful to include the root Target
target, since you could then add extra_labels
to all targets trivially if necessary. Other people may feel differently about this though.
So seems like a good idea to me :+1:
any extra label added to Target is pretty useless, as the code that label guards will always be enabled.
Is the 'add all parents except for Target' option a viable strategy? If so, I could add that to targets.py to ease new board bring up.
I would say yes. The question to answer within this ticket is how hierarchy should look like (target inheritance). The above code snippet I provided, is this a valid use case ? I would say it is, at least for now ,thats how its done for various targets.
cc @sg- @geky for opinions - for the question quoted in this post
Description
Question
This code snippet illustrate the problem:
To make K22F work, I would need to add to extra labels
MCU_K22F512
to the targetMCU_K22F512
. It's not defined by default. But for a regular target like K22F it is, as I recall. I could not find any relevant info in the docs.cc @bogdanm @theotherjimmy @MarceloSalazar