Setting up the Python Interpreter ĮSP-IDF works well with Python version 3.8+. When adding custom non-build steps like 'flash' to the IDE, it is recommended to execute idf.py for these 'special' commands.įor more detailed information about integrating ESP-IDF with CMake into an IDE, see Build System Metadata. IDEs with CMake integration often provide their own build tools (CMake calls these 'generators') to build the source files as part of the IDE. The IDE will want to know the path to the project's CMakeLists.txt file. You can also use an IDE with CMake integration. Providing variables at the end of the command line is make syntax, and works for make on all platforms. For example, the idf.py build command is the same as running these commands in a bash shell (or similar commands for Windows Command Prompt): When idf.py does something, it prints each command that it runs for easy reference.

However, you can also invoke CMake directly if you prefer.

Idf.py is a wrapper around CMake for convenience. You can read more about configuring the build system using idf.py here. It manages the following tools:ĬMake, which configures the project to be built The idf.py command-line tool provides a front-end for easily managing your project builds. The toolchain should be installed in the system command line PATH. The toolchain for compilation is not part of the project. This allows the ESP-IDF framework to be decoupled from your project.

Instead, it is standalone, and linked to the project via the IDF_PATH environment variable which holds the path of the esp-idf directory. A full list of supported targets in your version of ESP-IDF can be seen by running idf.py -list-targets. 'Target' is the hardware for which an application is built. Some are provided by ESP-IDF itself, others may be sourced from other places. 'components' are modular pieces of standalone code that are compiled into static libraries (.a files) and linked to an app. A single project will usually build two apps - a 'project app' (the main executable, ie your custom firmware) and a 'bootloader app' (the initial bootloader program which launches the project app). A single project contains exactly one project configuration.Īn 'app' is an executable that is built by ESP-IDF. This configuration file is modified via idf.py menuconfig to customize the configuration of the project. 'Project configuration' is held in a single file called sdkconfig in the root directory of the project. Concepts Ī 'project' is a directory that contains all the files and configuration to build a single 'app' (executable), as well as additional supporting elements such as a partition table, data/filesystem partitions, and a bootloader. After the components in the project are configured, the build system will compile the project. It then allows the user to configure the ESP-IDF project using a text-based menu system to customize each component. To do that, when a project is compiled, the build system will look up all the components in the ESP-IDF directories, the project directories and (optionally) in additional custom component directories. The ESP-IDF base libraries (libc, ROM bindings, etc)ĮSP-IDF makes these components explicit and configurable. For example, for a web server that shows the current humidity, there could be: Overview Īn ESP-IDF project can be seen as an amalgamation of a number of components. Read this document if you want to know how to organize and build a new ESP-IDF project or component. This document explains the implementation of the ESP-IDF build system and the concept of 'components'.

Current Consumption Measurement of Modules.

Using Prebuilt Libraries with Components.

Using ESP-IDF Components from External Libraries.

Using Third-Party CMake Projects with Components.

Fully Overriding the Component Build Process.

Wrappers to Redefine or Extend Existing Functions.Requirements in the Build System Implementation.Overriding Default Build Specifications.

Cmake install directory root