Help using CLion + CMake + ESP-IDF v4.0+

[MindReader32]

Hi,

Now that the ESP-IDF is moving away from Make to Ninja (and Clion doesn't support Ninja) do any of the ESP engineers (who have said that they use Clion*) have any tips to get this to work with IDF v4.x+ please?

I bumbled into this GitHub just ("Ninja support for CLion IDE (working with newer versions of clion)" https://gist.github.com/arichardson/3de ... edd2e0fe63

But no luck getting that to work either.

I have been able to get Clion + Cmake + IDFv4 working with the Make variant, I could launch almost any of the IDF CMake API macros from the CLion 'Run Configurations' menu, i.e. I was able to build my project bin using 'gen_project_binary'.

However, trying to launch the 'monitor' failed, it was unable to find a 'project_settings.json' file in the build folder.

I launch CLion from a shell script that sets all the Environment vars, to reduce the amount of CLion settings/duplications.

As much as I like Clion, I'd be really keen to hear what the internal ESP developers use and find to be 'the best'/'most popular'.

Thanks

*https://esp32.com/viewtopic.php?f=13&t=11280

[MindReader32]

Ok, progress...

What didn't help... I had 2 Clion toolchain targets, one being the 'default' and a custom one called 'ESPNinjaWrapper' for the ninja wrap script mentioned above.

The 'ESPNinjaWrapper' one was writing into 'build-wrapper' which the IDF CMake wasn't using (as it defaults to 'build').
However, what I didn't realise was the the other 'default' toolchain was being run (even thought it was not reference from the CMAke config) and creating artefacts (built with Xcode) in 'build' which explains why idf.py got so upset down the line.

It's working better now. In short, just edit the CLion 'default' toolchain and only have 1.

[permal]

You can have CMake generate a build system for either make or Ninja; just don't specify "-G Ninja" on the command line and it defaults to regular make files (at least on Linux).

I'm using both in parallel, Ninja when I run my CI, and the make file CodeBlocks-variant that CLion uses. I compile my code for both ESP and Linux under CLion and command line, its working like a charm now now that I've sorted out all the kinks. https://github.com/PerMalmberg/Smooth

[MindReader32]

Thats' true, and that's what I am doing in my IDF 3.x projects, but as the IDF CMake Makefile support is deprecated in IDF 4.x I wanted to make the jump to Ninja based builds now.

[permal]

There is no such thing as "CMake make file". CMake is a build system generator, not a build system. It generates whatever build system you tell it to. Make files, Ninja, Visual Studio solution...

Unless you absolutely want CLion to use Ninja during compilation, just let it do its thing based on the CMake-files.

[MindReader32]

I do realise that, to be clear then, what I meant by "IDF CMake Makefile support" being deprecated refers to this:

Since ESP-IDF V4.0, the default build system is based on CMake. This documentation is for the legacy build system based on GNU Make. Support for this build system may be removed in future major releases.

from: https://docs.espressif.com/projects/esp ... egacy.html

My mistake.

[MindReader32]

My question to the ESP devs is why does the 'build_system' 'idf_as_lib' example explicitly specify Ninja?

Code: Select all

cmake .. -DCMAKE_TOOLCHAIN_FILE=$IDF_PATH/tools/cmake/toolchain-esp32.cmake -DTARGET=esp32 -GNinja

Just a developer's personal preference? or is there something in 4.0beta (and/or beyond) that would/will require it?

[permal]

My question to the ESP devs is why does the 'build_system' 'idf_as_lib' example explicitly specify Ninja?

I too pointed that out to them a while back. The answer I got was that Ninja is faster. So yes, just a preference.

Btw, don't go down the route using IDF as a library, I've been down that rabbit hole already, it breaks as soon as IDF is >1 step from your main app, e.g. App - Library - IDF. Also the way Espressif has implemented their "component" system causes no end of issues when you want to use regular CMake conventions, such as multiple add_executable() and add_library(). When building against IDF, strictly follow the "component"-concept they have added on top of CMake or you'll loose the ability to run "menuconfig" etc without manual intervention.

[MindReader32]

Thanks for the tip, so I best not go down that route for my other question: https://esp32.com/viewtopic.php?f=13&t=12656
All the best.