Update CMAKE_MODULE_PATH at once place.
Note, we update also CMAKE_MODULE_PATH in app.cmake. This is temporary until we get a proper way to include
Mbed Os (removing app.cmake need to be included by an application).
To avoid conflicts as we expose our CMake list files via CMAKE_MODULE_PATH. Some files already include it, this
aligns the rest of files.
I leave app.cmake as it is - it's user facing and it would be breaking change. We can clean this one for the next major version.
Requires: https://github.com/ARMmbed/mbed-tools/pull/242
The optional `OUTPUT_EXT` field in Mbed OS `targets.json` specifies
the format of the output image. This is important because
* some targets only support one image format
* each post-binary hook outputs one image only
This avoids confusion of having both .hex and .bin images generated
while only one of them is usable.
Pass the exact name to the post-build hook, when an application's
or test's `CMakeLists.txt` calls `mbed_set_post_build()`. The
interface is CMake's built-in mechanism:
* `set_target_properties()` to set a property, e.g. application name
* `$<TARGET_PROPERTY:target,property>` to query a property at run time
If a target has a post binary hook, we should force regenerate
the application binaries every time so that the hook is run on a
raw binary rather than a previous build that already went through
the post-build process once.
There should not be a reference to APP_TARGET in Mbed OS as end-users
may decide to use a different name for the CMake variable to store their
application name.
The CMake custom target must be unique to avoid more than one
Mbed target adding the same. Only the CMake custom command added for the
Mbed target being built is run as the custom CMake target now includes
the Mbed target name.
We need to generate a "response file" to pass to the C preprocessor
when we preprocess the linker script, because of path length limitations
on Windows. We set the response file and bind the path to a global
property. The MBED_TARGET being built queries this global property when
it sets the linker script.
We must set this global property before the targets subdirectory is
added to the project. This is required because the MBED_TARGET depends
on the response file. If the path to the response file is not defined
when the target requests it the config definitions will not be passed
to CPP.
A CMake custom target, mbed-post-build, is added as a dependency of the
application CMake target if a Mbed target adds a CMake custom target
named mbed-post-build-bin. mbed-post-build-bin is added as a dependency
of mbed-post-build. mbed-post-build-bin depends on the application binary.
This is done so a CMake custom command that executes post-build can be added.
The Python scripts that implement the operations have been modified to add
CLI entry points so they can be called from CMake. Dependency on the old
tool has been removed on those scripts by passing them exactly what they
require instead of passing old tool Python objects. A consequence of that
was to slightly amend how the old tool calls some of those Python modules.
Support has only been added for Mbed targets that currently have a requirement
for post build operations. This includes: LPC1114, LPC1768, ARCH_PRO, LPC54114,
LPC546XX, FF_LPC546XX, CY8CKIT064B0S2_4343W, CYTFM_064B0S2_4343W, CYSBSYSKIT_01
The following targets are not supported as TFM support is not yet included:
ARM_MUSCA_B1, ARM_MUSCA_B1_NS, ARM_MUSCA_S1, ARM_MUSCA_S1_NS.
This fixes the problem for an app/test to define APP_TARGET as requirements. This is not a proper fix
but rather a workaround for broken apps/tests currently. We will address this separately via new
pull request.
We set language standard via mbed-core and app inherits it if links to it.
This is breaking change for application, please remove the function call from an
application and it should build without errors.
Move the mbed_set_mbed_target_linker_script function into its own file
and make it set the linkerscript on the target passed in, rather than
setting the linkerscript on the top level mbed-core target. We use
CMake's automatic forwarding of usage requirements to forward the linker
script to the top level target.
This commit also adds a condition to check whether the MBED_TARGET is a
CMake buildsystem target. If it is we will just link to it in the
idiomatic CMake way, if it's not then we use the 'old' mechanism of
setting the linkerscript for the mbed-core target. This check will be
useful when we refactor MBED_TARGETS to be CMake buildsystem targets as
it will allow us to do the refactoring incrementally.
Fixes https://github.com/ARMmbed/mbed-os/issues/13983
Move linker script to the function mbed_set_mbed_target_linker_script.
I also moved memmap as it is needed for an app. The location might not be the best fit,
we will address this in separate pull request.
Martin Kojtal
Lingkai Dong
Ladislas de Toldi
Hugues Kamba
Robert Walton
Jamie Smith
Evelyne Donnaes
Rajkumar Kanagaraj
Rajkumar Kanagaraj