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.
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.
These optional feature produces a graphviz file showing component
dependencies. It is useful for debugging reasons why certain
components got added to the build.
CMake sorts result of file(GLOB) command since version 3.6.0:
https://gitlab.kitware.com/cmake/cmake/-/commit/edcccde7d
Since ESP-IDF sets cmake_minimum_required version to 3.5, and version
3.5.1 is used in CI, sort file lists obtained from file(GLOB)
manually.
This helps obtain reproducible order of libraries passed to the linker
and to ldgen.
* 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
* Target components pull in xtensa component directly
* Use CPU HAL where applicable
* Remove unnecessary xtensa headers
* Compilation changes necessary to support non-xtensa gcc types (ie int32_t/uint32_t is no
longer signed/unsigned int).
Changes come from internal branch commit a6723fc
... to reduce the number of simultaneously open files at link time.
When plugin support is enabled in the linker, BFD's (and the
corresponding file handles) are cached for the plugin to use. This
results in quite a large number of simultaneously open files, which
hits the default limit on macOS (256 files).
Since we aren't using LTO now, disable it explicitly when invoking the
linker.
Closes IDF-923
Closes IDFGH-1764
Closes https://github.com/espressif/esp-idf/issues/3989
Ref. https://github.com/espressif/esp-idf/issues/1684
This change allows RTTI to be enabled in menuconfig. For full RTTI
support, libstdc++.a in the toolchain should be built without
-fno-rtti, as it is done now.
Generally if libstdc++.a is built with RTTI, applications which do not
use RTTI (and build with -fno-rtti) could still include typeinfo
structures referenced from STL classes’ vtables. This change works
around this, by moving all typeinfo structures from libstdc++.a into
a non-loadable section, placed into a non-existent memory region
starting at address 0. This can be done because when the application
is compiled with -fno-rtti, typeinfo structures are not used at run
time. This way, typeinfo structures do not contribute to the
application binary size.
If the application is build with RTTI support, typeinfo structures are
linked into the application .rodata section as usual.
Note that this commit does not actually enable RTTI support.
The respective Kconfig option is hidden, and will be made visible when
the toolchain is updated.
This commit makes it so that BUILD_COMPONENT holds only the component,
and a new property BUILD_COMPONENT_ALIASES hold the full name of the
component.
This also removes erroneous check for duplicate components, as this can
never happen:
(1) if two components have the same name but different prefixes,
the internal names are still unique between them
(2)if two components happen to have the same name and same prefix, the
latter would override the former
Previous implementation only builds list of components included in the
build during component registration.
Since the build components is known as the requirements expansion is
ongoing, update the list here instead.
Use imported library, which does not create additional rules, but still
allows attaching arbitraty properties instead of custom targets. This
allows the targets to not appear in the target list of IDEs such as
CLion.
How idf_build_component and the COMPONENTS argument to idf_build_process
interact is not clear/misleading. Clarify their interaction in the docs.
Closes: https://github.com/espressif/esp-idf/issues/3630
!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
!4452 simplified early expansion by using an early expansion script that
only does one thing: get the public and private requirements for each
component, albeit one by one. This was also dependent on parsing
the command output of the expansion script. This commit makes it so that a list of all
components to be processed to passed to the expansion script, generating a cmake
file that sets each component requirements in one go.
This also makes sure that only components that registered themselves get
included in the final build list.
