IR support ESP32 blocked by design or doing something wrong?

[martinus]

Have been running IR support on ESP32 for quite a while, so consider it stable.
But now i'm trying to compile my custom setup with PlatformIO instead of Arduino IDE

Took a while to figure out why it did not compile, until i discovered that the IR library has been blocked by design?
This file:

Code: Select all

platformio_esp32_envs.ini

Contains:

Code: Select all

[esp32_common]
lib_ignore = ....,IRremoteESP8266,...

When i remove that one, compiles ok.

Wonder why it's ignored for ESP32, because despite the name, it supports ESP32 as well

[Ath]

Most likely cause: The library wasn't compatible before, so was excluded. Now that's obviously been resolved, the library can be included again.

[TD-er]

There is now a separated IR PlatformIO environment for "custom" builds.
Both for ESP8266 as well as ESP32.

I split these as I was running into several build issues with PlatformIO in Windows.

The first one is related to the max. length of a command line in Windows (32768 bytes) which we exceed when linking it.
All .cpp files are first compiled into an object file, which is handed over to the linker on the command line.
Since the IR library does have a lot of .cpp files, you would run into lots of environments no longer being able to build.
Also these files add to the build time which was becoming a problem on Travis.

I recently added a hack to generate a temp .cpp file and adding the directories from where I took the .cpp to create the large temp.cpp file to the directory ignore list.
This is shown in the build log (in colors).
The sole purpose of this is to overcome this linker issue of PlatformIO on Windows.
I can do the same with the IR lib, but that doesn't reduce the build time (it will even increase it as the file is always considered 'touched' and thus recompiled)

Therefore I created 2 extra PIO envs for custom IR builds.

Another problem which also needed to add libraries to the lib_ignore list for some environments is related to the way VS code does handle its internal memory for all extensions.
VS code is nothing more then a web app in a Chromium wrapper. So it uses its own JavaScript sandbox.
This one has only 4 GB or RAM allocated. So regardless of the amount of memory in your PC (mine has enough), you would run out of memory if intellisense was trying to keep up with the code changes while coding.
When excluding some libraries, this reduced the number of "VS code extension handler crashes" from a few times per hour to near zero.
Now VS code does have some fixes for this (after my report, they extended the max. limit....) so that also may have helped.

[martinus]

Thanks for the explanations.

I've tweaked the Plaformio*.ini files to show only the three build types that i need:

Code: Select all

custom_ESP8266_4M1M
custom_ESP8266_1M
custom_ESP32_4M316k

And finally all three compile with PlatformIO successfully.

Most of the time was spend on updating my custom plugins, because a lot of things have changed under the hood of ESPEasy. Mainly moving most *.ino files to CPP/h so had to include lots of header files.

But the dirty work is done, time to try it out in production!

[TD-er]

The move into .h/.cpp was also due to link/build issues as .ino files are really causing build issues with such large projects as ESPEasy has become.

By the way, you can also add the favorite envs to your "default" one and then they will all be built if you run "pio run" without specifying an env.