Add pytest test coverage for cmakev2 build system examples that had
none.
CMakeLists.txt fixes required to enable testing:
conditional_component and plugins: added idf_build_generate_flasher_args()
since these use the low-level build API (idf_build_executable /
idf_flash_binary) which unlike idf_project_default() does not call it
automatically. Without it, flasher_args.json was missing from the build
output and pytest-embedded could not initialize the DUT.
multi_binary: both app1 and app2 were registered in the global flash
target via idf_flash_binary(...FLASH), creating a duplicate key at offset
0x10000 in the flasher_args.json generator expression and preventing the
file from being generated. Fixed by removing FLASH from app2's call so
only app1 is registered in the global flash target. idf_build_generate_flasher_args()
now produces a valid flasher_args.json with app1 as the default app binary.
The test patches the binary path to app2.bin when testing the second app.
This commit adds a new example at
examples/build_system/cmakev2/features/import_lib_direct to
demonstrate the cmakev2 ability to integrate with external CMake
projects easily.
This commit adds a new example at
examples/build_system/cmakev2/features/multi_binary to
demonstrate the cmakev2 ability to build multiple binaries in a single
CMake project.
This commit adds a new example at
examples/build_system/cmakev2/features/conditional_components to
demonstrate the cmakev2 ability to conditionally include components in
the build based on Kconfig options.
This commit updates the examples/build_system/cmake/plugins
example for the new build system and adds the newly created example at
examples/build_system/cmakev2/features/plugins.
This commit updates the examples/build_system/cmake/multi_config
example for the new build system and adds the newly created example at
examples/build_system/cmakev2/features/multi_config.
This commit updates the examples/build_system/cmake/import_prebuilt
example for the new build system and adds the newly created example at
examples/build_system/cmakev2/features/import_prebuilt.
This commit updates the examples/build_system/cmake/import_lib
example for the new build system and adds the newly created example at
examples/build_system/cmakev2/features/import_lib.
This commit updates the examples/build_system/cmake/component_manager
example for the new build system and adds the newly created example at
examples/build_system/cmakev2/features/component_manager.
This commit updates the examples/build_system/cmake/idf_as_lib
example for the new build system and adds the newly created example at
examples/build_system/cmakev2/features/idf_as_lib.
This commit updates the examples/get-started/hello_world example for the
new build system and adds the newly created example at
examples/build_system/cmakev2/get_started/hello_world.
This commit adds a new idf.py --preset NAME argument, which allows
selecting the CMake configuration preset with a given name.
For idf.py, selecting the preset does two things:
- sets the build directory, which is specified in the preset itself
using "binaryDir" field
- passes --preset argument to CMake configuration phase
The multi_config example is updated to illustrate how this feature is
expected to be used.
Initially, ESP-IDF used the do_global_ctors() function to run global
constructors. This was done to accommodate Xtensa targets that emit
.ctors.* sections, which are ordered in descending order.
For RISC-V, compilation used .init_array.* sections, which are designed
to have ascending order. Priority constructors in .init_array.* sections
were correctly processed in ascending order. However, non-priority
.init_array section was processed in descending order, as it was done
for Xtensa .ctors.
Starting with ESP-IDF v6.0, the implementation switched to the standard
LibC behavior (__libc_init_array()), which processes both priority and
non-priority constructors in ascending order.
To achieve this, a breaking changes were introduced:
- Xtensa .ctors.* priority entries converted to .init_array.* format
(ascending), to be passed to __libc_init_array().
- Processing order of non-priority .init_array and .ctors sections was
changed from descending to ascending.
Also, this change introduces .preinit_array for linking. This may be
needed for some C++ or sanitizer features.
Related to https://github.com/espressif/esp-idf/issues/15529
The Linux build was broken after IDF flash API was updated without updating
the Linux stub library in the example. This commit updates the spi_flash stub
library such that:
- The API now matches same API as IDF's spi_flash component
- Links the stub_esp32 library to pull in basic types and defines
Example linux build of the example demonstrates "esp32" and "spi_flash" stub
libraries (roughly analogous to "esp_system" and "spi_flash" components).
This commit moves the "flash_ops.c" file to the "spi_flash" stub library as it
is a flash related funciton.
Also renamed the header to "esp_flash.h" (in order to match current header name
in IDF). This is a prerequisite to fixing the linux build of this example.
The build-esp32p4.sh and run-esp32p4.sh scripts are not symbolic links to the
base scripts, leading to a "permission denied" error. This commit changes their
types to symbolic links, in line with the other targets.
Set the COMPONENTS project variable to streamline the build process.
Although the minimal build feature could be used to specify plugin
components in the main component dependencies, it's more convenient to
set the plugin components at the project level. This approach also
allows for quick selection of which plugins to include in the
application.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently, several example dependencies rely on the fact that all
registered components are added to the build, along with components
specified in common requirements. This results in longer build times
because even unused components must be built. Switch all examples to use
idf_minimal_build to compile only the components actually required by
the example.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The import_lib example contained a fallback mirror for downloading tinyxml2 sources
but this link was dead. If this mirror was used it would cause the build to fail.
It corrupts environment on macOS runner because it uses shell, not docker-executor,
and makes all tree read-only for a non-root user.
+ Replace examples with real files in example README.md
Sudeep Mohanty
Marius Vikhammer
Fu Hanxi
C.S.M
Alexey Lapshin
Marek Fiala
Ivan Grokhotkov
Peter Dragun
Chen Jichang
igor.udot
Darian Leung
gaoxu
Frantisek Hrbata
Daniel Paul
wanlei
laokaiyao
Xiao Xufeng
Armando