extra_labels_add broken

[markus-becker-tridonic-com]

Extra labels on an inheriting target via extra_labels_add remove the extra labels of the mother target.

This manifests then in device.h not being found during compilation.

@MarceloSalazar

[markus-becker-tridonic-com]

same for macros_add.

[0xc0170]

cc @bogdanm

[bogdanm]

Can you please add instructions to reproduce this?

[markus-becker-tridonic-com]

Adding e.g. to targets.json

    "OUR_F4_TARGET": {
        "inherits": ["NUCLEO_F401RE"],
        "default_toolchain": "GCC_ARM",
        "extra_labels_add": ["OUR_F4_TARGET"],
        "macros_add": [
            "MBED_CONF_TRIDONIC_LED_GREEN=PA_2",
            "MBED_CONF_TRIDONIC_LED_YELLOW=PA_3",
            "MBED_CONF_TRIDONIC_LED_RED=PB_10"
        ]
    },

does not seem to have the extra_labels from NUCLEO_F401RE, but only OUR_F4_TARGET.

For the macros we inherit further:

    "OUR_F4_TARGET_WIRELESS": {
        "inherits": ["OUR_F4_TARGET"],
        "extra_labels_add": ["OUR_F4_TARGET_WIRELESS"],
        "macros_add": [
            "MBED_CONF_ATMEL_RF_SPI_MOSI=PB_15",
            "MBED_CONF_ATMEL_RF_SPI_MISO=PB_14",
            "MBED_CONF_ATMEL_RF_SPI_SCLK=PB_13",
            "MBED_CONF_ATMEL_RF_SPI_CS=PB_12",
            "MBED_CONF_ATMEL_RF_SPI_RST=PB_1",
            "MBED_CONF_ATMEL_RF_SPI_SLP=PB_5",
            "MBED_CONF_ATMEL_RF_SPI_IRQ=PA_11",
            "MBED_CONF_ATMEL_RF_I2C_SDA=PB_3",
            "MBED_CONF_ATMEL_RF_I2C_SCL=PB_10"
        ]
    },

then MBED_CONF_TRIDONIC_LED_GREEN is gone.

[MarceloSalazar]

@bogdanm are you able to reproduce?

[ciarmcom]

ARM Internal Ref: IOTMORF-425

[theotherjimmy]

@markus-becker-tridonic-com I did as you suggested, reproducing a problem (but not the one you were describing, I think). I was able to work around it by replacing the "extra_labels_add": ["OUR_F4_TARGET"], with "extra_labels_add": ["NUCLEO_F401RE"], Could you try this on your end?

I used this command python tools/build.py -t gcc_arm -m OUR_F4_TARGET -c -v --silent | grep TRIDONIC_LED_GREEN -c if it reports a number greater than 0, you have compiled that many files with the TRIDONIC_LED_GREEN macro.

[theotherjimmy]

I think what you are actually seeing is not that extra_labels_add is broken, but that the 'mother' target's label is not added to the labels of the child. This prevents mbed from compiling as some necessary code is contained within a folder named TARGET_NUCLEO_F401RE, which will not be picked up by either of your new targets.

[MarceloSalazar]

@javier-moreno-tridonic-com @daniel-cesarini-tridonic-com would you be able to help here?

[daniel-cesarini-tridonic-com]

@theotherjimmy what is the intended behavior of the "inherits" keyword?
We were considering it as a statement of inheritance between subsequent target definitions, thus inheriting also the labels and macros/pin definitions from "mother" targets.

[theotherjimmy]

@daniel-cesarini-tridonic-com The Inherits keyword makes all cumulative attributes (extra_labels, macros, device_has, and features) use the inheritance hierarchy to resolve their values. Further, it makes all non-cumulative attributes default to the value of the most recent ancestor's value.

The labels of a target is generated from the name of the target plus it's extra_labels, after all cumulative attributes have been applied to extra_labels. Do you expect the names of the parent targets to appear within the labels as well?

[daniel-cesarini-tridonic-com]

We are now using what you suggested: it is working by adding the "mother" target name as an "extra_label_add".

Yes, we were actually supposing that also the parent targets' name would appear within the labels of the sibling(s) ;-).
@theotherjimmy thank you for the help! :-)

[bogdanm]

Can this be closed?