ESP32 Forum

Hi, I have been using the IDF framework / toolchain for a while now and I was wondering if there was a supported way or if anyone explored developing without the full toolchain.

I guess I am not sure which, if any, part of the toolchain could be circumvented. Ideally I would like to not use MSYS2 and develop with my preferred build system and not Make. I would also like to selectively compile what I need from the IDF framework into a static library so it will never need to be recompiled and does not need as much bloat.

Some of the current scripts are awesome, like make flash, make monitor, make menuconfig. I would like to incorporate that into my own development environment but without Make.

I guess an additional question is, is using MSYS2 a must? And if not, does anyone have any pointers into creating their own development environment? I would prefer to stay on the command line and not use Eclipse too.

Thanks!

Hi jpan27,

If MSYS2 is the main sticking point then you might want to take a look at the CMake-based build system (currently in preview release) which doesn't require MSYS2:
https://esp32.com/viewtopic.php?f=13&t=5559&p=24109

jpan127 wrote:selectively compile what I need from the IDF framework into a static library

It's theoretically possible to build IDF into static libraries (arduino-esp32 does this, for example). We don't currently have a supported way to do this with the current build system, but it's something we'd like to support in the future (probably as part of the CMake-based build system).

jpan127 wrote:it will never need to be recompiled and does not need as much bloat.

A couple of things to note:

- Even though a lot of files are compiled as part of an IDF build, only referenced symbols (ie functions and variables which are called from your project) are linked into the final binary. So if you don't use it, it can't "bloat" the final binary (it's as if it wasn't there at all, apart from the compile time overhead).

- If you don't change the configuration then you should only need to compile IDF source files once per project. Note that when IDF is pre-built into static libraries then it's not possible to change the configuration at all, for the same reason. After the first build of a project, "make" will only compile the source files which have changed (unless you "make clean").

We know that building on Windows can be painfully slow. Part of the goal for the CMake-based build system is to address this (faster building under Windows, and some improved logic about when to make incremental builds).

Hi Angus,

Thanks for the reply!

This is definitely in the direction I was hoping for. MSYS2 is one of the main reasons why I want to move away, but ultimately what I want is a minimal platform for me to use my own environment. I have a preferred build system, SCons, and would like to build up my own development pipeline rather than use (all) the provided scripts / tools.

If I was able to use my own build system I can definitely make it work with static libraries. I realize that Make / CMake / etc have their own method of tracking file changes and most of the time the files won't change so recompilation is not necessary. However, it is still a simpler option when the build directory is cleaned or switching back and forth between computers and recompilation is required. Also debatably easier to check in a static lib than a submodule for esp-idf. This is not a big deal, however, should be a simple change in whatever build script.

I guess my ideal goal is to know what is the bare minimum that is necessary to link into a flashable executable, where to get the compiler (xtensa?) directly, and then I can probably pick and choose which of your useful scripts to add to my pipeline.

Maybe this will help?

http://esp-idf.readthedocs.io/en/latest ... ratch.html

It is a link to the documentation page on ESP-IDF which discusses how to build the Xtensa toolchain from source that is used to compile source files to build an ESP32 executable.

Thanks Kolban!

I took a look at the typical make output with make -n and saw how the xtensa-esp32-elf-gcc is used.
It also shows how esptool.py is used to flash the program and the bootloader.

I think from this I can figure out how everything is done and it doesn't seem as complex / obfuscated as I originally thought.