The input format is now determined by the OUTPUT_EXT key in
targets.json, and defaults to "bin" when not specified. This changes the
Teensy3_1 and the NRF51x targets' post bulid hooks.
Teensy3_1 just converted to intelhex, so we do nothing instead.
NRF51x assumed that it was taking in a bin format file. I made it detect
file type by extension.
The extra space between "--no_wrap_diagnostics" and "-e" is inconsistent with the development and release targets.
It bugs people (like me) that have little OCD tics 😉.
targets.json contained a key for some targets, `OUTPUT_EXT`, which I
moved to `Target`, the root of all targets. Following on that, the tools
now use this extension provided by `OUTPUT_EXT` to determine the file
type of the output executable.
Check in scripts which are able to generate flash algos for supported
targets.
To initially download all packs the following command should be run:
"python extract.py --rebuild_all"
After that all supported targets can be rebuilt by running:
"python extract.py"
Finally, to rebuild an individual target you can used its pack name:
"python extract.py --target STM32F302R8"
Before, the types were not checked and just expected. The old behavior
would cause lots of tracebacks, or, much worse, convert things like:
```
{
"target_overrides": {
"*": {
"target.macros_add": "CONFIG_GPIO_AS_PINRESET"
}
}
}
```
into a definition of each of the letters as macros that expand to
nothing, causing massive compilation problems.
I resolved this by adding some type checking to the config data. Now
there is a type check for most of the fields within a library and
application configurations.
The file `project_api.py` was poorly named and caused much confusion.
Given that it was actually a front end to the exporters, I put it into
the export sub-dir.
When constructing a toolchain for export, we currently set the
`build_dir` to the `export_dir`. When exporting offline, the
`export_dir` is always set to the root of the project. The toolchains
ignore their `build_dir` when scanning for sorces, so when the exporters
use the toolchains to scan for their resources, they get nothing.
In this patch we set the `build_dir` of the toolchain that the exports
use to nothing. A path of nothing should not match anything, and will
therefore not ignore everything when scanning for resources.
Add an 'all' parameter to get_flash_algorthim_binary. When set
an enumerator of all flash algorithms is returned. rather than just
the first flash algorithm.
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>`.
Fixed results output summary.
General tidy up of long lines.
Added a new field to json file, target_list, to allow the user to
override the set of targets used for the compilation.
Sam Grove
Anna Bridge
Jimmy Brisson
Willie Walker
Seppe Stas
Tony Wu
0xc0170
Russ Butler
Phyo Kyaw
Martin Kojtal
Głąbek, Andrzej