The function headers have been updated to follow the standard format
that should be being used for tools in mbed. This is a one line summary
followed by a descriptive block with more detail.
Updated the handling of the main function so that the logger becomes
global and thus works across all the functions. This has been tested
with both the fork and branch options, and for levels INFO and DEBUG.
Added the ability to specify a branch to update rather than a fork
Replaced print commands with the use of a logger
Updated the run_cmd functions in line with previous improvements
I also broke the config header template into it's own file. Further, I
fixed a bug in the config header generation where if no macros, builds
would crash.
The traceback was caused when a file without a parent directory (which
is implicitly ".") is added to the resources object. The code assumed
that all files within the resources object would have a parent
directory.
This commit changes the check to account for files that are in the root
directory of a project and have no preceding `./`
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 😉.
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.
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.
Resolves the github issue #3790: Blinky fails to build (on Mac) after
addition of linker script preprocessing feature. Paraphrasing, this
issue is that Homebrew on mac does not install `arm-none-eabi-gcc` in
the same location as `arm-none-eabi-cpp`, the C Pre-Processor. The tools
prior to this commit, and after turning on the pre-processing of the
linker-script will fail on any Mac homebrew installed toolchains.
This commit resolves the above issue by allowing the toolchain's path to
the executable to remain empty after a call to `check_executable`. When
this path is empty, the tools will search the PATH environment variable
for the executable.
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>`.
Daniel Zimmermann
Andrzej Puzdrowski
arostm
Alexis ROCHE
Jimmy Brisson
Martin Kojtal
adbridge
Jan Jongboom
Matteo Italia
Brian Daniels
0xc0170
Głąbek, Andrzej
Willie Walker
Seppe Stas
Tony Wu
Phyo Kyaw
Russ Butler