* added/improved global chroot support
* added RESPONSE_FILES flag to support optional response files (on linux the cmd param length is 2 megabytes). Default True
* added unified handling for archive and link response file (similar to includes)
* added COMPILE_C_AS_CPP flag to support compiling of c files as cpp. Default False
* added mbedToolchain.init() for post __init__ hooks
* added caching to mbedToolchain.need_update() to reduce IO hits
* added support to identify compiler warning/error column (supports ARMCC, GCC and IAR). Errors/warnings now report file@line,col
* added global TOOLCHAIN_PATHS which allows overriding/changing of the toolchain paths. Also simplified ARM-related paths
* added target.json to mbed library release (by @0xc0170)* migrated compile_worker() to utils.py for lightweight thread initialization
* improved run_cmd() performance by removing unnecessary check about the command being executed (should be checked once in the relevant toolchain instead)
* removed remnants of Goanna support (should be reimplemented as hooks to compile/link/archive instead)
* fixes for Python 2.7 compatibility (by @0xc0170)
* fixes for Exporters (by @0xc0170)
It's nicer to be compatible with the standards.
I have added one more field to the description of each function:
Side effects. This feild contains the expected side effects of
running a particular method. If the side effects of a method are
None, it is expected that the function does not change anything in
any envoronment and that running it multiple times with the same
arguments will produce the same result every time. That is when
Side effects is non, the method is expected to be pure.
The methods themselfes do nothing within the abstract base class
mbedToolchain. This change enforces that toolchains do not call
these methods that contain no implementation.
The mbedToolchain class calls many members of it's subclasses, expecting
them to implement a particular API. This change adds a requirement to
each subclass that requires them to implement this expected API.
The API consists of these methods:
- parse_dependencies
- parse_ouptut
- get_config_option
- compile_c
- compile_cpp
- link
- archive
- binary
This commit adds a check for configuration data changes. If a change in
configuration data is detected, all the sources in the tree are rebuilt.
This is a fix for #2073. #2162 was originally proposed as a fix, but it
was agreed that `--preinclude` is a more convenient way to include
configuration data, since it can be used to change the behaviour of
source files that don't include "mbed_config.h" directly, which is a big
advantage when importing 3rd party source trees. Compared to #2162, this
commit has the disadvantage of rebuilding all the source files if a
configuration change is detected, but it was agreed that the advantage
of using `--preinclude` outweighs the disadvantage of the increased
compilation time.
- removing redundancy as discussed in PR #2087:
- in target.json the core option can have only this values : "Cortex-M0", "Cortex-M0+", "Cortex-M1", "Cortex-M3", "Cortex-M4", "Cortex-M7", "Cortex-A9" - Cortex-M4F and Cortex-M7F removed
- in target.json an additional fpu option with values: "single" and "double" can be used
- build and export scripts are changed to handle this
- tested (compiling, running on hardware) with nucleo_f767 (cortex-m7 with double precision fpu), nucleo_f746 (cortex-m7 with single precision fpu), nucleo_f446 and nucleo_l467 (cortex-m4 with single precision fpu), teensy31 (cortex-m4 without fpu - only build test), nucleo_l073 (cortex-m0)
- singletest results are added to PR #2087 comments
- creating new core name Cortex_M7F_DP for a target with a double precision fpu
- adding new core name to arm.py to set compiler/linker flags to a double precision fpu when configured in target.json
- up to now: gcc wrote flag for a double precision fpu -> target with STM32F746 didn't run when using double variables - mcu has only single precision fpu
- changing gcc.py to use single precision for Cortex-M7 und double precision for Cortex_M7F_DP
tested with NUCLEO_F746, NUCLEO_F767 and build.py+make.py and exporting with project.py + compiling/flashing
- iar.py need a similar extention - I didn't change that yet because
- did not run at the moment - python exception
- currently worked on in PR #1948
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.
For example .mbedignore in tools/ contains '*' and naturally should match all files, folders including tools/ itself. Without this fix, tools/ is added to the include path
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.
Sam Grove
Mihail Stoyanov
Bogdan Marinescu
0xc0170
Jimmy Brisson
Bogdan Marinescu
Przemek Wirkus
Olaf Hagendorf
Christopher Haster