Currently when checking if the destination branch already exists the
command 'git branch' is used. This only returns local branches. What is
actually required is the list of remote branches. This can be obtained
by the command 'git branch -r' and filtering the result.
Wipe out all blank lines in json:
find tools/test -name 'test_data.json' | xargs sed -i -e '/^$/d'
Move all start braces back a space:
find tools/test -name 'test_data.json' | xargs sed -i -e "s/^ {/{/"
Removed heap/stack from report
Add --stats-depth option to mbed compile
Fix minor issues identified in review
Fix bug when parsing armcc libs
Fix code style
Fix minor issues on existing tests
Fix memap for automated TESTS
Fix stats-depth parameter for tests
Previously if updating a branch in the ARMmbed version of an example
repo, the branch would be created initially from master. This update
allows the new branch to be created by any pre-existing branch.
This update also moves the branch / fork / tag configuration data to the
json config file. It thus simplifies the command line.
-b on its own now indicates use the branch information in the config
-f on its own now indicates use the fork information in the config
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
This is a bug fix for the following bug (Github issue #437):
If two builds were run specifying a non-default build folder, the second
build would fail to link with duplicate symbols and may not fit on the
device. The root of this problem is that these non-default build folders
are not ignored by scan-resources, and therefore included in the build.
We fix this bug by ignoring the build directory passed into the tools.
To enable a boot-loader style application, override
"targets.bootloader_exec" or "targets.restrict_size" on a particular
target. These parameters are a bin or hex file, and an integer, in bytes,
respectively. If either override is present, then an application region
is created after the boot-loader region, when "targets.bootloader_exec"
is present, and before post-application, when "targets.restric_size" is
present. The size of the boot-loader region is read from the file
provided in the configuration.
example specified in the supplied .json file, in a user specified fork.
A pull request is then made from each fork to the ARMmbed master repo.
New usage:
python update.py <args>
Where <args> are:
[-c <file.json>] optional argument for example list, default
example.json
-U <github user with forked repos>
-T <github authorisation token>
tag
If an example's GitHub repository contains multiple child examples, the
script was incorrectly filtering out all the child examples when
compiling and exporting. This patch now handles this case correctly.
This adds an example clone and deploy step that allows you to modify
each top level repository before pulling in the rest of the example's
dependencies. This allows us to not pull in a copy of mbed-os for each
example in CI and instead symbolic link the already cloned copy, saving
valuable time and disk space
Adding the new compile option allows the marking of a set of examples to
indicate whether they should be compiled or not. For the update process
examples that are not compiled will not be auto updated irrespective of
that setting.
Other changes to make return logic from some functions in update.py more
efficient and some typos in the lib file.
Changes:
Refactor examples.py to add a new command line option to provide an update
tag.
Refactor examples.py to add new functionality to update the version of
mbed-os in the examples to a supplied tag.
Refactor examples.py to make cloning the example repos, updating their
mbed-os version and compiling, into library functions and move to a new
library module.
Refactor the format of the examples.json file to make it compatible with
both examples.py and update.py.
Refactor update.py so that examples are test compiled prior to updating.
Refactor update.py so that only examples tagged as auto-updatable and that
fully compile are automatically updated.
*Changes*
- Parallel export
- mbed-os tests added
- specified release version (default to 5)
- default tests AND targets dependent on specified release version
As mbed-events is being brought into the mbed-os tree, the examples
using the external mbed-events library will fail due to duplicate
definitions.
The tests for BLE examples will be readded after the examples are
updated to only use the mbed-events library in the mbed-os tree.
*Changes*
- Parallel export
- mbed-os tests added
- specified release version (default to 5)
- default tests AND targets dependent on specified release version
The previous code used a variable that was internal to the Target class.
This commit removes the argument to `set_targets_json_location`
completely, which forces Target to use the default locatio internally.
Custom targets were the origin of a number of issues with the mbed
tools, so it was decided that they need to be removed. This PR does just
that (and moves the "custom_targets" part of the config system tests
into a separate, per-test "targets.json" file to preserve the test
functionality).
uVision4 is no longer maintained by the Keil team (support was stopped
long time ago).
This is why we need to make the uvision exporter able to generate uVision5
projects by default (which is based on software packs).
Also, adding note that the uvision4 exporter is now deprecated and will be
removed in the future.
Makes several broad changes:
- removes dead code that dealt with the online build system
- replaces export function with a much simpler one that:
- does not copy any sources
- the zip file hits the disk
- the mbed_config.h hits the disk
- the project files hit the disk
- nothing else hits the disk
- exporters use Resource object scanned with a toolchain
- progen exporters don't optionally build a project instead they have a
build function that may be called afterwards
- much of the code passes pylint (have a score of 9 or above):
- project.py
- project_api.py
- export/__init__.py
- export/exporters.py
- test/export/build_test.py
Unlike other libraries, uvisor is currently integrated into the build
system, with special cases based on its addition as a feature. This
suggests we should also have tests for these special cases.
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.
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.
PR #1974 added a new configuration parameter to K64F, which in turn made
some tests break, because they found an unexpected configuration
parameter. Fixed by defining a special target for the tests
(test_target) that can be used independently of the actual mbed targets.
The current implementation of the configuration system "compiles" the
configuration parameters to macros defined on the command line. This
works, but has a few limitations:
- it can bring back the maximum command line length issues in Windows.
- depending on the type of the configuration parameter, it might require
special quoting of its value in the command line.
- various 3rd party IDE/tools seem to have some limitations regarding
the total length of the macros that can be defined.
This commit is the first step in replacing the current mechanism with
one that generates configuration in header files that will be
automatically included, instead of command line macro definitions. The
commit only adds the method for generating the header file, it doesn't
actually change the way config is used yet (that will happen in step 2),
thus it is backwards compatible. The logic of the configuration system
itself is unchanged (in fact, the whole change (not only this commit) is
supposed to be completely transparent for the users of the configuration
system).
The commit also fixes an issue in tools/get_config.py that appeared as a
result of a recent PR: the signature of "get_config" in
tools/build_api.py changed, but tools/get_config.py was not updated.
David Walters
adbridge
Jimmy Brisson
Shrikant Tudavekar
Marcelo Salazar
Andrew Leech
Brian Daniels
Martin Kojtal
Sam Grove
0xc0170
Russ Butler
Mohammad Azim Khan
Sarah Marsh
sarahmarshy
Christopher Haster
Marcelo Salazar
Bogdan Marinescu
Conor Keegan
Vincent Coubard
Mihail Stoyanov