When using a standard library which does not support multi-threading
allow only one thread to be used. This allows the code to remain
safe.
This also pulls up on the mbed library to use this change:
df0c855df9...5acdad9fd7
This commit integrates configuration data with exporters, in a similar
way to the integration in build_project or build_library in
tools/build_api.py.
Only a very simple test was done for this PR: define a configuration
parameter in the mbed_app.json of a blinky example, export it to uvision
and check if the corresponding macro made it into the project file. If
there are better tests to be performed, please let me know.
There was an issue when compiling with GCC_ARM, the tools would
print the incorrect file where the error was present. This modifies the
regular expression and matching logic used to find the error. This was
tested with the 4.9 q2 release of GCC ARM.
get_config.py can be used to view the configuration of the mbed project
that's being compiled:
- without '-v' it displays a simple list of configuration parameters and
their values
- with '-v' it displays additional data for each configuration parameter
(like the place of definition and the last place that set a value for
the configuration parameter).
Tested by running "get_config.py" on a few tests from
tools/test/config_test.
The tests check a number of features of the configuration mechanism
(mostly the inheritance and overriding of configuration parameters), as
well as the behavarious in various abnormal situations.
This commit adds the implementation of the configuration mechanism and
applies it for two uses cases:
- building a program (build_project in build_api.py)
- building a library (build_library in build_api.py)
There's also a new method 'get_config' in build_api.py that's used to
return the configuration of a project. Currently, it's used only for
testing, the intention is to use it for the implementation of the 'mbed
config' command.
Tested with various test configurations on the "blinky" example and also
with its own set of tests (to be added in a separate commit).
'make.py' was modified to send the target *name* to build_project, as
opposed to the target *instance*. This is needed because the
coniguration mechanism allows for creating custom targets, but these
targets are not available until the configuration file
mbed_app_config.json is parsed, which happens in build_project (so
before make.py calls 'build_project'). The API of build_project didn't
change, it now accepts both target names and target instances for the
'target' argument.
Known issues:
- doesn't currently work when doing binary builds of the SDK. Currently,
building the SDK is broken in mbed-os, so this will be added later.
- when building tests, the build process ends up calling
'build_project', so the configuration mechanism should play well with
tests. However, this wasn't tested.
A later commit will all documentation for the configuration mechanism.
- added a method that can be used to new targets dynamically (this
will be used by the configuration mechanism).
- the JSON parser now keeps the order of the keys read from the JSON
file (will also be used by the configuration mechanism).
- there's now a global target cache in targets.py, so that a target
with a given name will only be created once.
There was an issue where the binary name was incorrectly set when building
from any directory that isn't the project root. This fixes that issue by
first getting the absolute path, then finding the binary name using that.
Pull in mbedmicro/mbed. Make the following changes in addition:
- Ignore unused directories in mbed
- Add stub mbed-drivers/mbed.h for backwards compatibility
- Remove targets.json and instead use mbed's version
Russ Butler
Mihail Stoyanov
Mihail Stoyanov
Christopher Haster
Niklas Hauser
Brian Daniels
Sam Grove
Bogdan Marinescu
Marcelo Salazar
Martin Kojtal
Bogdan Marinescu
Jimmy Brisson
Russ Butler