The esp_libc relies on the stdio implementation of the vfs component if
CONFIG_VFS_SUPPORT_IO is enabled. This is not an issue in cmakev1
because if the vfs component is not included in the project build, its
configuration is not available, and CONFIG_VFS_SUPPORT_IO is not set.
However, in cmakev2, the configuration for all components is available,
and the presence of some component configuration options does not
necessarily mean that the component is included in the project build.
When esp_libc is compiled without the vfs dependency but with
CONFIG_VFS_SUPPORT_IO enabled, the libc initialization will encounter a
panic due to a NULL pointer dereference (fp->_flags) in __swsetup_r, as
fopen in esp_libc_init_global_stdio will return NULL.
The `includes` list variable is used without initialization. Initialize
it explicitly.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently, the lwip is linked to mbedtls if CONFIG_LWIP_ENABLE is set.
This approach works in cmakev1 because only the configuration for
BUILD_COMPONENTS is available during component evaluation. However, this
is not the case in cmakev2, where the configuration for all components
is available. This means that even if CONFIG_LWIP_ENABLE is set, it does
not guarantee that the lwip component is included in the build. For
cmakev2, modify the check to use a generator expression to ensure that
lwip is linked to mbedtls only if lwip is actually included in the
build.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
In cmakev2, the component CMakeLists.txt files are evaluated recursively
based on the component dependencies. This means that variables from
previously evaluated components are set and available in the scope of
the currently evaluated component. It is necessary to initialize every
variable that is used.
Fixes: 56e0c11bb6 ("feat(usb_cdc_console): moved usb-cdc ROM console to n..")
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
In cmakev2, the project_include.cmake files for every component are
included. This means that even when working with RISC-V, the
project_include.cmake file for Xtensa is still included. Ensure that the
architecture is verified, and exit if it is not Xtensa.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
IDF_BUILD_V2 does not have BUILD_COMPONENTS build property. Therefore,
when IDF_BUILD_V2 is defined, use a generator expressions instead.
The inclusion of esp_eth_netif_glue.c, which relies on the presence of
the esp_netif component, should ideally be managed by a configuration
option. The same applies to the requirements for esp_eth. Currently,
only a basic adjustment has been made to enable the inclusion of esp_eth
in cmakev2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
IDF_BUILD_V2 does not have BUILD_COMPONENTS build property. Therefore,
when IDF_BUILD_V2 is defined, use idf_component_optional_requires and
generator expressions instead. I believe that the one-liner should also
work with IDF_BUILD_V1, but the change is kept separate to clearly show
the difference between IDF_BUILD_V1 and IDF_BUILD_V2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
IDF_BUILD_V2 does not have BUILD_COMPONENTS build property. Therefore,
when IDF_BUILD_V2 is defined, use a generator expressions instead. I
believe that the one-liner should also work with IDF_BUILD_V1, but the
change is kept separate to clearly show the difference between
IDF_BUILD_V1 and IDF_BUILD_V2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
