The introduction of pretty-bar had broken the handling of
"mbed compile"'s "--stats-depth" argument. No matter what one gave
as parameter to it, the result output is just using the default 2.
Fix the logic in build_api.
Looks like this:
Building project mbed-os-prettyoutput (ARCH_PRO, GCC_ARM)
Scan: .
Scan: env
Scan: mbed
Scan: FEATURE_LWIP
Text 70.5KB Data 2.72KB BSS 7.43KB ROM 73.2KB RAM 10.1KB
ROM [||||||| ] 73.2KB/512KB
RAM [|||||||||||||||| ] 10.1KB/32KB
Image: BUILD/ARCH_PRO/GCC_ARM/mbed-os-prettyoutput.bin
If you build a target without a cmsis-pack it looks like this:
Building project mbed-os-prettyoutput (ARM_BEETLE_SOC, GCC_ARM)
Scan: .
Scan: env
Scan: mbed
Scan: FEATURE_BLE
Text 99KB Data 2.84KB BSS 13KB ROM 102KB RAM 15.8KB
Image: BUILD/ARM_BEETLE_SOC/GCC_ARM/mbed-os-prettyoutput.bin
And the old behaviour of displaying the memap table can be brought back
by passing the --stats-depth parameter
Build api used to build cmsis separately (how mbed 2 is being build). This is
currently not how cmsis is being defined. As there target dependencies in some
cases, we should include paths from targets when building cmsis
If map file parsing fails then memap_instance is set to None. To
prevent a traceback when parsing fails check if this is None before
trying to access any of its fields.
Removed heap/stack from report
Add --stats-depth option to mbed compile
Fix minor issues identified in review
Fix bug when parsing armcc libs
Fix code style
Fix minor issues on existing tests
Fix memap for automated TESTS
Fix stats-depth parameter for tests
I accidentally broke only uARM mbed 2 builds. Here is the story: When
scanning for resources, toolchains look for any `TOOLCHAIN_<classname>`
folders to include. These `<classname>`s mostly match the name passed in
on the command line with one exception: `uARM` on the command line maps
to `ARM_MICRO` the class. This would not be a problem except for the bug
that I introduced in a prior commit. The bug is that the mbed2 library
builds will use the name passed in on the command line to construct
`TOOLCHAIN_<cli-name>`. This will not match when scanning.
I fixed it by translating the `<cli-name>` into the `<classname>`.
An earlier patch in this series relies on the assumption that all
toolchain construction goes through `prepare_toolchain`. This is still
not the case. The only remaining user of the `mbedToolchain` object that
does not go through `prepare_toolchain` is the static analysis scanner.
It's basically dead-code at this point. I say we remove it. So this
patch removes it.
The prior patch in this series makes the assumption that any building
will go through `build_api.prepare_toolchain`. This was not a valid
assumption for the mbed2 build process. So, instead of maintaining 2
ways of using the toolchain classes, I elected to unify on
`prepare_toolchain`.
This is a bug fix for the following bug (Github issue #437):
If two builds were run specifying a non-default build folder, the second
build would fail to link with duplicate symbols and may not fit on the
device. The root of this problem is that these non-default build folders
are not ignored by scan-resources, and therefore included in the build.
We fix this bug by ignoring the build directory passed into the tools.
To enable a boot-loader style application, override
"targets.bootloader_exec" or "targets.restrict_size" on a particular
target. These parameters are a bin or hex file, and an integer, in bytes,
respectively. If either override is present, then an application region
is created after the boot-loader region, when "targets.bootloader_exec"
is present, and before post-application, when "targets.restric_size" is
present. The size of the boot-loader region is read from the file
provided in the configuration.
Before, the get_config function was checking the equality of a set and a
list. However the list's equality depends on order, so this change casts
it to set to prevent an infinite loop.
Added single-nested include directories to libraries built with the
legacy build_lib function. Unfortunately, to get this working without
a significant rewrite of the legacy build tools, library header files
are just duplicated in the precompile stage.
Makes several broad changes:
- removes dead code that dealt with the online build system
- replaces export function with a much simpler one that:
- does not copy any sources
- the zip file hits the disk
- the mbed_config.h hits the disk
- the project files hit the disk
- nothing else hits the disk
- exporters use Resource object scanned with a toolchain
- progen exporters don't optionally build a project instead they have a
build function that may be called afterwards
- much of the code passes pylint (have a score of 9 or above):
- project.py
- project_api.py
- export/__init__.py
- export/exporters.py
- test/export/build_test.py
This came up when building tests, but affects any library that's built
that uses config and included as "source" with the mbed tools.
JSON files are not copied by default when building a library, so when this
is built it loses the config data associated with the library. This commit
copies all JSON files into the build directory when building libraries.
This leads to two mbed_config.h files existing if the build directories
are different between the library and application build. This is the case
when building tests, so an option build_library was added to remove the
mbed_config.h file when compilation is done. This disabled by default when
building libraries, but it is enabled when building tests.
`build_lib` wasn't aware of configuration data, so some of the source
files that depends on configuration data fail to compile. This commit
fixes that by making `build_lib` aware of configuration data.
Previously, build_mbed_libs didn't take into account the configuration.
This is a problem when doing a binary release, since mbed_lib.json
contains configuration data relevant to the binary release.
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.
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.
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.
The configuration object is now created early in the build_project
function. This way, if there's a mbed_app.json that contains a custom
target, that target is taken into account. This is useful (for example)
when compiling tests for an application that defines a custom target.
The IAR assembler doesn't accept '--preinclude', but it accepts -D.
This commit changes the way the config-related macros are propagated
to the IAR assembler to use '-D' instead of '--preinclude'. This is
the only change related to functionality, the others are small,
backward compatible changes to the config code to make passing arguments
to the toolchain instances easier.
Tested by compiled blinky with IAR, GCC_ARM and ARM for K64F.
This commit uses the previously introduced feature of generating
configuration data as a C header file rather than as command line macro
definitions. Each toolchain was modified to use prefix headers if
requested, and build_api.py was modified to set up the toolchain's
prefix header content using the data generated by the config system.
Tested by compiling blinky for GCC and ARMCC. I'm having a few issues
with my IAR license currently, but both ARMCC and IAR use the same
`--preinclude` option for prefix headers, so this shouldn't be an issue.
Note that at the moment all exporters still use the previous
configuration data mechanism (individual macro definitions as opposed to
a prefix header). Exporters will be updated in one or more PRs that will
follow.
Previously, .hex files were not copied when building source as a library.
This prevents builds that pre compile source as a library and then
includes the build directory as the only source (because there is no
softdevice present). This PR copies hex files when compiling source
as a library.
Cruz Monrreal
Cruz Monrreal II
Jimmy Brisson
Andrew Leech
Laurence de Bruxelles
Anna Bridge
Christopher Haster
Tero Jääskö
Martin Kojtal
TomoYamanaka
Russ Butler
Marcelo Salazar
lordguilly
Bartek Szatkowski
Sam Grove
Michael Bartling
Brian Daniels
Conor Keegan
Sarah Marsh
Vincent Coubard
Bogdan Marinescu
Mihail Stoyanov
0xc0170
Przemek Wirkus