OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/cmake/llext-edk.cmake

198 lines
8.7 KiB
CMake
Raw Normal View History

cmake: New target which generates a sort of development kit for llext Loadable extensions need access to Zephyr (and Zephyr application) includes and some CFLAGS to be properly built. This patch adds a new target, `llext-edk`, which generates a tar file with those includes and flags that can be loaded from cmake and make files. A Zephyr application willing to expose some API to extensions it loads only need to add the include directories describing such APIs to the Zephyr ones via zephyr_include_directories() CMake call. A new Kconfig option, CONFIG_LLEXT_EDK_NAME allows one to control some aspects of the generated file, which enables some customization - think of an application called ACME, willing to have a ACME_EXTENSION_KIT or something. All EDK Kconfig options are behind CONFIG_LLEXT_EDK, which doesn't depend on LLEXT directly - so that EDK features can be leveraged by downstream variations of loadable extensions. Also, each arch may need different compiler flags for extensions: those are handled by the `LLEXT_CFLAGS` cmake flag. An example is set for GCC ARM. Finally, EDK throughout this patch means Extension Development Kit, which is a bad name, but at least doesn't conflict with SDK. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-01-19 12:28:46 +08:00
# Copyright (c) 2024 Intel Corporation
# SPDX-License-Identifier: Apache-2.0
# This script generates a tarball containing all headers and flags necessary to
# build an llext extension. It does so by copying all headers accessible from
# INTERFACE_INCLUDE_DIRECTORIES and generating a Makefile.cflags file (and a
# cmake.cflags one) with all flags necessary to build the extension.
#
# The tarball can be extracted and used in the extension build system to include
# all necessary headers and flags. File paths are made relative to a few key
# directories (build/zephyr, zephyr base, west top dir and application source
# dir), to avoid leaking any information about the host system.
#
# The following arguments are expected:
# - llext_edk_name: Name of the extension, used to name the tarball and the
# install directory variable for Makefile.
# - INTERFACE_INCLUDE_DIRECTORIES: List of include directories to copy headers
# from. It should simply be the INTERFACE_INCLUDE_DIRECTORIES property of the
# zephyr_interface target.
# - llext_edk_file: Output file name for the tarball.
llext-edk: (refactor) unify variable names The variable llext_edk_cflags was used in the main CMakeLists.txt file, while llext_cflags was used in the llext-edk.cmake file. This commit unifies the variable names to use llext_edk_cflags in both files. No logic changes are introduced by this commit. Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
2024-08-06 23:24:20 +08:00
# - llext_edk_cflags: Flags to be used for source compile commands.
cmake: New target which generates a sort of development kit for llext Loadable extensions need access to Zephyr (and Zephyr application) includes and some CFLAGS to be properly built. This patch adds a new target, `llext-edk`, which generates a tar file with those includes and flags that can be loaded from cmake and make files. A Zephyr application willing to expose some API to extensions it loads only need to add the include directories describing such APIs to the Zephyr ones via zephyr_include_directories() CMake call. A new Kconfig option, CONFIG_LLEXT_EDK_NAME allows one to control some aspects of the generated file, which enables some customization - think of an application called ACME, willing to have a ACME_EXTENSION_KIT or something. All EDK Kconfig options are behind CONFIG_LLEXT_EDK, which doesn't depend on LLEXT directly - so that EDK features can be leveraged by downstream variations of loadable extensions. Also, each arch may need different compiler flags for extensions: those are handled by the `LLEXT_CFLAGS` cmake flag. An example is set for GCC ARM. Finally, EDK throughout this patch means Extension Development Kit, which is a bad name, but at least doesn't conflict with SDK. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-01-19 12:28:46 +08:00
# - ZEPHYR_BASE: Path to the zephyr base directory.
# - WEST_TOPDIR: Path to the west top directory.
# - APPLICATION_SOURCE_DIR: Path to the application source directory.
# - PROJECT_BINARY_DIR: Path to the project binary build directory.
subsys/llext: Generate syscalls stubs for EDK exclusively for userspace A new Kconfig option which generates syscall stubs assuming that extensions will always run on userspace, thus simplifying linking them, as there's no need for z_impl_ stubs (used for direct syscalls), CONFIG_LLEXT_EDK_USERSPACE_ONLY. While defining __ZEPHYR_USER__ could have the same effect for optmised builds, people building extensions on debug environments - thus non-optimised - would suffer, as they'd need to somehow make the stubs available (by either exporting the symbol or implementing dummy stubs). Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-02-28 07:05:47 +08:00
# - CONFIG_LLEXT_EDK_USERSPACE_ONLY: Whether to copy syscall headers from the
# edk directory. This is necessary when building an extension that only
# supports userspace, as the syscall headers are regenerated in the edk
# directory.
cmake: New target which generates a sort of development kit for llext Loadable extensions need access to Zephyr (and Zephyr application) includes and some CFLAGS to be properly built. This patch adds a new target, `llext-edk`, which generates a tar file with those includes and flags that can be loaded from cmake and make files. A Zephyr application willing to expose some API to extensions it loads only need to add the include directories describing such APIs to the Zephyr ones via zephyr_include_directories() CMake call. A new Kconfig option, CONFIG_LLEXT_EDK_NAME allows one to control some aspects of the generated file, which enables some customization - think of an application called ACME, willing to have a ACME_EXTENSION_KIT or something. All EDK Kconfig options are behind CONFIG_LLEXT_EDK, which doesn't depend on LLEXT directly - so that EDK features can be leveraged by downstream variations of loadable extensions. Also, each arch may need different compiler flags for extensions: those are handled by the `LLEXT_CFLAGS` cmake flag. An example is set for GCC ARM. Finally, EDK throughout this patch means Extension Development Kit, which is a bad name, but at least doesn't conflict with SDK. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-01-19 12:28:46 +08:00
cmake_minimum_required(VERSION 3.20.0)
llext: add support for SLID-based linking This commit introduces support for an alternate linking method in the LLEXT subsystem, called "SLID" (short for Symbol Link Identifier), enabled by the CONFIG_LLEXT_EXPORT_BUILTINS_BY_SLID Kconfig option. SLID-based linking uses a unique identifier (integer) to identify exported symbols, instead of using the symbol name as done currently. This approach provides several benefits: * linking is faster because the comparison operation to determine whether we found the correct symbol in the export table is now an integer compare, instead of a string compare * binary size is reduced as symbol names can be dropped from the binary * confidentiality is improved as a side-effect, as symbol names are no longer present in the binary Signed-off-by: Mathieu Choplain <mathieu.choplain@st.com>
2024-05-06 19:03:26 +08:00
if (CONFIG_LLEXT_EXPORT_BUILTINS_BY_SLID)
message(FATAL_ERROR
"The LLEXT EDK is not compatible with CONFIG_LLEXT_EXPORT_BUILTINS_BY_SLID.")
endif()
cmake: New target which generates a sort of development kit for llext Loadable extensions need access to Zephyr (and Zephyr application) includes and some CFLAGS to be properly built. This patch adds a new target, `llext-edk`, which generates a tar file with those includes and flags that can be loaded from cmake and make files. A Zephyr application willing to expose some API to extensions it loads only need to add the include directories describing such APIs to the Zephyr ones via zephyr_include_directories() CMake call. A new Kconfig option, CONFIG_LLEXT_EDK_NAME allows one to control some aspects of the generated file, which enables some customization - think of an application called ACME, willing to have a ACME_EXTENSION_KIT or something. All EDK Kconfig options are behind CONFIG_LLEXT_EDK, which doesn't depend on LLEXT directly - so that EDK features can be leveraged by downstream variations of loadable extensions. Also, each arch may need different compiler flags for extensions: those are handled by the `LLEXT_CFLAGS` cmake flag. An example is set for GCC ARM. Finally, EDK throughout this patch means Extension Development Kit, which is a bad name, but at least doesn't conflict with SDK. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-01-19 12:28:46 +08:00
set(llext_edk ${PROJECT_BINARY_DIR}/${llext_edk_name})
set(llext_edk_inc ${llext_edk}/include)
cmake: Handle `imacros` from flags Instead of hardcoding `autoconf.h` imacro, get the list of imacros from the llext flags. As those come in the form of absolute paths, they also need to be massaged to point from the EDK directory without revealing host complete paths. Also, the EDK now keeps the imacros on a different flag, `LLEXT_GENERATED_IMACROS_CFLAGS`, to keep it similar to other generated includes. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-04-14 07:04:01 +08:00
# Usage:
# relative_dir(<dir> <relative_out> <bindir_out>)
#
# Helper function to generate relative paths to a few key directories
# (PROJECT_BINARY_DIR, ZEPHYR_BASE, WEST_TOPDIR and APPLICATION_SOURCE_DIR).
# The generated path is relative to the key directory, and the bindir_out
# output variable is set to TRUE if the path is relative to PROJECT_BINARY_DIR.
#
function(relative_dir dir relative_out bindir_out)
cmake: New target which generates a sort of development kit for llext Loadable extensions need access to Zephyr (and Zephyr application) includes and some CFLAGS to be properly built. This patch adds a new target, `llext-edk`, which generates a tar file with those includes and flags that can be loaded from cmake and make files. A Zephyr application willing to expose some API to extensions it loads only need to add the include directories describing such APIs to the Zephyr ones via zephyr_include_directories() CMake call. A new Kconfig option, CONFIG_LLEXT_EDK_NAME allows one to control some aspects of the generated file, which enables some customization - think of an application called ACME, willing to have a ACME_EXTENSION_KIT or something. All EDK Kconfig options are behind CONFIG_LLEXT_EDK, which doesn't depend on LLEXT directly - so that EDK features can be leveraged by downstream variations of loadable extensions. Also, each arch may need different compiler flags for extensions: those are handled by the `LLEXT_CFLAGS` cmake flag. An example is set for GCC ARM. Finally, EDK throughout this patch means Extension Development Kit, which is a bad name, but at least doesn't conflict with SDK. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-01-19 12:28:46 +08:00
cmake_path(IS_PREFIX PROJECT_BINARY_DIR ${dir} NORMALIZE to_prj_bindir)
cmake_path(IS_PREFIX ZEPHYR_BASE ${dir} NORMALIZE to_zephyr_base)
if("${WEST_TOPDIR}" STREQUAL "")
set(to_west_topdir FALSE)
else()
cmake_path(IS_PREFIX WEST_TOPDIR ${dir} NORMALIZE to_west_topdir)
endif()
cmake_path(IS_PREFIX APPLICATION_SOURCE_DIR ${dir} NORMALIZE to_app_srcdir)
# Overall idea is to place included files in the destination dir based on the source:
# files coming from build/zephyr/generated will end up at
# <install-dir>/include/zephyr/include/generated, files coming from zephyr base at
# <install-dir>/include/zephyr/include, files from west top dir (for instance, hal modules),
# at <install-dir>/include and application ones at <install-dir>/include/<application-dir>.
# Finally, everything else (such as external libs not at any of those places) will end up
# at <install-dir>/include/<full-path-to-external-include>, so we avoid any external lib
# stepping at any other lib toes.
if(to_prj_bindir)
cmake_path(RELATIVE_PATH dir BASE_DIRECTORY ${PROJECT_BINARY_DIR} OUTPUT_VARIABLE dir_tmp)
set(dest ${llext_edk_inc}/zephyr/${dir_tmp})
elseif(to_zephyr_base)
cmake_path(RELATIVE_PATH dir BASE_DIRECTORY ${ZEPHYR_BASE} OUTPUT_VARIABLE dir_tmp)
set(dest ${llext_edk_inc}/zephyr/${dir_tmp})
elseif(to_west_topdir)
cmake_path(RELATIVE_PATH dir BASE_DIRECTORY ${WEST_TOPDIR} OUTPUT_VARIABLE dir_tmp)
set(dest ${llext_edk_inc}/${dir_tmp})
elseif(to_app_srcdir)
cmake_path(GET APPLICATION_SOURCE_DIR FILENAME app_dir)
cmake_path(RELATIVE_PATH dir BASE_DIRECTORY ${APPLICATION_SOURCE_DIR} OUTPUT_VARIABLE dir_tmp)
set(dest ${llext_edk_inc}/${app_dir}/${dir_tmp})
else()
set(dest ${llext_edk_inc}/${dir})
endif()
cmake: Handle `imacros` from flags Instead of hardcoding `autoconf.h` imacro, get the list of imacros from the llext flags. As those come in the form of absolute paths, they also need to be massaged to point from the EDK directory without revealing host complete paths. Also, the EDK now keeps the imacros on a different flag, `LLEXT_GENERATED_IMACROS_CFLAGS`, to keep it similar to other generated includes. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-04-14 07:04:01 +08:00
set(${relative_out} ${dest} PARENT_SCOPE)
if(to_prj_bindir)
set(${bindir_out} TRUE PARENT_SCOPE)
else()
set(${bindir_out} FALSE PARENT_SCOPE)
endif()
endfunction()
string(REGEX REPLACE "[^a-zA-Z0-9]" "_" llext_edk_name_sane ${llext_edk_name})
string(TOUPPER ${llext_edk_name_sane} llext_edk_name_sane)
set(install_dir_var "${llext_edk_name_sane}_INSTALL_DIR")
llext-edk: (refactor) unify variable names The variable llext_edk_cflags was used in the main CMakeLists.txt file, while llext_cflags was used in the llext-edk.cmake file. This commit unifies the variable names to use llext_edk_cflags in both files. No logic changes are introduced by this commit. Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
2024-08-06 23:24:20 +08:00
separate_arguments(llext_edk_cflags NATIVE_COMMAND ${llext_edk_cflags})
cmake: Handle `imacros` from flags Instead of hardcoding `autoconf.h` imacro, get the list of imacros from the llext flags. As those come in the form of absolute paths, they also need to be massaged to point from the EDK directory without revealing host complete paths. Also, the EDK now keeps the imacros on a different flag, `LLEXT_GENERATED_IMACROS_CFLAGS`, to keep it similar to other generated includes. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-04-14 07:04:01 +08:00
set(make_relative FALSE)
llext-edk: (refactor) unify variable names The variable llext_edk_cflags was used in the main CMakeLists.txt file, while llext_cflags was used in the llext-edk.cmake file. This commit unifies the variable names to use llext_edk_cflags in both files. No logic changes are introduced by this commit. Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
2024-08-06 23:24:20 +08:00
foreach(flag ${llext_edk_cflags})
cmake: Handle `imacros` from flags Instead of hardcoding `autoconf.h` imacro, get the list of imacros from the llext flags. As those come in the form of absolute paths, they also need to be massaged to point from the EDK directory without revealing host complete paths. Also, the EDK now keeps the imacros on a different flag, `LLEXT_GENERATED_IMACROS_CFLAGS`, to keep it similar to other generated includes. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-04-14 07:04:01 +08:00
if (flag STREQUAL "-imacros")
set(make_relative TRUE)
elseif (make_relative)
set(make_relative FALSE)
cmake_path(GET flag PARENT_PATH parent)
cmake_path(GET flag FILENAME name)
relative_dir(${parent} dest bindir)
cmake_path(RELATIVE_PATH dest BASE_DIRECTORY ${llext_edk} OUTPUT_VARIABLE dest_rel)
if(bindir)
list(APPEND imacros_gen_make "-imacros\$(${install_dir_var})/${dest_rel}/${name}")
list(APPEND imacros_gen_cmake "-imacros\${CMAKE_CURRENT_LIST_DIR}/${dest_rel}/${name}")
else()
list(APPEND imacros_make "-imacros\$(${install_dir_var})/${dest_rel}/${name}")
list(APPEND imacros_cmake "-imacros\${CMAKE_CURRENT_LIST_DIR}/${dest_rel}/${name}")
endif()
else()
list(APPEND new_cflags ${flag})
endif()
endforeach()
llext-edk: (refactor) unify variable names The variable llext_edk_cflags was used in the main CMakeLists.txt file, while llext_cflags was used in the llext-edk.cmake file. This commit unifies the variable names to use llext_edk_cflags in both files. No logic changes are introduced by this commit. Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
2024-08-06 23:24:20 +08:00
set(llext_edk_cflags ${new_cflags})
cmake: Handle `imacros` from flags Instead of hardcoding `autoconf.h` imacro, get the list of imacros from the llext flags. As those come in the form of absolute paths, they also need to be massaged to point from the EDK directory without revealing host complete paths. Also, the EDK now keeps the imacros on a different flag, `LLEXT_GENERATED_IMACROS_CFLAGS`, to keep it similar to other generated includes. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-04-14 07:04:01 +08:00
llext-edk: fix: add compile definitions to the generated EDK The LLEXT EDK was not exporting common Zephyr compile definitions ("-Dxxx" flags). This patch adds the compile definitions before the other compile flags, as it is done in the Zephyr build system. This patch also adds to this list the "-DLL_EXTENSION_BUILD" flag, instead of providing a special case at a later stage. Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
2024-08-06 23:27:24 +08:00
list(APPEND base_flags_make ${llext_edk_cflags} ${imacros_make})
list(APPEND base_flags_cmake ${llext_edk_cflags} ${imacros_cmake})
cmake: Handle `imacros` from flags Instead of hardcoding `autoconf.h` imacro, get the list of imacros from the llext flags. As those come in the form of absolute paths, they also need to be massaged to point from the EDK directory without revealing host complete paths. Also, the EDK now keeps the imacros on a different flag, `LLEXT_GENERATED_IMACROS_CFLAGS`, to keep it similar to other generated includes. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-04-14 07:04:01 +08:00
cmake: Pass path list in a Windows friendly way When invoking cmake/llext-edk.cmake, CMakeLists.txt was sending the list of includes as a colon separated list. On Windows, this list was actually a single item, so it wasn't being parsed properly. This patch sends the list as a cmake list and uses separate_arguments() on the receiving side to fix it. Fixes #73069 Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-05-24 07:38:24 +08:00
separate_arguments(include_dirs NATIVE_COMMAND ${INTERFACE_INCLUDE_DIRECTORIES})
cmake: Handle `imacros` from flags Instead of hardcoding `autoconf.h` imacro, get the list of imacros from the llext flags. As those come in the form of absolute paths, they also need to be massaged to point from the EDK directory without revealing host complete paths. Also, the EDK now keeps the imacros on a different flag, `LLEXT_GENERATED_IMACROS_CFLAGS`, to keep it similar to other generated includes. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-04-14 07:04:01 +08:00
file(MAKE_DIRECTORY ${llext_edk_inc})
foreach(dir ${include_dirs})
if (NOT EXISTS ${dir})
continue()
endif()
relative_dir(${dir} dest bindir)
cmake: New target which generates a sort of development kit for llext Loadable extensions need access to Zephyr (and Zephyr application) includes and some CFLAGS to be properly built. This patch adds a new target, `llext-edk`, which generates a tar file with those includes and flags that can be loaded from cmake and make files. A Zephyr application willing to expose some API to extensions it loads only need to add the include directories describing such APIs to the Zephyr ones via zephyr_include_directories() CMake call. A new Kconfig option, CONFIG_LLEXT_EDK_NAME allows one to control some aspects of the generated file, which enables some customization - think of an application called ACME, willing to have a ACME_EXTENSION_KIT or something. All EDK Kconfig options are behind CONFIG_LLEXT_EDK, which doesn't depend on LLEXT directly - so that EDK features can be leveraged by downstream variations of loadable extensions. Also, each arch may need different compiler flags for extensions: those are handled by the `LLEXT_CFLAGS` cmake flag. An example is set for GCC ARM. Finally, EDK throughout this patch means Extension Development Kit, which is a bad name, but at least doesn't conflict with SDK. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-01-19 12:28:46 +08:00
# Use destination parent, as the last part of the source directory is copied as well
cmake_path(GET dest PARENT_PATH dest_p)
file(MAKE_DIRECTORY ${dest_p})
file(COPY ${dir} DESTINATION ${dest_p} FILES_MATCHING PATTERN "*.h")
cmake_path(RELATIVE_PATH dest BASE_DIRECTORY ${llext_edk} OUTPUT_VARIABLE dest_rel)
cmake: Handle `imacros` from flags Instead of hardcoding `autoconf.h` imacro, get the list of imacros from the llext flags. As those come in the form of absolute paths, they also need to be massaged to point from the EDK directory without revealing host complete paths. Also, the EDK now keeps the imacros on a different flag, `LLEXT_GENERATED_IMACROS_CFLAGS`, to keep it similar to other generated includes. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-04-14 07:04:01 +08:00
if(bindir)
cmake/llext-edk: Generate more granular CFLAGS Besides the LLEXT_CFLAGS, which have all that is needed to compile, generate more granular ones, LLEXT_INCLUDE_CFLAGS, LLEXT_ALL_INCLUDE_CFLAGS, LLEXT_GENERATED_INCLUDE_CFLAGS and LLEXT_BASE_CFLAGS. These are done for convenience, as they can help on different setups, such as unit testing. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-02-29 06:45:32 +08:00
list(APPEND inc_gen_flags_make "-I\$(${install_dir_var})/${dest_rel}")
list(APPEND inc_gen_flags_cmake "-I\${CMAKE_CURRENT_LIST_DIR}/${dest_rel}")
cmake: Handle `imacros` from flags Instead of hardcoding `autoconf.h` imacro, get the list of imacros from the llext flags. As those come in the form of absolute paths, they also need to be massaged to point from the EDK directory without revealing host complete paths. Also, the EDK now keeps the imacros on a different flag, `LLEXT_GENERATED_IMACROS_CFLAGS`, to keep it similar to other generated includes. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-04-14 07:04:01 +08:00
else()
cmake/llext-edk: Generate more granular CFLAGS Besides the LLEXT_CFLAGS, which have all that is needed to compile, generate more granular ones, LLEXT_INCLUDE_CFLAGS, LLEXT_ALL_INCLUDE_CFLAGS, LLEXT_GENERATED_INCLUDE_CFLAGS and LLEXT_BASE_CFLAGS. These are done for convenience, as they can help on different setups, such as unit testing. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-02-29 06:45:32 +08:00
list(APPEND inc_flags_make "-I\$(${install_dir_var})/${dest_rel}")
list(APPEND inc_flags_cmake "-I\${CMAKE_CURRENT_LIST_DIR}/${dest_rel}")
endif()
list(APPEND all_inc_flags_make "-I\$(${install_dir_var})/${dest_rel}")
list(APPEND all_inc_flags_cmake "-I\${CMAKE_CURRENT_LIST_DIR}/${dest_rel}")
cmake: New target which generates a sort of development kit for llext Loadable extensions need access to Zephyr (and Zephyr application) includes and some CFLAGS to be properly built. This patch adds a new target, `llext-edk`, which generates a tar file with those includes and flags that can be loaded from cmake and make files. A Zephyr application willing to expose some API to extensions it loads only need to add the include directories describing such APIs to the Zephyr ones via zephyr_include_directories() CMake call. A new Kconfig option, CONFIG_LLEXT_EDK_NAME allows one to control some aspects of the generated file, which enables some customization - think of an application called ACME, willing to have a ACME_EXTENSION_KIT or something. All EDK Kconfig options are behind CONFIG_LLEXT_EDK, which doesn't depend on LLEXT directly - so that EDK features can be leveraged by downstream variations of loadable extensions. Also, each arch may need different compiler flags for extensions: those are handled by the `LLEXT_CFLAGS` cmake flag. An example is set for GCC ARM. Finally, EDK throughout this patch means Extension Development Kit, which is a bad name, but at least doesn't conflict with SDK. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-01-19 12:28:46 +08:00
endforeach()
subsys/llext: Generate syscalls stubs for EDK exclusively for userspace A new Kconfig option which generates syscall stubs assuming that extensions will always run on userspace, thus simplifying linking them, as there's no need for z_impl_ stubs (used for direct syscalls), CONFIG_LLEXT_EDK_USERSPACE_ONLY. While defining __ZEPHYR_USER__ could have the same effect for optmised builds, people building extensions on debug environments - thus non-optimised - would suffer, as they'd need to somehow make the stubs available (by either exporting the symbol or implementing dummy stubs). Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-02-28 07:05:47 +08:00
if(CONFIG_LLEXT_EDK_USERSPACE_ONLY)
# Copy syscall headers from edk directory, as they were regenerated there.
cmake: Handle `imacros` from flags Instead of hardcoding `autoconf.h` imacro, get the list of imacros from the llext flags. As those come in the form of absolute paths, they also need to be massaged to point from the EDK directory without revealing host complete paths. Also, the EDK now keeps the imacros on a different flag, `LLEXT_GENERATED_IMACROS_CFLAGS`, to keep it similar to other generated includes. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-04-14 07:04:01 +08:00
file(COPY ${PROJECT_BINARY_DIR}/edk/include/generated/ DESTINATION ${llext_edk_inc}/zephyr/include/generated)
subsys/llext: Generate syscalls stubs for EDK exclusively for userspace A new Kconfig option which generates syscall stubs assuming that extensions will always run on userspace, thus simplifying linking them, as there's no need for z_impl_ stubs (used for direct syscalls), CONFIG_LLEXT_EDK_USERSPACE_ONLY. While defining __ZEPHYR_USER__ could have the same effect for optmised builds, people building extensions on debug environments - thus non-optimised - would suffer, as they'd need to somehow make the stubs available (by either exporting the symbol or implementing dummy stubs). Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-02-28 07:05:47 +08:00
endif()
cmake/llext-edk: Generate more granular CFLAGS Besides the LLEXT_CFLAGS, which have all that is needed to compile, generate more granular ones, LLEXT_INCLUDE_CFLAGS, LLEXT_ALL_INCLUDE_CFLAGS, LLEXT_GENERATED_INCLUDE_CFLAGS and LLEXT_BASE_CFLAGS. These are done for convenience, as they can help on different setups, such as unit testing. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-02-29 06:45:32 +08:00
# Generate flags for Makefile
cmake: Handle `imacros` from flags Instead of hardcoding `autoconf.h` imacro, get the list of imacros from the llext flags. As those come in the form of absolute paths, they also need to be massaged to point from the EDK directory without revealing host complete paths. Also, the EDK now keeps the imacros on a different flag, `LLEXT_GENERATED_IMACROS_CFLAGS`, to keep it similar to other generated includes. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-04-14 07:04:01 +08:00
list(APPEND all_flags_make ${base_flags_make} ${imacros_gen_make} ${all_inc_flags_make})
cmake: New target which generates a sort of development kit for llext Loadable extensions need access to Zephyr (and Zephyr application) includes and some CFLAGS to be properly built. This patch adds a new target, `llext-edk`, which generates a tar file with those includes and flags that can be loaded from cmake and make files. A Zephyr application willing to expose some API to extensions it loads only need to add the include directories describing such APIs to the Zephyr ones via zephyr_include_directories() CMake call. A new Kconfig option, CONFIG_LLEXT_EDK_NAME allows one to control some aspects of the generated file, which enables some customization - think of an application called ACME, willing to have a ACME_EXTENSION_KIT or something. All EDK Kconfig options are behind CONFIG_LLEXT_EDK, which doesn't depend on LLEXT directly - so that EDK features can be leveraged by downstream variations of loadable extensions. Also, each arch may need different compiler flags for extensions: those are handled by the `LLEXT_CFLAGS` cmake flag. An example is set for GCC ARM. Finally, EDK throughout this patch means Extension Development Kit, which is a bad name, but at least doesn't conflict with SDK. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-01-19 12:28:46 +08:00
list(JOIN all_flags_make " " all_flags_str)
file(WRITE ${llext_edk}/Makefile.cflags "LLEXT_CFLAGS = ${all_flags_str}")
cmake/llext-edk: Generate more granular CFLAGS Besides the LLEXT_CFLAGS, which have all that is needed to compile, generate more granular ones, LLEXT_INCLUDE_CFLAGS, LLEXT_ALL_INCLUDE_CFLAGS, LLEXT_GENERATED_INCLUDE_CFLAGS and LLEXT_BASE_CFLAGS. These are done for convenience, as they can help on different setups, such as unit testing. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-02-29 06:45:32 +08:00
list(JOIN all_inc_flags_make " " all_inc_flags_str)
file(APPEND ${llext_edk}/Makefile.cflags "\n\nLLEXT_ALL_INCLUDE_CFLAGS = ${all_inc_flags_str}")
list(JOIN inc_flags_make " " inc_flags_str)
file(APPEND ${llext_edk}/Makefile.cflags "\n\nLLEXT_INCLUDE_CFLAGS = ${inc_flags_str}")
list(JOIN inc_gen_flags_make " " inc_gen_flags_str)
file(APPEND ${llext_edk}/Makefile.cflags "\n\nLLEXT_GENERATED_INCLUDE_CFLAGS = ${inc_gen_flags_str}")
list(JOIN base_flags_make " " base_flags_str)
file(APPEND ${llext_edk}/Makefile.cflags "\n\nLLEXT_BASE_CFLAGS = ${base_flags_str}")
cmake: Handle `imacros` from flags Instead of hardcoding `autoconf.h` imacro, get the list of imacros from the llext flags. As those come in the form of absolute paths, they also need to be massaged to point from the EDK directory without revealing host complete paths. Also, the EDK now keeps the imacros on a different flag, `LLEXT_GENERATED_IMACROS_CFLAGS`, to keep it similar to other generated includes. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-04-14 07:04:01 +08:00
list(JOIN imacros_gen_make " " imacros_gen_str)
file(APPEND ${llext_edk}/Makefile.cflags "\n\nLLEXT_GENERATED_IMACROS_CFLAGS = ${imacros_gen_str}")
cmake/llext-edk: Generate more granular CFLAGS Besides the LLEXT_CFLAGS, which have all that is needed to compile, generate more granular ones, LLEXT_INCLUDE_CFLAGS, LLEXT_ALL_INCLUDE_CFLAGS, LLEXT_GENERATED_INCLUDE_CFLAGS and LLEXT_BASE_CFLAGS. These are done for convenience, as they can help on different setups, such as unit testing. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-02-29 06:45:32 +08:00
# Generate flags for CMake
cmake: Flag for EDK Makefile.flags was being used on cmake.flags Another case of subtle typo. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-05-25 05:59:50 +08:00
list(APPEND all_flags_cmake ${base_flags_cmake} ${imacros_gen_cmake} ${all_inc_flags_cmake})
cmake: New target which generates a sort of development kit for llext Loadable extensions need access to Zephyr (and Zephyr application) includes and some CFLAGS to be properly built. This patch adds a new target, `llext-edk`, which generates a tar file with those includes and flags that can be loaded from cmake and make files. A Zephyr application willing to expose some API to extensions it loads only need to add the include directories describing such APIs to the Zephyr ones via zephyr_include_directories() CMake call. A new Kconfig option, CONFIG_LLEXT_EDK_NAME allows one to control some aspects of the generated file, which enables some customization - think of an application called ACME, willing to have a ACME_EXTENSION_KIT or something. All EDK Kconfig options are behind CONFIG_LLEXT_EDK, which doesn't depend on LLEXT directly - so that EDK features can be leveraged by downstream variations of loadable extensions. Also, each arch may need different compiler flags for extensions: those are handled by the `LLEXT_CFLAGS` cmake flag. An example is set for GCC ARM. Finally, EDK throughout this patch means Extension Development Kit, which is a bad name, but at least doesn't conflict with SDK. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-01-19 12:28:46 +08:00
file(WRITE ${llext_edk}/cmake.cflags "set(LLEXT_CFLAGS ${all_flags_cmake})")
cmake/llext-edk: Generate more granular CFLAGS Besides the LLEXT_CFLAGS, which have all that is needed to compile, generate more granular ones, LLEXT_INCLUDE_CFLAGS, LLEXT_ALL_INCLUDE_CFLAGS, LLEXT_GENERATED_INCLUDE_CFLAGS and LLEXT_BASE_CFLAGS. These are done for convenience, as they can help on different setups, such as unit testing. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-02-29 06:45:32 +08:00
file(APPEND ${llext_edk}/cmake.cflags "\n\nset(LLEXT_ALL_INCLUDE_CFLAGS ${all_inc_flags_cmake})")
file(APPEND ${llext_edk}/cmake.cflags "\n\nset(LLEXT_INCLUDE_CFLAGS ${inc_flags_cmake})")
file(APPEND ${llext_edk}/cmake.cflags "\n\nset(LLEXT_GENERATED_INCLUDE_CFLAGS ${inc_gen_flags_cmake})")
file(APPEND ${llext_edk}/cmake.cflags "\n\nset(LLEXT_BASE_CFLAGS ${base_flags_cmake})")
cmake: Handle `imacros` from flags Instead of hardcoding `autoconf.h` imacro, get the list of imacros from the llext flags. As those come in the form of absolute paths, they also need to be massaged to point from the EDK directory without revealing host complete paths. Also, the EDK now keeps the imacros on a different flag, `LLEXT_GENERATED_IMACROS_CFLAGS`, to keep it similar to other generated includes. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-04-14 07:04:01 +08:00
file(APPEND ${llext_edk}/cmake.cflags "\n\nset(LLEXT_GENERATED_IMACROS_CFLAGS ${imacros_gen_cmake})")
cmake/llext-edk: Generate more granular CFLAGS Besides the LLEXT_CFLAGS, which have all that is needed to compile, generate more granular ones, LLEXT_INCLUDE_CFLAGS, LLEXT_ALL_INCLUDE_CFLAGS, LLEXT_GENERATED_INCLUDE_CFLAGS and LLEXT_BASE_CFLAGS. These are done for convenience, as they can help on different setups, such as unit testing. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-02-29 06:45:32 +08:00
# Generate the tarball
cmake: New target which generates a sort of development kit for llext Loadable extensions need access to Zephyr (and Zephyr application) includes and some CFLAGS to be properly built. This patch adds a new target, `llext-edk`, which generates a tar file with those includes and flags that can be loaded from cmake and make files. A Zephyr application willing to expose some API to extensions it loads only need to add the include directories describing such APIs to the Zephyr ones via zephyr_include_directories() CMake call. A new Kconfig option, CONFIG_LLEXT_EDK_NAME allows one to control some aspects of the generated file, which enables some customization - think of an application called ACME, willing to have a ACME_EXTENSION_KIT or something. All EDK Kconfig options are behind CONFIG_LLEXT_EDK, which doesn't depend on LLEXT directly - so that EDK features can be leveraged by downstream variations of loadable extensions. Also, each arch may need different compiler flags for extensions: those are handled by the `LLEXT_CFLAGS` cmake flag. An example is set for GCC ARM. Finally, EDK throughout this patch means Extension Development Kit, which is a bad name, but at least doesn't conflict with SDK. Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
2024-01-19 12:28:46 +08:00
file(ARCHIVE_CREATE
OUTPUT ${llext_edk_file}
PATHS ${llext_edk}
FORMAT gnutar
COMPRESSION XZ
)
file(REMOVE_RECURSE ${llext_edk})