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
As Mbed OS is built as whole, we have long paths again. This is known issue with windows. To fix the paths, we need to use response files.
Ninja is special, needs to be forced to use long paths.
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).
Auto mode for ASM files. There might be rare cases where this fails, we will fix
them by requesting the component to use gnu syntax for assembly files.
Martin Kojtal
Rajkumar Kanagaraj
Hugues Kamba
Rajkumar Kanagaraj
Hugues Kamba