A project that compiles and uploads fine with v2 is failing to compile with v3.
lib/Display/src/Display.cpp: In constructor 'Display::Display(int8_t, int8_t, int8_t, int8_t)':
lib/Display/src/Display.cpp:35:17: error: 'INITR_144GREENTAB' was not declared in this scope
_tft->initR(INITR_144GREENTAB); // initialize a ST7735S chip, green tab
^
That symbol is declared in Adafruit_ST7735.h, that comes from a library in installed at the global package location:
I commented out the lib_extra_dirs, re-init and it still compiles correctly now.
Is there any reason the lib_deep_search is disabled by default? Or why the libs in the ~/.platformio/lib directory don’t take precedence over the ~/.platformio/package/ directory?
I don’t know what to do. I wrote this PlatformIO 3.0 Build System to be very smart. So… We have the problem with this “smart behaviour”. PlatformIO 2.0 has a big problem… It compiles each file and each library. It doesn’t understand about compatibility.
PlatformIO 3.0 has another behaviour. It has support for the different library manifests:
library.json - PlatformIO
library.properties - Arduino IDE
module.json ARM mbed
PlatformIO 3.0 Library Build System analyzes these files and manifests (if they present) and decides how to use it, to extend build environment with extra flags, includes etc. This is very cool! It works 2 times faster than PlatformIO 2.0 and allows to avoid a lot of problems and conflicts.
Nevertheless, this system could be broken when manifest contains incorrect data. This is your case. Adafruit GFX and ST7735 were compatible only with atmelavr development platform. So, the libraries were not used for compilation… ignored! I’ve just updated manifest for these libs:
The question: “What to do with other libs”? How to verify these manifests and update them? This feature is very cool and would good to keep it in PlatformIO 3.0. For example, you have 2 build environments for the project in platformio.ini. The environment is based on ESP8266 and another on Atmel AVR. However, some libs are compatible with ESP8266 and are not compatible with AVR. What is more, both these libs contain file some_header.h that you will include in your project. Of course, you want from PlatformIO for find automatically proper libs depending on the environment data. The current behaviour of PlatformIO 3.0 allows doing that. PlatformIO 2.0 - doesn’t allow.
Finally, PlatformIO 3.0 Build System understands #ifdef, macros and etc. It means, that if a library is under some macros, it will not be included to build process.
P.S: You can build your project now without problems. Just update libs mentioned above. Also, you need to add to dependency list this library
Thanks! I found a very cool solution. I’ve introduced today lib_compat_level option. It should resolve 99% further problems. Please upgrade to the new 3.0.0.dev10.
Please upgraded to dev12. Sorry, I’ve refactored Library Dependency Finder again Now, the lib_deep_search is turned ON by default. The new version has smart behaviour and understands nested dependencies and keeps order. Also, it prints Dependency Map.
If left “debug” code for testing. Could you provide me your value from console?
Looking for dependencies...
13 0.312541007996
Library Dependency Map
I have another library challenge for you Ivan … I can’t get this one to work. It’s a struggle trying to trace out the various include stacks, but ultimately I can’t get it to compile even on a bare project.
Cloned into my arduino folder, and soft-linked over to ~/.platformio/lib/TFT_ST7735/
Performed the pio init --ide clion --board teensy31.
The only two include lines are:
#include <Arduino.h>
#include <TFT_ST7735.h>
And that will cause many build errors like:
/Users/home/.platformio/lib/TFT_ST7735/_fonts/defaultFont.c:39:1: error: unknown type name '_smCharType'
const _smCharType image_data_defaultFont_0x20[1]
^
However that _smCharType is defined for my teensy cpu type (__MK20DX256__) over in _includes/TFT_ST7735_cpuCommons.h:44
#define _smCharType unsigned char`
It’s an odd arrangement of includes, and might susceptible to ordering problems? Might be exploring some edge cases of the library dependency finder logic??
In a related note, I saw Teensy Paul mention that today’s new release of Arduino IDE is using gcc for finding includes… Arduino 1.6.10 | Teensy Forum
… using “gcc -E”, which is unfortunately slower, but it is absolutely guaranteed to give the same preprocessing as gcc run in normal compile mode. I shudder to think what a mess 1.6.5 could have been if they’d used two different preprocessors to discover required library headers
This isn’t a problem of the builder. We introduced support for 2 different build systems and their manifests:
library.properties (Arduino IDE specific structure)
module.json (ARM mbed, yotta build system)
Of course, the main and recommended manifest is library.json. When Library Dependency Finder collects compatible libraries from different source storages, it tries to initialize most compatible library sub-builder for the library. See source code:
class ArduinoLibBuilder(LibBuilderBase)
class MbedLibBuilder(LibBuilderBase)
class PlatformIOLibBuilder(LibBuilderBase)
If a library contains library.json, then the PlatformIOLibBuilder will be used. There is a big difference between these builders. For example (your case), this is Arduino IDE based library. ArduinoLibBuilder has specific behavior… If library doesn’t contain src folder in the root, then need to build only source files that are located in the root. All other folders should be ignored. If lib contains src, then all files should be ignored and only src folder should be built.
The other big story with ARM mbed’s yotta… I’ll not describe it here.
What do we have? This library contains library.json manifest file but doesn’t explain PlatformIO Build System how to build this library. In this case, PlatformIO Library Builder will build ALL files (the default behavior). In this case, need to explain in manifest which files should be built. See my PR:
I’ve just removed debug code and fixed a few issues. Please update to the latest commit. It should work very well now.
That is not a secret that our build system is super fast and doesn’t have competitors. We have a lot of tests within our community. As result, we decided to write universal build system that will support different manifests from the other build systems.
If you will see any problems with library, try to remove library.json. In this case, PlatformIO will try to find better sub-builder for the library automatically.
Now, the 
it’s mapped to 
… I can’t get this one to work. It’s a struggle trying to trace out the various include stacks, but ultimately I can’t get it to compile even on a bare project.