This commit includes
- Changing build option parameter from -O2 to -Os to reduce flash size of the
final binary pacakge.
The original parameter of -O2 is kept to circumvent the error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46762 .
But this error has been long fixed and released in latest 4.9.x GCC compiler.
This change is necessary to reduce the generated binary size of mbed Client component to
avoid problem of getting images over 512 kB which is causing application to crash because of
Configuration Store problem https://github.com/ARMmbed/configuration-store/issues/21
Create the wrapper class SingletonPtr. This provides a safe way to
declare and use singletons. This class allows both the lazy
initialization of a singleton, and allows the singleton to be
garbage collected by the linker if it is never referenced.
This patch also updates the HAL to use SingletonPtr when declaring
singleton mutexes.
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.
I would like to test that the Toolchains API remains stable. Therfore,
I have added a test to the travis CI that checks that each exposed
toolchain class implements the API that the mbedToolchain base class
uses to compile.
The test simply tries to instantiate each class exposed as part of the
TOOLCHAIN_CLASSES map. This is a test that each toolchain class
implements the required API, as the mbedToolchain will not allow the
instantiation of a subclass without a part of that API.
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.
This commit adds information about the location of problematic JSON
files when reporting a JSON parsing error.
Before this commit:
```
[ERROR] Expecting property name: line 7 column 9 (char 188)
```
After this commit:
```
Error parsing 'core/mbed_lib.json':
[ERROR] Expecting property name: line 7 column 9 (char 188)
```
Previously, add_py_targets assumed that it is not an error to add an
existing target if that target was previously added using
add_py_targets. This was done to aid testing, but it was weird, error
prone and broke with the latest changes to the caching mechanism. With
this commit:
- it is always an error to add a target that was previously added, which
is much more consistent.
- tests for the configuration mechanism use the newly added
'set_targets_json_location' function to clear the internal caches in
targets.py (and thus all previously added custom targets). As a side
effect, this commit also tests the 'set_targets_json_location'
function itself.
With this change, it becomes possible to use targets.py with any
targets.json, not just the default one in ../hal/targets.json.
targets.py will still be initialized with the default targets.json, but
the code can then call "set_targets_json_location" to specify the new
location of targets.json. set_targets_json_location modifies all the
data "in place"; that is, it doesn't create a new TARGET_MAP,
TARGET_NAMES or alike, but rather modified the existing ones. This is
important, because code using this construct:
from tools.targets import TARGET_MAP
can work unmodified with this change.
Now funnctions are looked up in the cache using a (function name,
arguments) key, which makes it possible to cache different invocations
of the functions (with different arguments).
Also applied the @cached attribute to get_target.