Lib problem revisited

Libraries
1

I write multi-board projects. I would probably fall asleep if there were no conditionals in my code… :slight_smile:

In one of my problem projects, I have PubSubClient and WiFiEsp and I am compiling for Wemos D1R2 and a Due with an ESP01S. The due compiles fine and the Wemos errors like crazy, trying to comple WiFiEsp.

In my src I have

#ifdef ESP_SERIAL
#include <WiFiEsp.h>
#include <WiFiEspClient.h>
#define WiFiClient WiFiEspClient
#else
#include <ESP8266WiFi.h>
#include <ESP8266mDNS.h>
#include <WiFiClientSecure.h>
#include <WiFiUdp.h>
#endif

My thoughts would be in the order of “Why is it compiling that library?”. I normally don’t include the “Arduino” lib dir, but I tried and it did the same thing. This seems to be the root of all my past library issues.

Shouldn’t the default behaviour be to only compile the needed library instead of all of them? It is an issue when they are technically incompatible as these examples are.

2

I run into this all the time as well. I have a “native” env that runs unit tests on the Mac so I don’t have to get any devices involved when it’s not device-dependent.

Sadly, PlatformIO attempts to rebuild all libs that are in .piolibdeps and some of them don’t make sense in “native” (and are NOT included in lib_deps for that environment). I have to rm -rf .piolibdeps and then my test code will compile after it re-downloads all the libs.

Maybe .piolibdeps needs to have a second layer directory structure like .piolibdeps/env-name/

3

yes, if they have a libs/common + libs/env-name it would be a perfectly manageable solution. It might be quicker"libs_add_dir = …" directive you could add in a specific env.

4

The solution for me turned out to be to add “lib_extra_dirs = libavr” to the env that actually needed the lib. I just created “libavr” dir off the main tree and put the offending lib in there.