micropython/ports/esp32/esp32_common.cmake

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

234 lines
6.2 KiB
CMake
Raw Normal View History

# Set location of base MicroPython directory.
if(NOT MICROPY_DIR)
get_filename_component(MICROPY_DIR ${CMAKE_CURRENT_LIST_DIR}/../.. ABSOLUTE)
esp32/CMake: Change PROJECT_DIR to CMAKE_CURRENT_LIST_DIR. This migrates the CMake variable `MICROPY_PORT_DIR` from the ESP-IDF defined project to the component. Previously used instances of the variable within the project definition have been migrated to `CMAKE_CURRENT_LIST_DIR`. Within the component (the `main` subdirectory in the ESP32 port) we define `MICROPY_PORT_DIR` using `CMAKE_CURRENT_LIST_DIR` and subsequently use the `MICROPY_PORT_DIR` value in all locations where `PROJECT` had previously been used. Context: In commit 9b90882146, initial support was added for building with the newly introduced CMake support provided by the ESP-IDF. Specifically, the commit message states: > This commit adds support for building the esp32 port with CMake, and in particular, it builds MicroPython as a component within the ESP-IDF. Using CMake and the ESP-IDF build infrastructure makes it much easier to maintain the port, especially with the various new ESP32 MCUs and their required toolchains. `PROJECT_DIR` is a variable populated by the ESP-IDF specifically and is not stable when used with "[Pure CMake components][1]" as documented in the ESP-IDF. It is intended to be used in the scope of the parent of the current file (the "project") as opposed to the current file ("the component"). Crossing into the parent scope like this works solely when the "project" is MicroPython, but not when used as a component by other ESP-IDF projects. Analyzing this file, the intention is to reference the "Project" which in the example is the parent directory. Within the [CMake variables][2] documentation, there is one specifically defined for referencing the directory for the CMake listfile currently being processed: [`CMAKE_CURRENT_LIST_DIR`][3]. After making the change from `PROJECT_DIR` to `CMAKE_CURRENT_LIST_DIR`, the reach into the parent scope defined by the ESP-IDF and the resulting CMake interface violation is removed. Similar to the component definition, the project `CMakeLists.txt` uses the variable `CMAKE_SOURCE_DIR` which CMake defines as "The path to the top level of the source tree." This commit changes the variable to `CMAKE_CURRENT_LIST_DIR` for the reasons cited above. [1]: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/build-system.html#writing-pure-cmake-components [2]: https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html [3]: https://cmake.org/cmake/help/latest/variable/CMAKE_CURRENT_LIST_DIR.html Signed-off-by: Brian 'redbeard' Harrington <redbeard@dead-city.org>
2023-06-12 21:02:10 +01:00
endif()
# Set location of the ESP32 port directory.
esp32/CMake: Change PROJECT_DIR to CMAKE_CURRENT_LIST_DIR. This migrates the CMake variable `MICROPY_PORT_DIR` from the ESP-IDF defined project to the component. Previously used instances of the variable within the project definition have been migrated to `CMAKE_CURRENT_LIST_DIR`. Within the component (the `main` subdirectory in the ESP32 port) we define `MICROPY_PORT_DIR` using `CMAKE_CURRENT_LIST_DIR` and subsequently use the `MICROPY_PORT_DIR` value in all locations where `PROJECT` had previously been used. Context: In commit 9b90882146, initial support was added for building with the newly introduced CMake support provided by the ESP-IDF. Specifically, the commit message states: > This commit adds support for building the esp32 port with CMake, and in particular, it builds MicroPython as a component within the ESP-IDF. Using CMake and the ESP-IDF build infrastructure makes it much easier to maintain the port, especially with the various new ESP32 MCUs and their required toolchains. `PROJECT_DIR` is a variable populated by the ESP-IDF specifically and is not stable when used with "[Pure CMake components][1]" as documented in the ESP-IDF. It is intended to be used in the scope of the parent of the current file (the "project") as opposed to the current file ("the component"). Crossing into the parent scope like this works solely when the "project" is MicroPython, but not when used as a component by other ESP-IDF projects. Analyzing this file, the intention is to reference the "Project" which in the example is the parent directory. Within the [CMake variables][2] documentation, there is one specifically defined for referencing the directory for the CMake listfile currently being processed: [`CMAKE_CURRENT_LIST_DIR`][3]. After making the change from `PROJECT_DIR` to `CMAKE_CURRENT_LIST_DIR`, the reach into the parent scope defined by the ESP-IDF and the resulting CMake interface violation is removed. Similar to the component definition, the project `CMakeLists.txt` uses the variable `CMAKE_SOURCE_DIR` which CMake defines as "The path to the top level of the source tree." This commit changes the variable to `CMAKE_CURRENT_LIST_DIR` for the reasons cited above. [1]: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/build-system.html#writing-pure-cmake-components [2]: https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html [3]: https://cmake.org/cmake/help/latest/variable/CMAKE_CURRENT_LIST_DIR.html Signed-off-by: Brian 'redbeard' Harrington <redbeard@dead-city.org>
2023-06-12 21:02:10 +01:00
if(NOT MICROPY_PORT_DIR)
get_filename_component(MICROPY_PORT_DIR ${MICROPY_DIR}/ports/esp32 ABSOLUTE)
endif()
# Include core source components.
include(${MICROPY_DIR}/py/py.cmake)
# CMAKE_BUILD_EARLY_EXPANSION is set during the component-discovery phase of
# `idf.py build`, so none of the extmod/usermod (and in reality, most of the
# micropython) rules need to happen. Specifically, you cannot invoke add_library.
if(NOT CMAKE_BUILD_EARLY_EXPANSION)
# Enable extmod components that will be configured by extmod.cmake.
# A board may also have enabled additional components.
set(MICROPY_PY_BTREE ON)
include(${MICROPY_DIR}/py/usermod.cmake)
include(${MICROPY_DIR}/extmod/extmod.cmake)
endif()
list(APPEND MICROPY_QSTRDEFS_PORT
esp32/CMake: Change PROJECT_DIR to CMAKE_CURRENT_LIST_DIR. This migrates the CMake variable `MICROPY_PORT_DIR` from the ESP-IDF defined project to the component. Previously used instances of the variable within the project definition have been migrated to `CMAKE_CURRENT_LIST_DIR`. Within the component (the `main` subdirectory in the ESP32 port) we define `MICROPY_PORT_DIR` using `CMAKE_CURRENT_LIST_DIR` and subsequently use the `MICROPY_PORT_DIR` value in all locations where `PROJECT` had previously been used. Context: In commit 9b90882146, initial support was added for building with the newly introduced CMake support provided by the ESP-IDF. Specifically, the commit message states: > This commit adds support for building the esp32 port with CMake, and in particular, it builds MicroPython as a component within the ESP-IDF. Using CMake and the ESP-IDF build infrastructure makes it much easier to maintain the port, especially with the various new ESP32 MCUs and their required toolchains. `PROJECT_DIR` is a variable populated by the ESP-IDF specifically and is not stable when used with "[Pure CMake components][1]" as documented in the ESP-IDF. It is intended to be used in the scope of the parent of the current file (the "project") as opposed to the current file ("the component"). Crossing into the parent scope like this works solely when the "project" is MicroPython, but not when used as a component by other ESP-IDF projects. Analyzing this file, the intention is to reference the "Project" which in the example is the parent directory. Within the [CMake variables][2] documentation, there is one specifically defined for referencing the directory for the CMake listfile currently being processed: [`CMAKE_CURRENT_LIST_DIR`][3]. After making the change from `PROJECT_DIR` to `CMAKE_CURRENT_LIST_DIR`, the reach into the parent scope defined by the ESP-IDF and the resulting CMake interface violation is removed. Similar to the component definition, the project `CMakeLists.txt` uses the variable `CMAKE_SOURCE_DIR` which CMake defines as "The path to the top level of the source tree." This commit changes the variable to `CMAKE_CURRENT_LIST_DIR` for the reasons cited above. [1]: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/build-system.html#writing-pure-cmake-components [2]: https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html [3]: https://cmake.org/cmake/help/latest/variable/CMAKE_CURRENT_LIST_DIR.html Signed-off-by: Brian 'redbeard' Harrington <redbeard@dead-city.org>
2023-06-12 21:02:10 +01:00
${MICROPY_PORT_DIR}/qstrdefsport.h
)
list(APPEND MICROPY_SOURCE_SHARED
${MICROPY_DIR}/shared/readline/readline.c
${MICROPY_DIR}/shared/netutils/netutils.c
${MICROPY_DIR}/shared/timeutils/timeutils.c
${MICROPY_DIR}/shared/runtime/interrupt_char.c
${MICROPY_DIR}/shared/runtime/stdout_helpers.c
${MICROPY_DIR}/shared/runtime/sys_stdio_mphal.c
${MICROPY_DIR}/shared/runtime/pyexec.c
)
list(APPEND MICROPY_SOURCE_LIB
${MICROPY_DIR}/lib/littlefs/lfs1.c
${MICROPY_DIR}/lib/littlefs/lfs1_util.c
${MICROPY_DIR}/lib/littlefs/lfs2.c
${MICROPY_DIR}/lib/littlefs/lfs2_util.c
#${MICROPY_DIR}/lib/mbedtls_errors/esp32_mbedtls_errors.c
${MICROPY_DIR}/lib/oofatfs/ff.c
${MICROPY_DIR}/lib/oofatfs/ffunicode.c
)
list(APPEND MICROPY_SOURCE_DRIVERS
${MICROPY_DIR}/drivers/bus/softspi.c
${MICROPY_DIR}/drivers/dht/dht.c
)
list(APPEND MICROPY_SOURCE_PORT
esp32/CMake: Change PROJECT_DIR to CMAKE_CURRENT_LIST_DIR. This migrates the CMake variable `MICROPY_PORT_DIR` from the ESP-IDF defined project to the component. Previously used instances of the variable within the project definition have been migrated to `CMAKE_CURRENT_LIST_DIR`. Within the component (the `main` subdirectory in the ESP32 port) we define `MICROPY_PORT_DIR` using `CMAKE_CURRENT_LIST_DIR` and subsequently use the `MICROPY_PORT_DIR` value in all locations where `PROJECT` had previously been used. Context: In commit 9b90882146, initial support was added for building with the newly introduced CMake support provided by the ESP-IDF. Specifically, the commit message states: > This commit adds support for building the esp32 port with CMake, and in particular, it builds MicroPython as a component within the ESP-IDF. Using CMake and the ESP-IDF build infrastructure makes it much easier to maintain the port, especially with the various new ESP32 MCUs and their required toolchains. `PROJECT_DIR` is a variable populated by the ESP-IDF specifically and is not stable when used with "[Pure CMake components][1]" as documented in the ESP-IDF. It is intended to be used in the scope of the parent of the current file (the "project") as opposed to the current file ("the component"). Crossing into the parent scope like this works solely when the "project" is MicroPython, but not when used as a component by other ESP-IDF projects. Analyzing this file, the intention is to reference the "Project" which in the example is the parent directory. Within the [CMake variables][2] documentation, there is one specifically defined for referencing the directory for the CMake listfile currently being processed: [`CMAKE_CURRENT_LIST_DIR`][3]. After making the change from `PROJECT_DIR` to `CMAKE_CURRENT_LIST_DIR`, the reach into the parent scope defined by the ESP-IDF and the resulting CMake interface violation is removed. Similar to the component definition, the project `CMakeLists.txt` uses the variable `CMAKE_SOURCE_DIR` which CMake defines as "The path to the top level of the source tree." This commit changes the variable to `CMAKE_CURRENT_LIST_DIR` for the reasons cited above. [1]: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/build-system.html#writing-pure-cmake-components [2]: https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html [3]: https://cmake.org/cmake/help/latest/variable/CMAKE_CURRENT_LIST_DIR.html Signed-off-by: Brian 'redbeard' Harrington <redbeard@dead-city.org>
2023-06-12 21:02:10 +01:00
main.c
ppp_set_auth.c
esp32/CMake: Change PROJECT_DIR to CMAKE_CURRENT_LIST_DIR. This migrates the CMake variable `MICROPY_PORT_DIR` from the ESP-IDF defined project to the component. Previously used instances of the variable within the project definition have been migrated to `CMAKE_CURRENT_LIST_DIR`. Within the component (the `main` subdirectory in the ESP32 port) we define `MICROPY_PORT_DIR` using `CMAKE_CURRENT_LIST_DIR` and subsequently use the `MICROPY_PORT_DIR` value in all locations where `PROJECT` had previously been used. Context: In commit 9b90882146, initial support was added for building with the newly introduced CMake support provided by the ESP-IDF. Specifically, the commit message states: > This commit adds support for building the esp32 port with CMake, and in particular, it builds MicroPython as a component within the ESP-IDF. Using CMake and the ESP-IDF build infrastructure makes it much easier to maintain the port, especially with the various new ESP32 MCUs and their required toolchains. `PROJECT_DIR` is a variable populated by the ESP-IDF specifically and is not stable when used with "[Pure CMake components][1]" as documented in the ESP-IDF. It is intended to be used in the scope of the parent of the current file (the "project") as opposed to the current file ("the component"). Crossing into the parent scope like this works solely when the "project" is MicroPython, but not when used as a component by other ESP-IDF projects. Analyzing this file, the intention is to reference the "Project" which in the example is the parent directory. Within the [CMake variables][2] documentation, there is one specifically defined for referencing the directory for the CMake listfile currently being processed: [`CMAKE_CURRENT_LIST_DIR`][3]. After making the change from `PROJECT_DIR` to `CMAKE_CURRENT_LIST_DIR`, the reach into the parent scope defined by the ESP-IDF and the resulting CMake interface violation is removed. Similar to the component definition, the project `CMakeLists.txt` uses the variable `CMAKE_SOURCE_DIR` which CMake defines as "The path to the top level of the source tree." This commit changes the variable to `CMAKE_CURRENT_LIST_DIR` for the reasons cited above. [1]: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/build-system.html#writing-pure-cmake-components [2]: https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html [3]: https://cmake.org/cmake/help/latest/variable/CMAKE_CURRENT_LIST_DIR.html Signed-off-by: Brian 'redbeard' Harrington <redbeard@dead-city.org>
2023-06-12 21:02:10 +01:00
uart.c
usb.c
usb_serial_jtag.c
gccollect.c
mphalport.c
fatfs_port.c
help.c
machine_bitstream.c
machine_timer.c
machine_pin.c
machine_touchpad.c
machine_adc.c
machine_adcblock.c
machine_dac.c
machine_i2c.c
machine_i2s.c
machine_uart.c
modmachine.c
network_common.c
network_lan.c
network_ppp.c
network_wlan.c
mpnimbleport.c
modsocket.c
modesp.c
esp32_nvs.c
esp32_partition.c
esp32_rmt.c
esp32_ulp.c
modesp32.c
machine_hw_spi.c
machine_wdt.c
mpthreadport.c
machine_rtc.c
machine_sdcard.c
modespnow.c
)
esp32/CMake: Change PROJECT_DIR to CMAKE_CURRENT_LIST_DIR. This migrates the CMake variable `MICROPY_PORT_DIR` from the ESP-IDF defined project to the component. Previously used instances of the variable within the project definition have been migrated to `CMAKE_CURRENT_LIST_DIR`. Within the component (the `main` subdirectory in the ESP32 port) we define `MICROPY_PORT_DIR` using `CMAKE_CURRENT_LIST_DIR` and subsequently use the `MICROPY_PORT_DIR` value in all locations where `PROJECT` had previously been used. Context: In commit 9b90882146, initial support was added for building with the newly introduced CMake support provided by the ESP-IDF. Specifically, the commit message states: > This commit adds support for building the esp32 port with CMake, and in particular, it builds MicroPython as a component within the ESP-IDF. Using CMake and the ESP-IDF build infrastructure makes it much easier to maintain the port, especially with the various new ESP32 MCUs and their required toolchains. `PROJECT_DIR` is a variable populated by the ESP-IDF specifically and is not stable when used with "[Pure CMake components][1]" as documented in the ESP-IDF. It is intended to be used in the scope of the parent of the current file (the "project") as opposed to the current file ("the component"). Crossing into the parent scope like this works solely when the "project" is MicroPython, but not when used as a component by other ESP-IDF projects. Analyzing this file, the intention is to reference the "Project" which in the example is the parent directory. Within the [CMake variables][2] documentation, there is one specifically defined for referencing the directory for the CMake listfile currently being processed: [`CMAKE_CURRENT_LIST_DIR`][3]. After making the change from `PROJECT_DIR` to `CMAKE_CURRENT_LIST_DIR`, the reach into the parent scope defined by the ESP-IDF and the resulting CMake interface violation is removed. Similar to the component definition, the project `CMakeLists.txt` uses the variable `CMAKE_SOURCE_DIR` which CMake defines as "The path to the top level of the source tree." This commit changes the variable to `CMAKE_CURRENT_LIST_DIR` for the reasons cited above. [1]: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/build-system.html#writing-pure-cmake-components [2]: https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html [3]: https://cmake.org/cmake/help/latest/variable/CMAKE_CURRENT_LIST_DIR.html Signed-off-by: Brian 'redbeard' Harrington <redbeard@dead-city.org>
2023-06-12 21:02:10 +01:00
list(TRANSFORM MICROPY_SOURCE_PORT PREPEND ${MICROPY_PORT_DIR}/)
list(APPEND MICROPY_SOURCE_PORT ${CMAKE_BINARY_DIR}/pins.c)
list(APPEND MICROPY_SOURCE_QSTR
${MICROPY_SOURCE_PY}
${MICROPY_SOURCE_EXTMOD}
${MICROPY_SOURCE_USERMOD}
${MICROPY_SOURCE_SHARED}
${MICROPY_SOURCE_LIB}
${MICROPY_SOURCE_PORT}
${MICROPY_SOURCE_BOARD}
)
list(APPEND IDF_COMPONENTS
app_update
bootloader_support
bt
driver
esp_adc
esp_app_format
esp_common
esp_eth
esp_event
esp_hw_support
esp_netif
esp_partition
esp_pm
esp_psram
esp_ringbuf
esp_rom
esp_system
esp_timer
esp_wifi
freertos
hal
heap
log
lwip
mbedtls
newlib
nvs_flash
sdmmc
soc
spi_flash
ulp
vfs
xtensa
)
# Register the main IDF component.
idf_component_register(
SRCS
${MICROPY_SOURCE_PY}
${MICROPY_SOURCE_EXTMOD}
${MICROPY_SOURCE_SHARED}
${MICROPY_SOURCE_LIB}
${MICROPY_SOURCE_DRIVERS}
${MICROPY_SOURCE_PORT}
${MICROPY_SOURCE_BOARD}
INCLUDE_DIRS
${MICROPY_INC_CORE}
${MICROPY_INC_USERMOD}
${MICROPY_PORT_DIR}
${MICROPY_BOARD_DIR}
${CMAKE_BINARY_DIR}
REQUIRES
${IDF_COMPONENTS}
)
# Set the MicroPython target as the current (main) IDF component target.
set(MICROPY_TARGET ${COMPONENT_TARGET})
# Define mpy-cross flags, for use with frozen code.
set(MICROPY_CROSS_FLAGS -march=xtensawin)
# Set compile options for this port.
target_compile_definitions(${MICROPY_TARGET} PUBLIC
${MICROPY_DEF_CORE}
${MICROPY_DEF_BOARD}
MICROPY_ESP_IDF_4=1
MICROPY_VFS_FAT=1
MICROPY_VFS_LFS2=1
FFCONF_H=\"${MICROPY_OOFATFS_DIR}/ffconf.h\"
LFS1_NO_MALLOC LFS1_NO_DEBUG LFS1_NO_WARN LFS1_NO_ERROR LFS1_NO_ASSERT
LFS2_NO_MALLOC LFS2_NO_DEBUG LFS2_NO_WARN LFS2_NO_ERROR LFS2_NO_ASSERT
)
# Disable some warnings to keep the build output clean.
target_compile_options(${MICROPY_TARGET} PUBLIC
-Wno-clobbered
-Wno-deprecated-declarations
-Wno-missing-field-initializers
)
# Additional include directories needed for private NimBLE headers.
target_include_directories(${MICROPY_TARGET} PUBLIC
${IDF_PATH}/components/bt/host/nimble/nimble
)
# Add additional extmod and usermod components.
target_link_libraries(${MICROPY_TARGET} micropy_extmod_btree)
target_link_libraries(${MICROPY_TARGET} usermod)
# Collect all of the include directories and compile definitions for the IDF components,
# including those added by the IDF Component Manager via idf_components.yaml.
foreach(comp ${__COMPONENT_NAMES_RESOLVED})
micropy_gather_target_properties(__idf_${comp})
micropy_gather_target_properties(${comp})
endforeach()
# Include the main MicroPython cmake rules.
include(${MICROPY_DIR}/py/mkrules.cmake)
# Generate source files for named pins (requires mkrules.cmake for MICROPY_GENHDR_DIR).
set(GEN_PINS_PREFIX "${MICROPY_PORT_DIR}/boards/pins_prefix.c")
set(GEN_PINS_MKPINS "${MICROPY_PORT_DIR}/boards/make-pins.py")
set(GEN_PINS_SRC "${CMAKE_BINARY_DIR}/pins.c")
set(GEN_PINS_HDR "${MICROPY_GENHDR_DIR}/pins.h")
if(EXISTS "${MICROPY_BOARD_DIR}/pins.csv")
set(GEN_PINS_BOARD_CSV "${MICROPY_BOARD_DIR}/pins.csv")
set(GEN_PINS_BOARD_CSV_ARG --board-csv "${GEN_PINS_BOARD_CSV}")
endif()
target_sources(${MICROPY_TARGET} PRIVATE ${GEN_PINS_HDR})
add_custom_command(
OUTPUT ${GEN_PINS_SRC} ${GEN_PINS_HDR}
COMMAND ${Python3_EXECUTABLE} ${GEN_PINS_MKPINS} ${GEN_PINS_BOARD_CSV_ARG}
--prefix ${GEN_PINS_PREFIX} --output-source ${GEN_PINS_SRC} --output-header ${GEN_PINS_HDR}
DEPENDS
${MICROPY_MPVERSION}
${GEN_PINS_MKPINS}
${GEN_PINS_BOARD_CSV}
${GEN_PINS_PREFIX}
VERBATIM
COMMAND_EXPAND_LISTS
)