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
Previously ldgen determines the output file name on its own. This commit
makes it so that user can dictate what the output file name will be
for the processed template, if the user needs it for something else.
!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.
!4452 had config generation first before building the component list
to be used in the build. This proved to be detrimental when a new target
is added as config generation would consider configs from both targets.
Removes the need to know/guess the paths to these libraries. Once we are gcc 8 only, we
can remove -nostdlib and no additional arguments are needed for system libraries.
The catch is: any time IDF overrides a symbol in the toolchain sysroot, we need
an undefined linker marker to make sure this symbol is seen by linker.
Adds --tags and --dirty flags to cmake git_describe() calls, and not
pass the HEAD commit hash (incompatible with --dirty)
Makes IDF_VER output the same as in Make build system
Thanks to @william-ferguson-au for reporting this:
https://github.com/espressif/esp-idf/issues/3378#event-2355460974
This MR removes the common dependency from every IDF components to the SOC component.
Currently, in the ``idf_functions.cmake`` script, we include the header path of SOC component by default for all components.
But for better code organization (or maybe also benifits to the compiling speed), we may remove the dependency to SOC components for most components except the driver and kernel related components.
In CMAKE, we have two kinds of header visibilities (set by include path visibility):
(Assume component A --(depends on)--> B, B is the current component)
1. public (``COMPONENT_ADD_INCLUDEDIRS``): means this path is visible to other depending components (A) (visible to A and B)
2. private (``COMPONENT_PRIV_INCLUDEDIRS``): means this path is only visible to source files inside the component (visible to B only)
and we have two kinds of depending ways:
(Assume component A --(depends on)--> B --(depends on)--> C, B is the current component)
1. public (```COMPONENT_REQUIRES```): means B can access to public include path of C. All other components rely on you (A) will also be available for the public headers. (visible to A, B)
2. private (``COMPONENT_PRIV_REQUIRES``): means B can access to public include path of C, but don't propagate this relation to other components (A). (visible to B)
1. remove the common requirement in ``idf_functions.cmake``, this makes the SOC components invisible to all other components by default.
2. if a component (for example, DRIVER) really needs the dependency to SOC, add a private dependency to SOC for it.
3. some other components that don't really depends on the SOC may still meet some errors saying "can't find header soc/...", this is because it's depended component (DRIVER) incorrectly include the header of SOC in its public headers. Moving all this kind of #include into source files, or private headers
4. Fix the include requirements for some file which miss sufficient #include directives. (Previously they include some headers by the long long long header include link)
This is a breaking change. Previous code may depends on the long include chain.
You may need to include the following headers for some files after this commit:
- soc/soc.h
- soc/soc_memory_layout.h
- driver/gpio.h
- esp_sleep.h
The major broken include chain includes:
1. esp_system.h no longer includes esp_sleep.h. The latter includes driver/gpio.h and driver/touch_pad.h.
2. ets_sys.h no longer includes soc/soc.h
3. freertos/portmacro.h no longer includes soc/soc_memory_layout.h
some peripheral headers no longer includes their hw related headers, e.g. rom/gpio.h no longer includes soc/gpio_pins.h and soc/gpio_reg.h
BREAKING CHANGE
Works around bug where components/soc/CMakeLists.txt was testing "EXISTS
${COMPONENT_PATH}/${SOC_NAME}" and this test could pass during early
expansion if COMPONENT_PATH was empty and a directory /esp32 exists
on Windows.
Closes https://github.com/espressif/esp-idf/issues/3195
A problem if the Python interpreter used for idf.py (or set via PYTHON
variable) didn't match
"/usr/bin/env python" (or the associated executable for .py files, on
Windows).
Closes https://github.com/espressif/esp-idf/issues/3160
Possibly also fix for https://github.com/espressif/esp-idf/issues/2936
Adds build system test to catch any future direct execution of Python in
the standard build process.
Previously, this compiler flag was not being applied
regardless of CONFIG_SPIRAM_CACHE_WORKAROUND setting.
Explanation: add_compile_options() only applies to
source files added after the function is run, or in
subdirectories added after the function is run. In
this case, no new source files were being added after
this function was run.
When IDF_PATH is not set by the user, cmake infers the same through
other means and sets it as an environment variable. However, some
sub-invocation of cmake may not see this variable as it is not set
in the parent. This change adds a custom command for exporting IDF_PATH
just before invoking ldgen so that IDF_PATH can be used in Kconfig
without any errors.
Added a new structure esp_app_desc_t. It has info about firmware:
version, secure_version, project_name, time/date build and IDF version.
Added the ability to add a custom structure with a description of the firmware.
The esp_app_desc_t is located in fixed place in start of ROM secotor. It is located after structures esp_image_header_t and esp_image_segment_header_t.
app_version is filed from PROJECT_VER variable (if set in custom make file) or PROJECT_PATH/version.txt or git repo (git describe).
Add API to get app_desc from partition.
Previous version assumed having winpty on the Path meant that it would be needed,
but some tools (like Atlassian Sourcetree) permanently add winpty to the path.
Symptom is arrow keys not working in menuconfig dialog.
