mirror of
https://github.com/espressif/esp-idf.git
synced 2025-09-30 19:19:21 +00:00
docs: Update translation for ESP-IDF docs for syncronization
This commit is contained in:
@@ -144,6 +144,7 @@ To manage the Python version more generally via the command line, check out the
|
||||
|
||||
.. _example-project-structure:
|
||||
|
||||
|
||||
Example Project
|
||||
===============
|
||||
|
||||
@@ -174,7 +175,7 @@ This example "myProject" contains the following elements:
|
||||
|
||||
- A top-level project CMakeLists.txt file. This is the primary file which CMake uses to learn how to build the project; and may set project-wide CMake variables. It includes the file :idf_file:`/tools/cmake/project.cmake` which implements the rest of the build system. Finally, it sets the project name and defines the project.
|
||||
|
||||
- "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.
|
||||
- "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.
|
||||
|
||||
- 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.
|
||||
|
||||
@@ -296,7 +297,9 @@ Multiple Components with the Same Name
|
||||
|
||||
When ESP-IDF is collecting all the components to compile, it will do this in the order specified by ``COMPONENT_DIRS``; by default, this means ESP-IDF's internal components first (``IDF_PATH/components``), then any components in directories specified in ``EXTRA_COMPONENT_DIRS``, and finally the project's components (``PROJECT_DIR/components``). If two or more of these directories contain component sub-directories with the same name, the component in the last place searched is used. This allows, for example, overriding ESP-IDF components with a modified version by copying that component from the ESP-IDF components directory to the project components directory and then modifying it there. If used in this way, the ESP-IDF directory itself can remain untouched.
|
||||
|
||||
.. note:: If a component is overridden in an existing project by moving it to a new location, the project will not automatically see the new component path. Run ``idf.py reconfigure`` (or delete the project build folder) and then build again.
|
||||
.. note::
|
||||
|
||||
If a component is overridden in an existing project by moving it to a new location, the project will not automatically see the new component path. Run ``idf.py reconfigure`` (or delete the project build folder) and then build again.
|
||||
|
||||
|
||||
.. _cmake_minimal_component_cmakelists:
|
||||
@@ -443,11 +446,13 @@ When Writing a Component
|
||||
|
||||
If a component only supports some target chips (values of ``IDF_TARGET``) then it can specify ``REQUIRED_IDF_TARGETS`` in the ``idf_component_register`` call to express these requirements. In this case, the build system will generate an error if the component is included in the build, but does not support the selected target.
|
||||
|
||||
.. note:: In CMake terms, ``REQUIRES`` & ``PRIV_REQUIRES`` are approximate wrappers around the CMake functions ``target_link_libraries(... PUBLIC ...)`` and ``target_link_libraries(... PRIVATE ...)``.
|
||||
.. note::
|
||||
|
||||
In CMake terms, ``REQUIRES`` & ``PRIV_REQUIRES`` are approximate wrappers around the CMake functions ``target_link_libraries(... PUBLIC ...)`` and ``target_link_libraries(... PRIVATE ...)``.
|
||||
|
||||
|
||||
.. _example component requirements:
|
||||
|
||||
|
||||
Example of Component Requirements
|
||||
---------------------------------
|
||||
|
||||
@@ -753,7 +758,7 @@ It is also possible to conditionally replace the bootloader depending on a certa
|
||||
|
||||
project(main)
|
||||
|
||||
It is important to note that this can also be used for any other bootloader components than `main`. In all cases, the prefix `bootloader_component` must not be specified.
|
||||
It is important to note that this can also be used for any other bootloader components than ``main``. In all cases, the prefix ``bootloader_component`` must not be specified.
|
||||
|
||||
See :example:`custom_bootloader/bootloader_override` for an example of overriding the default bootloader.
|
||||
|
||||
@@ -796,6 +801,7 @@ Browse the :idf_file:`/tools/cmake/project.cmake` file and supporting functions
|
||||
|
||||
.. _component_cmakelists_example:
|
||||
|
||||
|
||||
Example Component CMakeLists
|
||||
============================
|
||||
|
||||
|
@@ -90,6 +90,7 @@ The following optimizations improve the execution of nearly all code, including
|
||||
|
||||
Reduce Logging Overhead
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Although standard output is buffered, it is possible for an application to be limited by the rate at which it can print data to log output once buffers are full. This is particularly relevant for startup time if a lot of output is logged, but such problem can happen at other times as well. There are multiple ways to solve this problem:
|
||||
|
||||
.. list::
|
||||
|
Reference in New Issue
Block a user