PlatformIO Community

Cannot find libraries on which other libraries depend

I’m a fairly new user and struggling with a problem. Using PlatformIO in VS. I started working on a project with the STM32 B-L475E-IOT01A board, and trying to connect the sensors and the WiFi. A problem i ran into in all the different projects I started (started multiple to check where the error was), is that if I install a library using the PlatformIO library tab, it installs the libraries neatly in the pio./libdeps folder. Is this normal? The lib folder seems the more obvious choice.

The problem is when i run my code, errors occur due to the compiler not finding header files on which the header files in the #include in the main file depend.

This is when the libraries are placed in the aforementioned pio./libdeps folder or in the lib folder. A ‘fix’ that works is to place all the header files, so the ones from the #include and the ones that they depend on in separate maps, named after the specific header file in the lib folder. This works for a small project with not a lot of dependencies, but as i want to combine the wifi and multiple sensors it becomes a lot of work and a long process.

Is this a bug, am I incompetent or is there something else at play?

Thanks in advance for any help!

ps. Below some screenshots

image

image

Yes, the philosophy here is that the libraries declared via lib_deps in the platformio.ini file (which is where the libraries ultimately end up when you use the PlatofrmIO library registry GUI) are automatically managed libraries that don’t need to be really visible in lib/ and need not be pushed in the repo (.pio is automatically .gitignore-ed). Especially since lib_deps has generic version declarations (e.g. ~1.0.0) so the concrete library files can also change. lib/ is for user-provided library. But the storage spaces are basically equivalent.

From the dependency graph it shows that some libraries were not detected at all and other have maybe undetected dependencies. In such a case, 2 things apply:

  • increase the aggressiveness of the library dependency finder via lib_ldf_mode, e.g. lib_ldf_mode = chain+ in the platformio.ini.
  • place a #include <main_library_header.h> in the main source file of the project to make it easier for PlatformIO to see that you’re using a certain library.

If it still does not work, there might be a bug. In that case, please provide the platformio.ini and minimal code that reproduces the error.

Thank you for the elaborate reply! I tried both fixes you proposed, to no avail. It seems like that whenever a headerfile is directly within a library map (so for example libdeps->library_map->headerfile.h), but if there is a map within the map of the library the compiler cannot find the header file (so libdeps->library_map->library_submap->headerfile.h). Ive included my platformio.ini below.

[env:disco_l475vg_iot01a]
platform = ststm32
board = disco_l475vg_iot01a 
framework = mbed
lib_ldf_mode = chain+
lib_deps = 
    mbed-mqtt/MQTT@0.0.0+sha.9cff7b6bbd01
    mbed-st/HTS221@0.0.0+sha.ccf7f36492ae
    mbed-farnell24-iot-team/wifi-ism43362@0.0.0+sha.766454e296c3

Minimal code used:

#include "mbed.h"

#include "ISM43362Interface.h"

#include "TCPSocket.h"

#include "MQTTmbed.h"

#include "MQTTClient.h"

#include "HTS221Sensor.h"

You are right, the library.json contained in the downloaded libraries (which I think are auto-generated) are missing the build options to include their subdirectories as include folders. If those are auto-generated, it’s a bug in PlatformIO. I’ll open an issue for that to have it investigated.

In the meantime, the project does compile when you manually add the include paths to the build system via build_flags .

[env:disco_l475vg_iot01a]
platform = ststm32
board = disco_l475vg_iot01a 
framework = mbed
lib_ldf_mode = chain+
lib_deps = 
    mbed-mqtt/MQTT@0.0.0+sha.9cff7b6bbd01
    mbed-st/HTS221@0.0.0+sha.ccf7f36492ae
    mbed-farnell24-iot-team/wifi-ism43362@0.0.0+sha.766454e296c3
build_flags = 
    -D"wait_ms=ThisThread::sleep_for"
    -I"$PROJECT_LIBDEPS_DIR/$PIOENV/FP"
    -I"$PROJECT_LIBDEPS_DIR/$PIOENV/MQTT"
    -I"$PROJECT_LIBDEPS_DIR/$PIOENV/ST_INTERFACES/Actuators"
    -I"$PROJECT_LIBDEPS_DIR/$PIOENV/ST_INTERFACES/Common"
    -I"$PROJECT_LIBDEPS_DIR/$PIOENV/ST_INTERFACES/Communications"
    -I"$PROJECT_LIBDEPS_DIR/$PIOENV/ST_INTERFACES/Sensors"
    -I"$PROJECT_LIBDEPS_DIR/$PIOENV/wifi-ism43362/ISM43362"
    -I"$PROJECT_LIBDEPS_DIR/$PIOENV/wifi-ism43362/ISM43362/ATParser"
    -I"$PROJECT_LIBDEPS_DIR/$PIOENV/wifi-ism43362/ISM43362/ATParser/BufferedSpi"
    -I"$PROJECT_LIBDEPS_DIR/$PIOENV/wifi-ism43362/ISM43362/ATParser/BufferedSpi/Buffer"    
    -I"$PROJECT_LIBDEPS_DIR/$PIOENV/X_NUCLEO_COMMON/DbgMCU"
    -I"$PROJECT_LIBDEPS_DIR/$PIOENV/X_NUCLEO_COMMON/DevI2C"
    -I"$PROJECT_LIBDEPS_DIR/$PIOENV/X_NUCLEO_COMMON/DevSPI"

This makes use of two environment variables to make it nicely portable. Additionally it adds a macro definition to get older drivers compiling for mbed-os 6, since wait_ms(x) was removed and C++ code has to do ThisThread::sleep_for(x) now (issue). I’ve had this issue in e.g. ISM43362Interface.cpp.

I have no board to test if this actually works, just that it compiles. If you experience further issues you might want to downgrade to mbed-os 5.x as this is what these driver seem to require (or maybe they were already updated?)

Linking .pio\build\disco_l475vg_iot01a\firmware.elf
Checking size .pio\build\disco_l475vg_iot01a\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]   8.0% (used 10480 bytes from 131072 bytes)
Flash: [          ]   3.7% (used 38504 bytes from 1048576 bytes)
Building .pio\build\disco_l475vg_iot01a\firmware.bin
===================== [SUCCESS] Took 460.40 seconds ===================== 

Edit: Issue 3957 is opened for that.

Thank you so much for your time and effort! So if i run into this problem it is possible to fix this with the build_flags? That makes sense, as adding the paths to intellisense does nothing for platformio ofcourse.
Ill run this code and come back to you.

The code runs! at least for this part it does, now just debug the rest haha. Thank you again!