An earlier patch in this series changed the API for
`build_api.prepare_toolchain`. This commit updates the `find_test`
function to call `prepare_toolchain` correctly.
The worker_result variable was not guaranteed to have a `'result'` or
`'reason'` key and accessing them before testing for them could result
in an error when they are not provided. This patch changes the checks to
prevent check for their existence before accessing them.
Since the toolchain path info lives as a global variable, its not
propigating to the subprocesses that are created to compile the tests in
parallel. This change manually passes these global variables and then
reassigns them.
This makes use of the reports generated by the building of tests to
prevent output from interleaving when the build is parallelized. This
required some changes to memap to return a generated string from
the 'generate_output' function. I also had an option to stop the prints
from memap to prevent text from interleaving
This uses similar code that is used withing the toolchains to parallelize
the linking process of all the tests accross all the available CPUs. It
also respects the `-j` parameter if you wish to limit the number of cores
used.
Previously, when building tests with test.py, if an exception occurred, the
error message would be masked by the function 'build_tests'. This commit
handles NotSupportedExceptions and ToolExceptions, but lets all other
Exceptions propigate up to the caller function. In most cases, this is the
CLI scripts, which will print a traceback. This will allow us to better
debug the python tools if errors occur.
#2613 should be merged first
Using test_api, I found that the test names were dependent on where mbed-os (if that is the root) is stored on disk if you provide anything other than '.' as the root directory.
This would change names like:
```
repos-mbed-os-example-blinky-mbed-os-features-storage-feature_storage-tests-cfstore-example3
```
to
```
features-storage-feature_storage-tests-cfstore-example3
```
The shared `prepare_toolchain` and `scan_resources` functions in build_api
expect a list, not a string. This is different from the
toolchain.scan_resources function. Now the functions are being used
correctly within the `find_tests` function in test_api
Previously, test discovery throught test.py used its own logic to find
tests. This was mostly a subset of the rules used during the build
process. It respected .mbedignore files, but it did not respect TARGET_,
TOOLCHAIN_, and FEATURES_ directories. This change now uses the same logic
used during building to respect these folders. Tests under these folders
that are not being pulled in for the given target will be ignored.
* added/improved global chroot support
* added RESPONSE_FILES flag to support optional response files (on linux the cmd param length is 2 megabytes). Default True
* added unified handling for archive and link response file (similar to includes)
* added COMPILE_C_AS_CPP flag to support compiling of c files as cpp. Default False
* added mbedToolchain.init() for post __init__ hooks
* added caching to mbedToolchain.need_update() to reduce IO hits
* added support to identify compiler warning/error column (supports ARMCC, GCC and IAR). Errors/warnings now report file@line,col
* added global TOOLCHAIN_PATHS which allows overriding/changing of the toolchain paths. Also simplified ARM-related paths
* added target.json to mbed library release (by @0xc0170)* migrated compile_worker() to utils.py for lightweight thread initialization
* improved run_cmd() performance by removing unnecessary check about the command being executed (should be checked once in the relevant toolchain instead)
* removed remnants of Goanna support (should be reimplemented as hooks to compile/link/archive instead)
* fixes for Python 2.7 compatibility (by @0xc0170)
* fixes for Exporters (by @0xc0170)
With this change, custom targets defined by the application being
tested in its mbed_app.json file can be used with tests. Note that
`build_project` already accepts both target names and instances, so the
call to `build_project` inside `build_tests` will still work.
This mitigates the Windows paths issue by shortening the test binary name to just the
test case folder name instead of the full unique test name used by the
tools. This doesn't solve the Windows path limit of 260 characters, but it
does reduce the characters used.