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.
The compile defintions should always be added depending on the
selected toolchain.
mbed_set_toolchain_options() should only be called if a third-party
toolchain file has not been used as it has compile options that can
cause conflicts.
Rename the CMake variable expected from applications from MBED_ROOT to
MBED_PATH to be consistent with the naming used for the configuration file
(MBED_CONFIG_PATH) also expected from applications.
Issue https://gitlab.kitware.com/cmake/cmake/-/issues/21093
Until this is fixed, we should disable response files for ARMClang + ninja on Windows.
Other toolchains and host systems should benefit from response files thus not disabling them
completely.
This fixes the issue with not finding includes. It's not trivial to find the root cause, it took me a while to figure out why ARMClang can't find the paths.
I moved the check to Mbed OS main cmake. It should not be in the toolchain file as it is not
related to the toolchain but to generator. We need toolchain properly set up first.
Note, I had to protect setting CMAKE_NINJA_FORCE_RESPONSE_FILE. If I set it to 0, ninja
would still use rsp files so I rather protected it and define that variable only when
required, not always.
Co-authored-by: Hugues Kamba <41612201+hugueskamba@users.noreply.github.com>
$<TARGET_FILE:${target}> is the output from CMake. As it can contain suffix for some toolchains, we can use ${target} instead (output from hex/bin generation).
mbed-os consists of mbed-core and mbed-rtos
mbed-baremetal consists of mbed-core
The main change is for mbed-core. Changing from object library to be interface. This way it allows us to do the above to have 2 main targets for users to use.
This should be backward compatible change as mbed-os target we used contains the same files/options as previously set.
This ensures that applications which link with the mbed-os
CMake target still work. We want applications that require the OS
to use the mbed-os CMake target as we will be creating a new one
that will include mbed-core and mbed-rtos.
These settings like enable_language should be done in the application and just once.
We hit the issue when you expose sources to an app (interface or public), CMake errors as some of the internal settings have not been configured.
A linker script needs symbols (stack size, app size, etc). They are basic values or defines. Not any array like or string like macros. We should filter these, as they are not valid anyway.
The other option to fix this would be to fix all the macros but I dont think it is needed as these config values won't be used in the linker script anyway.
Not allowed in ld files macros with spaces, like MACRO={0, 2, 3} or MACRO=(4 * 2000).
Directories that start with special prefixes (TARGET_, FEATURE_, COMPONENT_) are added to the build based on Mbed target configuration from targets.json instead of calling utility function mbed_add_cmake_directory_if_labels().
Aside from the core mbed-os CMake target, a number of targets have been created so they can optionally be included by application executables that require them using `target_link_libraries()`.
Co-authored-by: Martin Kojtal <martin.kojtal@arm.com>
Co-authored-by: Rajkumar Kanagaraj <rajkumar.kanagaraj@arm.com>
- Add linker option to generate map file for GCC_ARM and ARM toolchain
- Add mbed_generate_map_file function to call memap.py (parse the map
file).
- Add mbed_generate_executable function to generate executable artifacts with a memory map table
We should define CMAKE_TOOLCHAIN_FILE (as we are providing Mbed OS toolchain file). This fixes
also the issue we had with Unix makefiles where application would be without response files.
For more details, see https://gitlab.kitware.com/cmake/cmake/-/issues/21104
As the Mbed OS toolchain file is included by CMake, we need to have enabling language in the main CMake (can be executed
only once).
Provide a function in each build profile module to set the toolchain
options. All the functions have the same interface therefore the
CMake source file including the module always calls the same
function regardless of which build profile module is actually
included.
When the `mbed-os` target is broken up into multiple libraries,
a library other than `mbed-os` might need to set the toolchain
options. This will be possible by simply including the module
and calling the function with the target and toolchain for which
to set the options.
Provide a function in each toolchain module to set the toolchain
specific options. All the functions have the same interface
therefore the CMake source file including the module always calls
the same function regardless of which toolchain module is actually
included.
When the `mbed-os` target is broken up into multiple libraries, a
library other than `mbed-os` might need to set the toolchain options.
This will be possible by simply including the module and calling the
function with the target for which to set the options.
Provide a function in each CPU core module to set toolchain options.
All the functions have the same interface therefore the CMake source
file including the module always calls the same function regardless
of which cpu core module is actually included.
When the `mbed-os` target is broken up into multiple libraries, a
library other than `mbed-os` might need to set the toolchain options.
This will be possible by simply including the module and calling the
function with the target and toolchain for which to set the options.
Robert Walton
Jamie Smith
Hugues Kamba
Martin Kojtal
Lingkai Dong
Evelyne Donnaes
Rajkumar Kanagaraj
Rajkumar Kanagaraj
Hugues Kamba