alex/esp-idf
alex/esp-idf
1
0
Fork 0
mirror of https://github.com/espressif/esp-idf.git synced 2024-10-05 20:47:46 -04:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
4cafa3e76e
esp-idf/components/esp32/CMakeLists.txt

101 lines
4.2 KiB
CMake
Raw Normal View History

fix bug for cmake build system The path of ${SDKCONFIG_H} does not exist, should be replaced by ${sdkconfig_header}.
2019-09-09 03:46:47 -04:00
idf_build_get_property(sdkconfig_header SDKCONFIG_HEADER)
build system: Initial cmake support, work in progress
2018-01-11 21:49:13 -05:00
if(BOOTLOADER_BUILD)
cmake: Use cmake_lint project, tidy up all CMake source files
2018-02-26 23:45:30 -05:00
# For bootloader, all we need from esp32 is headers
components: use new component registration api
2019-04-28 03:38:23 -04:00
idf_component_register(INCLUDE_DIRS include)
cmake: use new signature form of target_link_library to link components !4452 used setting LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES to link components built under ESP-IDF build system. However, LINK_LIBRARIES does not produce behavior same as linking PRIVATE. This MR uses the new signature for target_link_libraries directly instead. This also moves setting dependencies during component registration rather than after all components have been processed. The consequence is that internally, components have to use the new signature form as well. This does not affect linking the components to external targets, such as with idf_as_lib example. This only affects linking additional libraries to ESP-IDF libraries outside component processing (after idf_build_process), which is not even possible for CMake<v3.13 as target_link_libraries is not valid for targets not created in current directory. See https://cmake.org/cmake/help/v3.13/policy/CMP0079.html#policy:CMP0079
2019-06-04 07:05:33 -04:00
target_linker_script(${COMPONENT_LIB} INTERFACE "ld/esp32.peripherals.ld")
build system: Initial cmake support, work in progress
2018-01-11 21:49:13 -05:00
else()
cmake: Use cmake_lint project, tidy up all CMake source files
2018-02-26 23:45:30 -05:00
# Regular app build
cmake: some formatting fixes Do not include bootloader in flash target when secure boot is enabled. Emit signing warning on all cases where signed apps are enabled (secure boot and signed images) Follow convention of capital letters for SECURE_BOOT_SIGNING_KEY variable, since it is relevant to other components, not just bootloader. Pass signing key and verification key via config, not requiring bootloader to know parent app dir. Misc. variables name corrections
2019-06-21 02:29:32 -04:00
set(srcs
"brownout.c"
"cache_err_int.c"
"cache_sram_mmu.c"
"clk.c"
"cpu_start.c"
"crosscore_int.c"
"dport_access.c"
"dport_panic_highint_hdl.S"
"esp_adapter.c"
"esp_timer_esp32.c"
"esp_himem.c"
"hw_random.c"
"int_wdt.c"
"intr_alloc.c"
"panic.c"
"pm_esp32.c"
"pm_trace.c"
"reset_reason.c"
"sleep_modes.c"
"spiram.c"
"spiram_psram.c"
"system_api.c"
"task_wdt.c")
components: use new component registration api
2019-04-28 03:38:23 -04:00
set(include_dirs "include")
set(requires driver esp_event efuse soc) #unfortunately rom/uart uses SOC registers directly
global: move the soc component out of the common list This MR removes the common dependency from every IDF components to the SOC component. Currently, in the ``idf_functions.cmake`` script, we include the header path of SOC component by default for all components. But for better code organization (or maybe also benifits to the compiling speed), we may remove the dependency to SOC components for most components except the driver and kernel related components. In CMAKE, we have two kinds of header visibilities (set by include path visibility): (Assume component A --(depends on)--> B, B is the current component) 1. public (``COMPONENT_ADD_INCLUDEDIRS``): means this path is visible to other depending components (A) (visible to A and B) 2. private (``COMPONENT_PRIV_INCLUDEDIRS``): means this path is only visible to source files inside the component (visible to B only) and we have two kinds of depending ways: (Assume component A --(depends on)--> B --(depends on)--> C, B is the current component) 1. public (```COMPONENT_REQUIRES```): means B can access to public include path of C. All other components rely on you (A) will also be available for the public headers. (visible to A, B) 2. private (``COMPONENT_PRIV_REQUIRES``): means B can access to public include path of C, but don't propagate this relation to other components (A). (visible to B) 1. remove the common requirement in ``idf_functions.cmake``, this makes the SOC components invisible to all other components by default. 2. if a component (for example, DRIVER) really needs the dependency to SOC, add a private dependency to SOC for it. 3. some other components that don't really depends on the SOC may still meet some errors saying "can't find header soc/...", this is because it's depended component (DRIVER) incorrectly include the header of SOC in its public headers. Moving all this kind of #include into source files, or private headers 4. Fix the include requirements for some file which miss sufficient #include directives. (Previously they include some headers by the long long long header include link) This is a breaking change. Previous code may depends on the long include chain. You may need to include the following headers for some files after this commit: - soc/soc.h - soc/soc_memory_layout.h - driver/gpio.h - esp_sleep.h The major broken include chain includes: 1. esp_system.h no longer includes esp_sleep.h. The latter includes driver/gpio.h and driver/touch_pad.h. 2. ets_sys.h no longer includes soc/soc.h 3. freertos/portmacro.h no longer includes soc/soc_memory_layout.h some peripheral headers no longer includes their hw related headers, e.g. rom/gpio.h no longer includes soc/gpio_pins.h and soc/gpio_reg.h BREAKING CHANGE
2019-04-03 01:17:38 -04:00
esp32: Component needs public dependency on tcpip_adapter Because of esp_event.h Closes https://github.com/espressif/esp-idf/issues/1954
2018-05-16 23:55:40 -04:00
# driver is a public requirement because esp_sleep.h uses gpio_num_t & touch_pad_t
esp32: Add firmware version to app Added a new structure esp_app_desc_t. It has info about firmware: version, secure_version, project_name, time/date build and IDF version. Added the ability to add a custom structure with a description of the firmware. The esp_app_desc_t is located in fixed place in start of ROM secotor. It is located after structures esp_image_header_t and esp_image_segment_header_t. app_version is filed from PROJECT_VER variable (if set in custom make file) or PROJECT_PATH/version.txt or git repo (git describe). Add API to get app_desc from partition.
2018-10-05 08:29:07 -04:00
# app_update is added here because cpu_start.c uses esp_ota_get_app_description() function.
components: use new component registration api
2019-04-28 03:38:23 -04:00
set(priv_requires app_trace app_update bootloader_support log mbedtls nvs_flash pthread
esp_wifi: refactor smartconfig callback to use esp event
2019-04-16 23:44:51 -04:00
spi_flash vfs wpa_supplicant espcoredump esp_common esp_wifi)
components: use new component registration api
2019-04-28 03:38:23 -04:00
set(fragments linker.lf ld/esp32_fragments.lf)
idf_component_register(SRCS "${srcs}"
INCLUDE_DIRS "${include_dirs}"
LDFRAGMENTS "${fragments}"
REQUIRES "${requires}"
PRIV_REQUIRES "${priv_requires}"
REQUIRED_IDF_TARGETS esp32)
build system: Initial cmake support, work in progress
2018-01-11 21:49:13 -05:00
cmake: use new signature form of target_link_library to link components !4452 used setting LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES to link components built under ESP-IDF build system. However, LINK_LIBRARIES does not produce behavior same as linking PRIVATE. This MR uses the new signature for target_link_libraries directly instead. This also moves setting dependencies during component registration rather than after all components have been processed. The consequence is that internally, components have to use the new signature form as well. This does not affect linking the components to external targets, such as with idf_as_lib example. This only affects linking additional libraries to ESP-IDF libraries outside component processing (after idf_build_process), which is not even possible for CMake<v3.13 as target_link_libraries is not valid for targets not created in current directory. See https://cmake.org/cmake/help/v3.13/policy/CMP0079.html#policy:CMP0079
2019-06-04 07:05:33 -04:00
target_linker_script(${COMPONENT_LIB} INTERFACE "${CMAKE_CURRENT_BINARY_DIR}/esp32_out.ld")
components: update with build system changes
2019-05-09 22:53:08 -04:00
# Rely on user code to define app_main
cmake: use new signature form of target_link_library to link components !4452 used setting LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES to link components built under ESP-IDF build system. However, LINK_LIBRARIES does not produce behavior same as linking PRIVATE. This MR uses the new signature for target_link_libraries directly instead. This also moves setting dependencies during component registration rather than after all components have been processed. The consequence is that internally, components have to use the new signature form as well. This does not affect linking the components to external targets, such as with idf_as_lib example. This only affects linking additional libraries to ESP-IDF libraries outside component processing (after idf_build_process), which is not even possible for CMake<v3.13 as target_link_libraries is not valid for targets not created in current directory. See https://cmake.org/cmake/help/v3.13/policy/CMP0079.html#policy:CMP0079
2019-06-04 07:05:33 -04:00
target_link_libraries(${COMPONENT_LIB} INTERFACE "-u app_main")
doc: update document of external memory
2018-09-21 02:33:18 -04:00
if(CONFIG_SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY)
esp32: Rename esp32.common.ld to esp32.project.ld to avoid build errors when downgrading Linker script generator produces build/esp32/esp32.common.ld from components/esp32/ld/esp32.common.ld.in This works fine until IDF is downgraded to V3.1 which uses components/esp32/ld/esp32.common.ld and doesn't track build/esp32/esp32.common.ld at all. At this point, the linker runs in the build/esp32 directory and "-T esp32.common.ld" picks up the linker script generated .ld file, which causes mis-builds. As reported on forums: https://esp32.com/viewtopic.php?f=13&t=9684&p=40105
2019-03-13 18:59:31 -04:00
# This has to be linked before esp32.project.ld
cmake: use new signature form of target_link_library to link components !4452 used setting LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES to link components built under ESP-IDF build system. However, LINK_LIBRARIES does not produce behavior same as linking PRIVATE. This MR uses the new signature for target_link_libraries directly instead. This also moves setting dependencies during component registration rather than after all components have been processed. The consequence is that internally, components have to use the new signature form as well. This does not affect linking the components to external targets, such as with idf_as_lib example. This only affects linking additional libraries to ESP-IDF libraries outside component processing (after idf_build_process), which is not even possible for CMake<v3.13 as target_link_libraries is not valid for targets not created in current directory. See https://cmake.org/cmake/help/v3.13/policy/CMP0079.html#policy:CMP0079
2019-06-04 07:05:33 -04:00
target_linker_script(${COMPONENT_LIB} INTERFACE "ld/esp32.extram.bss.ld")
cmake: separate app from idf lib project mbedtls: import mbedtls using unmodified cmake file
2018-11-11 02:36:10 -05:00
endif()
cmake: Add link-time dependencies for linker script files Requires some hackery around limitations in CMake's LINK_DEPENDS
2018-03-01 01:02:08 -05:00
components: update with build system changes
2019-05-09 22:53:08 -04:00
# Process the template file through the linker script generation mechanism, and use the output for linking the
# final binary
cmake: use new signature form of target_link_library to link components !4452 used setting LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES to link components built under ESP-IDF build system. However, LINK_LIBRARIES does not produce behavior same as linking PRIVATE. This MR uses the new signature for target_link_libraries directly instead. This also moves setting dependencies during component registration rather than after all components have been processed. The consequence is that internally, components have to use the new signature form as well. This does not affect linking the components to external targets, such as with idf_as_lib example. This only affects linking additional libraries to ESP-IDF libraries outside component processing (after idf_build_process), which is not even possible for CMake<v3.13 as target_link_libraries is not valid for targets not created in current directory. See https://cmake.org/cmake/help/v3.13/policy/CMP0079.html#policy:CMP0079
2019-06-04 07:05:33 -04:00
target_linker_script(${COMPONENT_LIB} INTERFACE "${CMAKE_CURRENT_LIST_DIR}/ld/esp32.project.ld.in"
ldgen: use user input filename for processed template Previously ldgen determines the output file name on its own. This commit makes it so that user can dictate what the output file name will be for the processed template, if the user needs it for something else.
2019-05-30 23:30:44 -04:00
PROCESS "${CMAKE_CURRENT_BINARY_DIR}/ld/esp32.project.ld")
build system: Initial cmake support, work in progress
2018-01-11 21:49:13 -05:00
cmake: use new signature form of target_link_library to link components !4452 used setting LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES to link components built under ESP-IDF build system. However, LINK_LIBRARIES does not produce behavior same as linking PRIVATE. This MR uses the new signature for target_link_libraries directly instead. This also moves setting dependencies during component registration rather than after all components have been processed. The consequence is that internally, components have to use the new signature form as well. This does not affect linking the components to external targets, such as with idf_as_lib example. This only affects linking additional libraries to ESP-IDF libraries outside component processing (after idf_build_process), which is not even possible for CMake<v3.13 as target_link_libraries is not valid for targets not created in current directory. See https://cmake.org/cmake/help/v3.13/policy/CMP0079.html#policy:CMP0079
2019-06-04 07:05:33 -04:00
target_linker_script(${COMPONENT_LIB} INTERFACE "ld/esp32.peripherals.ld")
target_link_libraries(${COMPONENT_LIB} PUBLIC gcc)
target_link_libraries(${COMPONENT_LIB} INTERFACE "-u call_user_start_cpu0")
build system: Initial cmake support, work in progress
2018-01-11 21:49:13 -05:00
cmake: Use cmake_lint project, tidy up all CMake source files
2018-02-26 23:45:30 -05:00
#ld_include_panic_highint_hdl is added as an undefined symbol because otherwise the
#linker will ignore panic_highint_hdl.S as it has no other files depending on any
#symbols in it.
cmake: use new signature form of target_link_library to link components !4452 used setting LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES to link components built under ESP-IDF build system. However, LINK_LIBRARIES does not produce behavior same as linking PRIVATE. This MR uses the new signature for target_link_libraries directly instead. This also moves setting dependencies during component registration rather than after all components have been processed. The consequence is that internally, components have to use the new signature form as well. This does not affect linking the components to external targets, such as with idf_as_lib example. This only affects linking additional libraries to ESP-IDF libraries outside component processing (after idf_build_process), which is not even possible for CMake<v3.13 as target_link_libraries is not valid for targets not created in current directory. See https://cmake.org/cmake/help/v3.13/policy/CMP0079.html#policy:CMP0079
2019-06-04 07:05:33 -04:00
target_link_libraries(${COMPONENT_LIB} INTERFACE "-u ld_include_panic_highint_hdl")
build system: Initial cmake support, work in progress
2018-01-11 21:49:13 -05:00
cmake: set CONFIG_DIR build property Add CONFIG_DIR as a build property, so that components don't have to derive it from one of the generated config files.
2019-06-14 23:17:16 -04:00
idf_build_get_property(config_dir CONFIG_DIR)
cmake: Use cmake_lint project, tidy up all CMake source files
2018-02-26 23:45:30 -05:00
# Preprocess esp32.ld linker script to include configuration, becomes esp32_out.ld
set(LD_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ld)
add_custom_command(
OUTPUT esp32_out.ld
components: update with build system changes
2019-05-09 22:53:08 -04:00
COMMAND "${CMAKE_C_COMPILER}" -C -P -x c -E -o esp32_out.ld -I ${config_dir} ${LD_DIR}/esp32.ld
fix bug for cmake build system The path of ${SDKCONFIG_H} does not exist, should be replaced by ${sdkconfig_header}.
2019-09-09 03:46:47 -04:00
MAIN_DEPENDENCY ${LD_DIR}/esp32.ld ${sdkconfig_header}
cmake: Use cmake_lint project, tidy up all CMake source files
2018-02-26 23:45:30 -05:00
COMMENT "Generating linker script..."
VERBATIM)
feature: allow .bss segment in external memory
2018-09-14 06:28:18 -04:00
doc: update document of external memory
2018-09-21 02:33:18 -04:00
add_custom_target(esp32_linker_script DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/esp32_out.ld)
components: update with build system changes
2019-05-09 22:53:08 -04:00
add_dependencies(${COMPONENT_LIB} esp32_linker_script)
esp32: disable stack protector for startup code (CMake) Files where stack protector is initialized should not be compiled with stack protector enabled. This was done for Make but missing for CMake. Fixes https://github.com/espressif/esp-idf/issues/2990.
2019-01-29 04:41:00 -05:00
# disable stack protection in files which are involved in initialization of that feature
set_source_files_properties(
move common source files from esp32 to esp_common
2019-03-21 00:21:01 -04:00
cpu_start.c
esp32: disable stack protector for startup code (CMake) Files where stack protector is initialized should not be compiled with stack protector enabled. This was done for Make but missing for CMake. Fixes https://github.com/espressif/esp-idf/issues/2990.
2019-01-29 04:41:00 -05:00
PROPERTIES COMPILE_FLAGS
-fno-stack-protector)
cmake: For gcc8 use linker to find paths to libc, libm, libstdc++, etc Removes the need to know/guess the paths to these libraries. Once we are gcc 8 only, we can remove -nostdlib and no additional arguments are needed for system libraries. The catch is: any time IDF overrides a symbol in the toolchain sysroot, we need an undefined linker marker to make sure this symbol is seen by linker.
2019-04-14 23:45:08 -04:00
if(CONFIG_SPIRAM_CACHE_WORKAROUND)
# Note: Adding as a PUBLIC compile option here causes this option to propagate to all components that depend on esp32.
#
# To handle some corner cases, the same flag is set in project_include.cmake
target_compile_options(${COMPONENT_LIB} PUBLIC -mfix-esp32-psram-cache-issue)
# also, make sure we link with this option so correct toolchain libs are pulled in
cmake: use new signature form of target_link_library to link components !4452 used setting LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES to link components built under ESP-IDF build system. However, LINK_LIBRARIES does not produce behavior same as linking PRIVATE. This MR uses the new signature for target_link_libraries directly instead. This also moves setting dependencies during component registration rather than after all components have been processed. The consequence is that internally, components have to use the new signature form as well. This does not affect linking the components to external targets, such as with idf_as_lib example. This only affects linking additional libraries to ESP-IDF libraries outside component processing (after idf_build_process), which is not even possible for CMake<v3.13 as target_link_libraries is not valid for targets not created in current directory. See https://cmake.org/cmake/help/v3.13/policy/CMP0079.html#policy:CMP0079
2019-06-04 07:05:33 -04:00
target_link_libraries(${COMPONENT_LIB} PUBLIC -mfix-esp32-psram-cache-issue)
cmake: For gcc8 use linker to find paths to libc, libm, libstdc++, etc Removes the need to know/guess the paths to these libraries. Once we are gcc 8 only, we can remove -nostdlib and no additional arguments are needed for system libraries. The catch is: any time IDF overrides a symbol in the toolchain sysroot, we need an undefined linker marker to make sure this symbol is seen by linker.
2019-04-14 23:45:08 -04:00
endif()
cmake: Use cmake_lint project, tidy up all CMake source files
2018-02-26 23:45:30 -05:00
endif()
Reference in New Issue Copy Permalink