We do not want an app to link core and also targets. As both actually create one core component.
Therefore expose include dirs from targets to core.
mbed-events for instance should just link to mbed-core and it should get all it needs.
Link what we can link with CMake. We still need copy core sources to mbed-os-obj. And expose
also link options to app as linker flags are provided via them. Normally, we would link to
target library but as it's interface, we would copy the sources as well, this is not what we want.
Use `${MBED_TARGET_CONVERTED}-core` target for exposing cmsis/device headers to the core. This breaks
the circular dependency between core and targets.
I also attempt to break building objects per each level in targets hieararchy. The top level target - public facing target, needs to gather sources and create object library.
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.
Martin Kojtal
Lingkai Dong
Ladislas de Toldi
Hugues Kamba
Robert Walton