forked from espressif/esp-idf
docs: Add information to build system about IDF Component Manager
This commit is contained in:
@@ -154,6 +154,7 @@ An example project directory tree might look like this::
|
||||
- myProject/
|
||||
- CMakeLists.txt
|
||||
- sdkconfig
|
||||
- dependencies.lock
|
||||
- bootloader_components/ - boot_component/ - CMakeLists.txt
|
||||
- Kconfig
|
||||
- src1.c
|
||||
@@ -164,10 +165,14 @@ An example project directory tree might look like this::
|
||||
- Kconfig
|
||||
- src1.c
|
||||
- include/ - component2.h
|
||||
- managed_components/ - namespace__component-name/ - CMakelists.txt
|
||||
- src1.c
|
||||
- idf_component.yml
|
||||
- include/ - src1.h
|
||||
- main/ - CMakeLists.txt
|
||||
- src1.c
|
||||
- src2.c
|
||||
|
||||
- idf_component.yml
|
||||
- build/
|
||||
|
||||
This example "myProject" contains the following elements:
|
||||
@@ -176,6 +181,10 @@ This example "myProject" contains the following elements:
|
||||
|
||||
- "sdkconfig" project configuration file. This file is created/updated when ``idf.py menuconfig`` runs, and holds the configuration for all of the components in the project (including ESP-IDF itself). The ``sdkconfig`` file may or may not be added to the source control system of the project.
|
||||
|
||||
- "dependencies.lock" file contains the list of all managed components, and their versions, that are currently in used in the project. The ``dependencies.lock`` file is generated/updated automatically when IDF Component Manager is used to add or update project components. So this file should never be edited manually! If the project does not have ``idf_component.yml`` files in any of its components, ``dependencies.lock`` will not be created.
|
||||
|
||||
- Optional "idf_component.yml" file contains metadata about the component and its dependencies. It is used by the IDF Component Manager to download and resolve these dependencies. More information about this file can be found in the `idf_component.yml <https://docs.espressif.com/projects/idf-component-manager/en/latest/reference/manifest_file.html>`_ section.
|
||||
|
||||
- Optional "bootloader_components" directory contains components that need to be compiled and linked inside the bootloader project. A project does not have to contain custom bootloader components of this kind, but it can be useful in case the bootloader needs to be modified to embed new features.
|
||||
|
||||
- Optional "components" directory contains components that are part of the project. A project does not have to contain custom components of this kind, but it can be useful for structuring reusable code or including third-party components that aren't part of ESP-IDF. Alternatively, ``EXTRA_COMPONENT_DIRS`` can be set in the top-level CMakeLists.txt to look for components in other places.
|
||||
@@ -184,6 +193,8 @@ This example "myProject" contains the following elements:
|
||||
|
||||
- "build" directory is where the build output is created. This directory is created by ``idf.py`` if it doesn't already exist. CMake configures the project and generates interim build files in this directory. Then, after the main build process is run, this directory will also contain interim object files and libraries as well as final binary output files. This directory is usually not added to source control or distributed with the project source code.
|
||||
|
||||
- "managed_components" directory is created by the IDF Component Manager to store components managed by this tool. Each managed component typically includes a ``idf_component.yml`` manifest file defining the component's metadata, such as version and dependencies. However, for components sourced from Git repositories, the manifest file is optional. Users should avoid manually modifying the contents of the "managed_components" directory. If alterations are needed, the component can be copied to the ``components`` directory. The "managed_components" directory is usually not versioned in Git and not distributed with the project source code.
|
||||
|
||||
Component directories each contain a component ``CMakeLists.txt`` file. This file contains variable definitions to control the build process of the component, and its integration into the overall project. See `Component CMakeLists Files`_ for more details.
|
||||
|
||||
Each component may also include a ``Kconfig`` file defining the `component configuration`_ options that can be set via ``menuconfig``. Some components may also include ``Kconfig.projbuild`` and ``project_include.cmake`` files, which are special files for `overriding parts of the project`_.
|
||||
@@ -338,6 +349,7 @@ The following component-specific variables are available for use inside componen
|
||||
- ``COMPONENT_NAME``: Name of the component. Same as the name of the component directory.
|
||||
- ``COMPONENT_ALIAS``: Alias of the library created internally by the build system for the component.
|
||||
- ``COMPONENT_LIB``: Name of the library created internally by the build system for the component.
|
||||
- ``COMPONENT_VERSION``: Component version specified by idf_component.yml and set by IDF Component Manager.
|
||||
|
||||
The following variables are set at the project level, but available for use in component CMakeLists:
|
||||
|
||||
@@ -1548,6 +1560,10 @@ Enumeration
|
||||
|
||||
- Retrieve each component's public and private requirements. A child process is created which executes each component's CMakeLists.txt in script mode. The values of ``idf_component_register`` REQUIRES and PRIV_REQUIRES argument is returned to the parent build process. This is called early expansion. The variable ``CMAKE_BUILD_EARLY_EXPANSION`` is defined during this step.
|
||||
- Recursively include components based on public and private requirements.
|
||||
- Unless IDF Component Manager is disabled, it is called to resolve the dependencies of the components:
|
||||
- Looks for manifests and dependencies contained in the project.
|
||||
- Starts the version solving process to resolve the dependencies of the components.
|
||||
- When the version solving process succeeds, the IDF Component Manager downloads dependencies, integrates them into the build, and creates a ``dependencies.lock`` file that contains a list of the exact versions of the dependencies installed by the IDF Component Manager.
|
||||
|
||||
|
||||
Processing
|
||||
|
Reference in New Issue
Block a user