Now "all" depend on the project merged with the soft device,
the goal merged has been renamed into the file it generate and now depend
on the realization of $(PROJECT).hex
At some point, the actual code that did the "clean" for build_library was
removed. This also affected building and cleaning tests. This adds this
capability back to the build API.
Unlike other libraries, uvisor is currently integrated into the build
system, with special cases based on its addition as a feature. This
suggests we should also have tests for these special cases.
Previously a scanning for config terminated on comparison of the feature
set, however at some point the set was changed to a list. This resulted
in non-deterministic failures based on list order.
Except for IAR, it does not support the --preinclude option for assembly
files but all of the other exporters can. It was less code to remove it
in IAR than to explicitly add it in all of the other exporters.
This PR enforces that the default_build in a target's definition in
hal/targets.json is set to standard to be included in the version 5
release.
This is being enforced because small builds do not support
multi-threading. This makes the capabilities more consistent across all
boards in the version 5 release.
NOTE: This removes the MOTE_L152RC and the LPC11U68
from the version 5 release list because the 'default_build' for these
targets is currently set to 'small'.
The key 'release' in hal/targets.json is ambiguous. This changes the key
to 'release_versions' to emphasize that the entries should be version
numbers/strings and that it should be an array, not a singular value.
This modifies the behavior of 'mcu_toolchain_matrix' in build_api.py. It
now prints release version support in the matrix. It also defaults to only
showing targets in mbed OS 5. You can still show older release versions by
modifying the 'release_version' parameter of the function.
Previously, the condition for including a target in a release was decided
by a 'release' key being set to 'true' in hal/targets.json. This doesn't
have enough granularity when we release multiple versions of mbed. This PR
changes the 'release' key to an array of strings, where each member is a
version that the target supports. Currently the valid versions are '2' and
'5'.
This PR also adds more robust checking for invalid target configurations
in a release. This is enforced whenever the release list is built from the
data, preventing invalid targets from coming into the release.
Finally, it updates the build_release.py script to use the new api for
fetching release targets.
Move the library files used by both nanostack and client into a common
location. This allows both client and nanostack to be built stand-alone.
The patch moves the following libraries into a common location:
-mbed-client-c
-mbed-client-randlib
-mbed-trace
-nanostack-hal-mbed-cmsis-rtos
-nanostack-libservice
-sal-stack-nanostack-eventloop
And moves the library 'coap-service' from client into nanostack.
Previously, test discovery throught test.py used its own logic to find
tests. This was mostly a subset of the rules used during the build
process. It respected .mbedignore files, but it did not respect TARGET_,
TOOLCHAIN_, and FEATURES_ directories. This change now uses the same logic
used during building to respect these folders. Tests under these folders
that are not being pulled in for the given target will be ignored.
Due to dependencies between the config/target systems, the config
has been modified to preparse the mbed_app.json for overrides.
This means that attributes with dependencies in the targets are
only valid at the application level. A hard error has been
added for these attributes if they are supplied at the library
level.
Modified '_process_config_and_overrides' to update cumulative
attributes based on cumulative overrides found during walking config
files.
This should remove most of the disparity between the config target
cumulative overrides and cumulative attributes set in targets.json.
These cumulative overrides are updated after the global target
instantiation though, which may cause internal build tool state
dependent on cumulative attributes to not correctly reflect all
cumulative overrides.
In tools/config.py, Config now aggregates all cumulative attributes in
target overrides.
{
"target_overrides": {
"K64F": {
"target.features_add": ["UVISOR"],
"target.extra_labels_add": ["UVISOR_SUPPORTED"],
"target.macros_add": ["UVISOR_MACRO"],
"target.device_has_add": ["UVISOR_HAS"]
}
}
}
Note: no action is performed on overrides yet