Unlike COMPILE_OPTIONS, COMPILE_DEFINITIONS CMake property assumes
values without the -D prefix, such as NAME or NAME=VAL.
Previously, IDF build system was passing COMPILE_DEFINITIONS build
property to CMake COMPILE_OPTIONS property, so -D prefix was not
a problem.
Now that COMPILE_DEFINITIONS CMake property is used, -D prefix has
to be removed.
(Note that this doesn't affect 'target_compile_definitions' function,
which strips -D prefix before adding the definition to the property.)
Now that the supported CMake version is >=3.16, this code can be
simplified.
The code to deduplicate the directories can be removed since this is
handled by target_link_directories.
Related to https://github.com/espressif/esp-idf/issues/4162
Setting this option informs CMake that it should pass
-fcolor-diagnostics flag to the compiler.
(Colorized build system output, like from GNU Make, is produced even
without this flag.)
Note that if the build is done using Ninja and the build output is
redirected (not a TTY), Ninja will still strip the escape codes from
the output. For the case of idf.py, this is handled in the next
commit.
Related to https://github.com/espressif/esp-idf/issues/4162
Setting this option informs CMake that it should pass
-fcolor-diagnostics flag to the compiler.
(Colorized build system output, like from GNU Make, is produced even
without this flag.)
Note that if the build is done using Ninja and the build output is
redirected (not a TTY), Ninja will still strip the escape codes from
the output. For the case of idf.py, this is handled in the next
commit.
This adds CSV support to idf_size.py and idf.py size actions and using the --format argument which accepts 'text', 'json' or 'csv' as input.
idf_size.py --json argument is deprecated but left to avoid a breaking change.
For idf.py size actions OUTPUT_JSON environment variable set at configuration time is overriden at target build time if --format is used.
Additionally, this commit refactors big parts of code, unified usage of json_dict and manually generated dictionaries for textual output and improves code quality in many parts.
'linux' component provides some of the common header files, such as
'sys/queue.h' and 'sys/lock.h'. For chip targets, it is possible to
include these files without having to add any extra requirements.
With this change, the same behavior will apply for the linux target.
`__COMPONENT_TARGETS` is evaluated very early when components and
component directories are added to the build, which means that all
components (including the ones which are in EXCLUDE_COMPONENTS) have
a build system target defined. The component manager was given the
list of all known components (derived from the list of targets), not
the list of components after EXCLUDE_COMPONENTS were processed.
Because of that, EXCLUDE_COMPONENTS didn't effectively exclude the
component from the consideration of the component manager.
This updates the minimal supported version of CMake to 3.16, which in turn enables us to use more CMake features and have a cleaner build system.
This is the version that provides most new features and also the one we use in our latest docker image for CI.
After refactoring the target components (e.g. esp32) no longer contained any real functionality.
What remained in these components have been moved elsewhere and the component itself deleted from the
build system.
lwip was added to common requirements list to provide "sys/socket.h"
header to all components without additional requirements specified.
However, lwip pulls in a lot of dependencies on other components.
This commit removes lwip from common requirements to reduce the number
of components in G1-only apps.
To compensate for this removal, the following changes are made:
- newlib (which is a common requirement) has a public dependency on
lwip if lwip is present in the build. This ensures that sys/socket.h
is available as long as lwip component is included into the build.
- lwip is now a public requirement of esp-tls since esp_tls.h includes
sys/socket.h header.
- lwip is now a public requirement o esp_http_client because
sys/socket.h is included from esp_http_client.h
- lwip is now a private requirement of esp_wifi for "smartconfig_ack"
- lwip is now a private requirement of mqtt for socket functions
- lwip is now a public requirement of tcp_transport because
esp_transport_tcp.h includes sys/socket.h header.
- mbedtls checks if lwip component is present in the build. If yes,
net_sockets.c is added to the build, along with the dependency on
lwip. Previously lwip was a public requirement of mbedtls
unconditionally.
system/g1_components test app is updated to reflect the changes
Default public dependencies of a component before and after this
change, except common requirements:
- esp_timer (public dependency of freertos)
- bootloader_support (public dependency of esp_hw_support)
- vfs (public dependency of lwip)
- esp_wifi (public dependency of lwip)
- esp_event (public dependency of esp_wifi)
- esp_netif (public dependency of esp_event)
- esp_eth (public dependency of esp_netif)
- esp_phy (public dependency of esp_wifi)
After:
- esp_timer (public dependency of freertos)
- bootloader_support (public dependency of esp_hw_support)
Altogether, the following components have been always added as
public requirements to all other components, and are not added now
([breaking-change]):
- lwip
- vfs
- esp_wifi
- esp_event
- esp_netif
- esp_eth
- esp_phy
Application components now need to explicitly declare dependencies on
these components.
This component property allows including all component object files
into the executable. It is equivalent to wrapping the component
library with -Wl,--whole-archive and -Wl,--no-whole-archive flags.
Closes https://github.com/espressif/esp-idf/issues/8667
When building for "linux" (~POSIX) target on macOS, the system linker
is normally used. MacOS linker doesn't recognise --gc-sections, but
has a -dead_strip flag which is equivalent.
Tools: Add "idf.py save-defconfig" command to generate sdkconfig.defaults based on current sdkconfig
Closes IDF-2970
See merge request espressif/esp-idf!16409
COMPONENT_DIRS and EXTRA_COMPONENT_DIRS should be defined as CMake
lists, using 'set' or 'list' commands. Some applications written
for earlier versions of ESP-IDF used to define these variables as
space separated strings.
For example, the following is correct:
set(EXTRA_COMPONENT_DIRS path/to/components path/to/more/components)
The following is not correct:
set(EXTRA_COMPONENT_DIRS "${EXTRA_COMPONENT_DIRS} component1")
set(EXTRA_COMPONENT_DIRS "${EXTRA_COMPONENT_DIRS} component2")
The string "component1 component2" may indicate a single directory
name with a space, or two directory names separated by space.
However due to the fact that such way of defining EXTRA_COMPONENT_DIRS
was supported in IDF 4.3 and earlier, we need to provide backward
compatibility for it.
This commit introduces a new script, split_paths_by_spaces.py, which
is invoked if EXTRA_COMPONENT_DIRS or COMPONENT_DIRS variable contains
spaces. The script tries to determine if each space should be
interpreted as a separator or as part of the directory name.
When this cannot be done unambiguously, the script reports an error.
In all cases when space separators are detected, the script reports
a warning, and prints instructions for fixing the CMakeLists.txt.
Breaking change in this commit: specifying non-existent directories
in COMPONENT_DIRS or EXTRA_COMPONENT_DIRS is no longer allowed.
New —-list-separator argument of confgen.py and
prepare_kconfig_files.py is used to select which character is used
as list separator. For compatibility with esp-docs, we still keep
support for space separator. Otherwise esp-docs would have to choose
the separator depending on the IDF version.
It can be used in component CMakeLists.txt files when adding "weak"
dependencies between component. A "weak" dependency from A to B is
similar to target_link_libraries(A PRIVATE B), but it gets added only
if B is included in the build.
Use it instead of specifying B as part of PRIV_REQUIRES when the
component can be built (even if with reduced functionality) without
component B being available.
These optional feature produces a graphviz file showing component
dependencies. It is useful for debugging reasons why certain
components got added to the build.
Defining CMake variables from the command-line or from another CMake project,
such as `-DCMAKE_C_FLAGS= -DCMAKE_CXX_FLAGS=`, caused a link failure as ESP
CMake was unable to set its proper compilation flags.
Additional CMake compiler flags can now be provided by another project.
* Closes https://github.com/espressif/esp-idf/issues/7507
This feature was added when we thought that target components might be
added out of IDF tree. That never became possible, and with recent
changes in IDF architecture it is unlikely that this feature will be
necessary any time soon. Remove it, simplifying the code.
This is an experimental feature intended at the moment for ESP-IDF
developers only.
If IDF_TOOLCHAIN=clang environment variable or CMake variable is set,
use toolchain-clang-esp32xx.cmake instead of toolchain-esp32xx.cmake.
These changes aren't sufficient to actually build any IDF project with
clang; subsequent commits add a few workarounds required to do this.
Toolchain files are added for esp32 and esp32s2, which are the targets
supported in our llvm-project fork at the moment.
Ivan Grokhotkov