351680fb18
When building greentea tests, each test is an executable with its
own output binary path. This is also the case when a user project
produces multiple executables. But the current implementation of
post-build operations always assumes there's only one executable,
at the root of the build directory.
The post-build command depends on Mbed target, and it always takes
the the executable we build as an input file. To achieve this, we
let each Mbed target (that has a post-build command) define a function
function(mbed_post_build_function target)
which takes a CMake executable target as an argument from which it can
get its binary path using generator expressions. It generates and adds
to the passed executable target a post-build custom command.
Notes:
* The function name needs to be exact, because CMake only supports
literal function calls - CMake can't dereference a function name from
a variable. To avoid multiple definitions of this function, each Mbed
target needs to guard it with a macro to check if the user is
building this Mbed target.
* `mbed_post_build_function()` is a function, but it is usually
defined by another macro rather than a parent function, because
nesting functions would make many variables inaccessible inside the
innermost `mbed_post_build_function()`.
* There's no more need to force regenerate images. Previously, post-
build commands were custom *targets* which always got to run, so we
force regenerated images on every build to avoid patching an image
that's already been patched once on previous build. Now post-build
commands are custom *commands* of the same executable target, and they
are only run if the executable target itself is rebuilt.
|
||
|---|---|---|
| .github | ||
| TESTS | ||
| UNITTESTS | ||
| cmsis | ||
| connectivity | ||
| docs | ||
| drivers | ||
| events | ||
| extern | ||
| features | ||
| hal | ||
| platform | ||
| rtos | ||
| storage | ||
| targets | ||
| tools | ||
| .astylerc | ||
| .codecheckignore | ||
| .coveragerc | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .lgtm.yml | ||
| .mergify.yml | ||
| .pylintrc | ||
| .travis.yml | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| DOXYGEN_FRONTPAGE.md | ||
| Jenkinsfile | ||
| LICENSE-apache-2.0.txt | ||
| LICENSE.md | ||
| README.md | ||
| doxyfile_options | ||
| doxygen_options.json | ||
| logo.png | ||
| mbed.h | ||
| requirements.txt | ||
README.md
Arm Mbed OS is an open source embedded operating system designed specifically for the "things" in the Internet of Things. It includes all the features you need to develop a connected product based on an Arm Cortex-M microcontroller, including security, connectivity, an RTOS and drivers for sensors and I/O devices.
Mbed OS provides a platform that includes:
- Security foundations.
- Cloud management services.
- Drivers for sensors, I/O devices and connectivity.
Release notes
The release notes detail the current release. You can also find information about previous versions.
License and contributions
The software is provided under the Apache-2.0 license. Contributions to this project are accepted under the same license. Please see contributing.md for more information.
This project contains code from other projects. The original license text is included in those source files. They must comply with our license guide.
Folders containing files under different permissive license than Apache 2.0 are listed in the LICENSE file.
Getting started for developers
We have a developer website for asking questions, engaging with others, finding information on boards and components, using an online IDE and compiler, reading the documentation and learning about what's new and what's coming next in Mbed OS.
Getting started for contributors
We also have a contributing and publishing guide that covers licensing, contributor agreements and style guidelines.
Documentation
For more information about Mbed OS, please see our published documentation. It includes Doxygen for our APIs, step-by-step tutorials, porting information and background reference materials about our architecture and tools.
To contribute to this documentation, please see the mbed-os-5-docs repository.