This example shows how to use ESP-IDF build system features to build
multiple configurations of an app from the same source files.
Configurations are set by overriding SDKCONFIG_DEFAULTS variable when
invoking idf.py.
Related: https://github.com/espressif/esp-idf/issues/5658
* add toolchain file
* add linux to preview targets
* add stub for dfu number in cmake
* excluded unity runner per default
* Added esp_attr.h and esp_partition.h linux stubs
* component.cmake check list for emptyness
* added switch for linux in unity cmake file
* Added Linux host example app
Also add some explanation about configuring the project in the README
Previously with the default build-esp32.sh script, the build directory was
deleted and recreated so the project would always be built with default config.
GCC prefixes underscore on symbol names on macOS, and so the set
undefined symbol `-u app_main` won't work. However, this is unecessary,
as the source file that defines it is specified directly to the
executable, and not through a static library.
Closes https://github.com/espressif/esp-idf/issues/4168
The build system automatically determines offsets of partitions from
the partition table, so no manual changes are needed. Instead, add a
note that partition offsets may need to be updated when increasing
the bootloader size.
!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
Ivan Grokhotkov