0

我正在尝试使Windows 上的CLion达到可以像标准 CMake 项目一样打开/使用esp_idf项目的状态。我知道这是可能的，因为我在 Linux 上也有类似的设置。我将列出我是如何在 Linux 上工作的，以及我在尝试将相同的想法移植到 Windows 时遇到的问题。

在 Linux 上

通过从已经由本质上初始化的 shell 的上下文启动 CLion get_idf，可能会导致 CLion 继承 idf 的 CMake 文件所需的环境变量。因此，让它在 Linux 上运行就像执行脚本一样简单：

#!/bin/bash
. $HOME/esp/esp-idf/export.sh
cd ~/clion-2020.2.3/bin
./clion.sh

现在，可以在 CLion 中将 idf 项目作为普通 CMake 项目打开/编译。

在 Windows 上

但是，在 Windows 上，如果应用类似的想法，结果将不起作用。CLion 仍然继承调用进程 env-vars，但这并不能达到预期的效果。剧本：

@echo off

cd "C:\Users\someuser\esp-idf\"
call "C:\Users\someuser\.espressif\idf_cmd_init.bat"
"C:\Program Files\JetBrains\CLion 2021.1.1\bin\clion64.exe"

所有相关的环境变量都是继承的（没有全部显示，因为有很多）：

clion 继承的环境变量

然而，尽管 idf 嵌入的 python 是系统/路径或其他环境变量中唯一存在的 python 实例，它仍然抱怨遗留 python 解释器或无法找到要求：

clion cmake 配置打印输出

更令人困惑的是，idf 环境完全可以从 CLion 中的集成终端运行：

从 CLion 终端运行的 idf.py 构建

有谁知道这种差异的技术原因是什么，我该如何解决？

为什么不直接使用 PlatformIO？

在我看来，PlatformIO 使得利用 esp_idf 的某些功能过于复杂。此外，我也无法让它在 Windows 上与 CLion 一起使用。最后，我希望至少可以选择在 Windows 上使用普通的 idf 和 CLion。

4

0 回答 0