ESP32-C3 学习测试到今天，一直在使用 ESP-IDF 的框架，但是还从来没有注意过工程结构，遇到复杂一点的项目，工程结构就显得太乱了，本文就来了解下 ESP-IDF 工程结构。

前言

除了蓝牙篇的测试，关于 ESP32-C3 的使用我们都已经做了一个小型的物联网应用了：

ESP32-C3 入门教程 应用 篇（实例一、通过 MQTT 协议连接 ONENET 平台）

https://xie.infoq.cn/article/2e81ed59ed0d7178a345dad94

但是在实际操作时候，我们大多数情况下都是直接在 main.c 文件中添加应用代码，遇到复杂一点的项目多一点驱动文件，工程结构就显得很乱，不规范并且不方便移植。在上面 ESP32-C3 应用篇提到的工程中，我确实也遇到了文件添加的问题，所以为了避免这种基本问题的困扰，得好好的了解一下 ESP-IDF 工程结构。

本文的目的就在于通过 ESP-IDF 工程结构的认识，让我们可以自已可以规范的添加自己的工程代码。

本文是基于 VScode 插件的工程结构来说明（Ubuntu 环境），环境搭建见下面博文：

ESP32-C3 VScode 开发环境搭建（基于乐鑫官方 ESP-IDF——Windows 和 Ubuntu 双环境）

https://xie.infoq.cn/article/5b639e112cabba00cc1b8941a

一、ESP-IDF 工程基本框架

一个标准的工程框架如下图所示：

我们就用在应用篇中通过 MQTT 协议连接 ONENET 平台的工程来做示范说明，先来看看整体框架：

1.1 工程主目录下的文件

顶层 CMakeLists.txt

顶层项目 CMakeLists.txt 文件，这是 CMake 用于学习如何构建项目的主要文件，可以在这个文件中设置项目全局的 CMake 变量

这个文件一般来说我们需要修改的是工程名字。

顶层 Makefile

看上去内容和 CMakeLists.txt 中的差不多，实际上这个文件通过 CMake 构建时文件都可以不需要，我测试了一下把这个文件删除，也能正常编译，所以这个应该是老的构建方式 GUN Make 需要用到的。

现在版本的 IDF（4.3+）不需要这个文件，可以删除，不用修改。

sdkconfig

项目配置文件，执行 idf.py menuconfig 时会创建或更新此文件，文件中保存了项目中所有组件（包括 ESP-IDF 本身）的配置信息。 sdkconfig 文件可能会也可能不会被添加到项目的源码管理系统中。

我们需要的设置会在 menuconfig 中配置，此文件在执行完 menuconfig 后自动更新，不用修改。

1.2 main 目录下的文件

main 中的 CMakeLists.txt

给 CMake 指路的文件，，告诉它.c和.h文件的位置，在目录下面有几个.c文件，就得添加几个。

这个文件我们需要修改，工程中在 main 文件夹下面，我多放了几个.c 文件，就需要都添加进去。如果我们把头文件放在同一个文件夹里，也需要修改

比如：

component.mk

GUN Make 中使用的文件，通过 CMake 构建时文件都可以不需要，和上面的 顶层 Makefile 一样。

现在版本的 IDF（4.3+）不需要这个文件，可以删除，不用修改。

Kconfig.projbuild

这不是一个必须的文件，它的作用就是可以配合 menuconfig 进行配置，可以方便移植。

如果新手不太熟悉 Kconfig 的书写，这里暂时可以不关注，在示例工程中，一些用到的变量就自己写死，而不用宏定义。

有了要学会看懂，会使用 menuconfig 配置。熟悉了以后，可以尝试书写，方便项目移植。

app_main.c

这就是这个项目工程的 main 文件，代码放里面就行了。

需要说明的是，在上面示例中有自己的驱动代码：

我们规范的做法是放在 components 目录下面，作为组件形式存在，所以下面会把我们会把这几个文件移动到 components 目录下面。

入口函数文件，就是自己写应用的 main 函数文件。

1.3 components 目录下的文件

我们以前说过，components 包含了项目的部分自定义组件，但它有助于构建可复用的代码或者导入第三方（不属于 ESP-IDF）的组件。

再看看 components 文件夹下面的整体框架，在示例项目中，只有一个 button 子文件夹（就连 led_strip 的驱动文件我都直接放置 button 文件夹下面，因为当时放在另外一个文件夹编译出错= =！）：

component.mk

和上面的 component.mk 文件一样 GUN Make 中使用的文件，通过 CMake 构建时文件都可以不需要，所以这里不管。

component.mk 不需要。

Kconfig

和上面的 Kconfig.projbuild 一样。

学会看懂，尝试书写，方便项目移植。

组件中的 CMakeLists.txt

是 CMake 构建项目的主要文件，规则和 main 中 CMakeLists.txt 一样，这个文件是重点。

重点！！学会修改。理解下面说的组件依赖！

组件依赖

组件中的 CMakeLists.txt 的核心，我们必须要学会如何修改，才能完善自己的工程，所以对于组件依赖我们需要但是介绍，这里官方的讲解比较详细，借用官网介绍截图说明：

组件依赖示例：

VScode 下添加组件

在我们使用 VScode 插件中，可以通过指令快速添加组件，方法如下：

可以看到添加的标准组件架构。

在以后自己的工程中，尽量安装这个标准组件架构设计。

二、工程调整示例

通过上面的详细介绍，即便不知道构建原理，我们也对 ESP-IDF 工程结构有了一定的认识，学以致用，我们通过上面的认识，来对上面示例工程进行一定的修改。

2.1 删除不需要的文件

第一步，把上面说的component.mk 和 顶层Makefile删除, readme 也删除了，至少整体看上去，没有开始那么乱，然后编译正常：

2.2 组件调整

LED 驱动新建组件

LED 驱动其实在前面 RMT 应用 教学博文中使用过，不过当时是使用的官方例程为模板生成的组件，所以并没有关心结构，但是在我写应用篇的时候，把组件拷贝到本项目下面直接编译确实有错误，所以当时才会直接放置 button 文件夹下面 = =！

现在我们要把他移出来，单独作为一个组件led_strip，其实还是复制过来，如下图：

完成以后编译正常！

按键驱动放至对应组件

把主函数下面的按键驱动my_button.c和my_button.h文件放置 button 组件文件夹下面，去他该去的地方：

完成以后编译正常！

温湿度驱动新建组件

按照标准的组件模板，把温湿度的驱动程序放在新建的 sht21 组件文件夹中：

完成以后编译正常！

2.3 调整完成

完成上面步骤，对于示例的调整就算完成了，看看最后的工程结构（和以前比起来感觉漂亮多了，我都不忍心写任何注释上去~）：

结语

乐鑫官方为了减少样板文件，其实也封装了 CMake 的许多功能，目的在于给与用户方便。

本文的目的在于让我们能够基于 ESP-IDF 框架，完善自己的工程结构，并没有对 Cmake 的构建原理做说明。如果有不妥当，不到位的地方，还请指出！

在本博文之后，ESP32-C3 的教学实例，都会按照这个标准框架进行。

谢谢！