Should be equivalent to what the docs say with idf_component_register(SRCS "main.c").
I’ve noticed you’re using CLion. Since it also uses CMake it might be confused and attempt to compile the sources on its own instead of correctly calling into PlatformIO.
Does the project compile with pio run in the console?
Do you have the PlatformIO CLion Plugin installed or are you using it without it? The selected target in the upper right corner is selectable as “PlatformIO Build”? And you only build it with the Build button, not with the Play button? Maybe project re-init helps (pio init --ide=clion in the project folder)?
Thanks for your reply! pio run also doesn’t work unfortunately. I do have the official Pio plugin installed. I am clicking the Build button to the left of the run configuration. Interestingly, I do not have a “PlatformIO Build” run config, only “PlatformIO Debug” or “PlatformIO Upload”.
How is it possible that this has 33 lines? The docs say a minimal CMakeList.txt at the root of the project with
# The following lines of boilerplate have to be in your project's CMakeLists
# in this exact order for cmake to work correctly
cmake_minimum_required(VERSION 3.16.0)
include($ENV{IDF_PATH}/tools/cmake/project.cmake)
project(project-name)
The CLion project file generator will of course generate its own CMakeLists.txt which instruct CLion to call into PlatformIO, but PlatformIO for ESP-IDF also needs a CMakeLists.txt with the ESP-IDF configuration code. So if you do pio init --ide=clion you overwrite that… Not sure how a ESP-IDF CMakeLists.txt plus PIO Wrapper CMakeLists.txt should work together.
Can you try replace the root-level CMakeListst.txt with the code given above (from the docs) and retry with just pio run?
$ pio run
Processing esp32doit-devkit-v1 (platform: espressif32; board: esp32doit-devkit-v1; framework: espidf)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32doit-devkit-v1.html
PLATFORM: Espressif 32 1.12.0 > DOIT ESP32 DEVKIT V1
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:
- framework-espidf 3.40000.200303 (4.0.0)
- tool-cmake 3.16.4
- tool-esptoolpy 1.20600.0 (2.6.0)
- tool-ninja 1.9.0
- toolchain-esp32ulp 1.22851.190618 (2.28.51)
- toolchain-xtensa32 2.80200.200226 (8.2.0)
Reading CMake configuration...
-- Project is not inside a git repository, or git repository has no commits; will not use 'git describe' to determine PROJECT_VER.
-- Project version: 1
-- Building ESP-IDF components for target esp32
-- Checking Python dependencies...
Python requirements from /Users/joris/.platformio/packages/framework-espidf/requirements.txt are satisfied.
-- Configuring incomplete, errors occurred!
See also "/Users/joris/Projects/test2/.pio/build/esp32doit-devkit-v1/CMakeFiles/CMakeOutput.log".
See also "/Users/joris/Projects/test2/.pio/build/esp32doit-devkit-v1/CMakeFiles/CMakeError.log".
fatal: not a git repository (or any of the parent directories): .git
/usr/local/Cellar/platformio/4.3.1/libexec/lib/python3.8/site-packages/pkg_resources/py2_warn.py:22: UserWarning: Setuptools will stop working on Python 2
************************************************************
You are running Setuptools on Python 2, which is no longer
supported and
>>> SETUPTOOLS WILL STOP WORKING <<<
in a subsequent release (no sooner than 2020-04-20).
Please ensure you are installing
Setuptools using pip 9.x or later or pin to `setuptools<45`
in your environment.
If you have done those things and are still encountering
this message, please comment in
https://github.com/pypa/setuptools/issues/1458
about the steps that led to this unsupported combination.
************************************************************
sys.version_info < (3,) and warnings.warn(pre + "*" * 60 + msg + "*" * 60)
CMake Error at /Users/joris/.platformio/packages/framework-espidf/components/esp32/project_include.cmake:11 (message):
Internal error, toolchain has not been set correctly by project (or an
invalid CMakeCache.txt file has been generated somehow)
Call Stack (most recent call first):
/Users/joris/.platformio/packages/framework-espidf/tools/cmake/build.cmake:305 (include)
/Users/joris/.platformio/packages/framework-espidf/tools/cmake/build.cmake:458 (__build_process_project_includes)
/Users/joris/.platformio/packages/framework-espidf/tools/cmake/project.cmake:337 (idf_build_process)
CMakeLists.txt:6 (project)
========================== [FAILED] Took 2.06 seconds ==========================
Here is the contents of the CMakeError.log that gets mentioned as well. It doesn’t seem very error-y, but it may be enough to screw up my build somehow.
Checking whether the ASM compiler is GNU using "--version" did not match "(GNU assembler)|(GCC)|(Free Software Foundation)":
Apple clang version 11.0.3 (clang-1103.0.32.29)
Target: x86_64-apple-darwin19.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
I’ve seen Python 3.8 causing errors and Python 3.7 not, but I’m not sure whether that’s the underlying problem here.
It’s still the system compiler though. In CLion → Options can you add a new toolchain where cmake and make is standard, but C++ and C compiler are pointing to /Users/joris/.platformio/packages/toolchain-xtensa32/bin/xtensa-esp32-elf-g++ and xtensa-esp32-elf-gcc respectively and put it in the top position? Though the CLion configuration shoudn’t really affect the PlatformIO execution if pio is executed from the commandilne… So maybe it is the cache file.
It builds! Using pio run, but it builds! And I immediately shot myself in the foot by running pio init --ide clion and attempting to build from CLion, because that now gives the first error again “Couldn’t find the main target of the project!”
But not being able to use the CLion plugin seems to kind of defeat the purpose of it.
Huh. I added include($ENV{IDF_PATH}/tools/cmake/project.cmake) to the PlatformIO generated CMakeLists.txt, just above the project() line and it is actually trying to do something useful now:
"/Users/joris/Library/Application Support/JetBrains/Toolbox/apps/CLion/ch-0/201.6668.126/CLion.app/Contents/bin/cmake/mac/bin/cmake" -DCMAKE_BUILD_TYPE=esp32doit-devkit-v1 -G "CodeBlocks - Unix Makefiles" /Users/joris/Projects/test2
-- Found Git: /usr/local/bin/git (found version "2.26.0")
-- IDF_TARGET not set, using default target: esp32
-- The ASM compiler identification is Clang
-- Found assembler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Project is not inside a git repository, or git repository has no commits; will not use 'git describe' to determine PROJECT_VER.
-- Building ESP-IDF components for target esp32
-- Checking Python dependencies...
The following Python requirements are not satisfied:
click>=5.0
pyparsing>=2.0.3,<2.4.0
pyelftools>=0.22
gdbgui>=0.13.2.0
pygdbmi<=0.9.0.2
Please follow the instructions found in the "Set up the tools" section of ESP-IDF Getting Started Guide
CMake Error at /Users/joris/esp/esp-idf/tools/cmake/build.cmake:271 (message):
Some Python dependencies must be installed. Check above message for
details.
Call Stack (most recent call first):
/Users/joris/esp/esp-idf/tools/cmake/build.cmake:397 (__build_check_python)
/Users/joris/esp/esp-idf/tools/cmake/project.cmake:395 (idf_build_process)
CMakeLists.txt:14 (project)
-- Configuring incomplete, errors occurred!
See also "/Users/joris/Projects/test2/cmake-build-esp32doit-devkit-v1/CMakeFiles/CMakeOutput.log".
See also "/Users/joris/Projects/test2/cmake-build-esp32doit-devkit-v1/CMakeFiles/CMakeError.log".
[Finished]
Somehow it can’t see the installed python libraries, it seems.
Maybe it uses a different Python3 runtime. Pretty sure the PlatformIO one is a virtualenv (so that it doesn’t modify system python packages). Not sure if that’s the right way though.
@valeros, this is an interesting usecase. With CLion as a cmake-based IDE, how can PlatformIO + CLion still be used in e.g. ESP-IDF v4 projects which also use a CMakeLists.txt, which collides with the template that PIO creates when doing pio init --ide=clion? Seems we have a paradox here.
Hi @Hertog_Jan ! Starting with version 4.0, ESP-IDF uses a build system based on CMake. In order to provide more seamless integration we also switched to CMake as the source of build configuration. Unfortunately, there is a conflict between CMakeLists.txt used by ESP-IDF and CMakeLists.txt which we generate for CLion. At the moment we’re working on better integration with CLion without this intermediate “hacky” CMakeLists.txt, but there is no ETA for this feature.
In a nutshell, I’d recommend you to rollback to the previous version of the espressif32 platform, e.g.:
It’s been almost a year, and I can appreciate that you and your team have your priorities, and CLion/ESP-IDF compatibility may not be one of them. But I would like to make a plea for getting PlatformIO’s CMake system to work nicely with ESP-IDF’s CMake system a higher priority:
I use a wroom 32, which supports WiFi out of the gate. Many of the aspects of the WiFi are configured using sdkconfig in ESP-IDF, including buffers - which dramatically impact the speed at which WiFi operates. The defaults are set in such a conservative manner as to not use much memory, at the expense of any reasonable speed (28.8k modem download speeds).
It is my understanding that the esp32-arduino project uses pre-compiled libraries, which would require re-compiling separately from PlatformIO using my own version of sdkconfig just so that I can use my board’s built-in features. In other words, I would basically need to fork my own copy of esp32-arduino and maintain it for the remainder of my project.
Alternatively, I could either abandon CLion altogether and use an IDE that I am not comfortable with using, just to build the project, or I can use an outdated version of ESP-IDF. I have tried VSCode, and I personally find it painful to use in comparison to CLion. While I could imagine that might not be the most compelling argument to sway your decision one way or the other, it would require having to set up a whole new environment, and relearn an entire new workflow, all of which take an inordinate amount of time and effort. I challenge you to try using a different IDE for your every day work to see what I mean. I would also prefer to not have to use an older version of the framework, and miss out on possibly important bug fixes and features that are in the v4.0 branch. I think this argument speaks for itself without my further justifying it.
TL;DR, Please reconsider your team’s stance on the importance of using CLion with the espidf (v4.0) framework. We shouldn’t be forced to choose between our IDE and/or using an older version of ESP-IDF just so we can take advantage of our board’s built-in features.
For anyone stuck on this in Jan 2022, the PlatformIO CLI works with the latest ESP-IDF but the CLion plugin does not. You can still use CLion as your IDE without the plugin. You just have to run your builds using pio run. When the plugin eventually works, you can switch your CLion project over to it. In the meantime, I suggest disabling it entirely.
If you want the nice “click-able” build buttons that the plugin tries to provide, you can create Shell Script configurations that simply run the pio cli. The cli command to build is pio run and the command to build and upload is pio run -t upload.
EDIT: The above solution works but results in none of the advantages typically wanted from an IDE. For example, CLion isn’t able to introspect the project at all. My new recommended solution is to completely abandon CLion. The VSCode extension is top notch and while it’s a bit of a pain to learn a new IDE, it’s worth it to get proper code inspection. Maybe I’ll switch back to CLion if the plugin ever gets fixed.
