PlatformIO fails to resolve all SensESP dependencies about sensesp

[ivankravets]

Sorry, this is our bug and has been fixed in platformio/platformio-core#3658

We will release 5.0.1 tomorrow.

A temporary solurion is to switch to dev-version via pio upgrade --dev

[ba58smith]

@wefleenor - please search your hard drive for a filed called Adafruit_Sensor.h. When I do that, I find it in a LOT of places. But I can't think of any reason it should work on the boat, but not at home. BTW, be careful with all of your research into this: there is a BME280 sensor, and a BMP280 sensor, and SensESP works with both, and has file names for both.

[ba58smith]

Notice that it's down in the directory structure of each of my PlatformIO Projects, and also in /.platformio/lib/.... I'm guessing yours should be, too.

[wefleenor]

<!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} code {mso-style-priority:99; font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} -->Thanks, Brian, I do find them in each project 1 layer down in the /d1_mini folder.  I didn’t look for it because I wasn’t using that sensor and it didn’t make sense to me that it would be needed.  This would seem to be an issue with how the software functions.  Is there a way to manually include the path or is it necessary to copy the files up 1 level? Bill*****************************************William E Fleenor, Ph.D. (retired)Civil & Environmental EngineeringUniversity of California - Davis2001 Engineering IIIOne Shields AvenueDavis, CA [email protected] [phone]Center for Watershed Sciences, UC Davishttps://watershed.ucdavis.edu/people/faculty***********************************  From: Brian SmithSent: Monday, September 7, 2020 11:48 AMTo: SignalK/SensESPCc: wefleenor; MentionSubject: Re: [SignalK/SensESP] build errors (#154) Notice that it's down in the directory structure of each of my PlatformIO Projects, and also in /.platformio/lib/.... I'm guessing yours should be, too.—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe. 

[BjarneBitscrambler]

Hi Bill: It's a workaround, but here's how I managed to get builds to complete when I was faced with similar issues. After locating the *.h file the compiler is complaining about, put its directory into the compiler's search path using the following flag:

build_flags =
   -I/full/path/to/file/.platformio/packages/framework-arduinoespressif32/libraries/ESPmDNS/src

The build_flags = setting goes into your project's platformio.ini file, located anywhere inside the block corresponding to your target board. In your case it sounds like you are using a d1_mini, so put it below the [env:d1_mini] tag.

In my case it seemed that PlatformIO was having trouble with its library management. I observed multiple installs of the same library, wrong libraries, wrong versions, etc over a week-long period...it was tough on my hair. My compile errors eventually disappeared, after multiple times of uninstalling and reinstalling PIO, deleting the .pio folder within the project, and trying other solutions mentioned on the web. I'm still not sure why it finally fixed itself, but in the meantime, hopefully the above will get you going.

One interesting related behaviour I noticed about PIO that still persists is that its Library Manager seems to need a restart of PIO before it recognizes changes to a project's libraries. I can reproduce the problem on my setup by creating a new PIO project, and then browsing PIO Home->Libraries->Installed. In that tab, the new project is not listed until after I quit and restart PIO.

[ba58smith]

After updating Python2 and Python3 on my computer today, I also started getting the error first reported in this Issue. I don't know how those updates could have had anything to do with it, but that is all I did (unless I unwittingly did something else during the Python updating - that was not a simple process).

UPDATE: The reason I updated Python was that PlatformIO wouldn't start the build process without doing a PIO Core update, which was failing because my Python versions were too old. As soon as I updated Python, then PIO updated its Core, and THAT'S what broke the library thing. See below.

I started by just adding the library with the missing .h file (Adafruit_Sensor.h) to library.json. That resolved that compiler error, but gave me another very similar one - also about an Adafruit .h file. So I added THAT library to library.json, which resolved that error, and gave another, and another. I eventually added all of these to library.json:
Adafruit Unified Sensor
Adafruit BusIO
Adafruit Sensor Calibration
Adafruit FXAS21002C
Adafruit FXOS8700

I know that PIO is supposed to be smart enough to pull in any library that's required, but it doesn't seem to be doing that. @mairas, is it a bad idea to add these libraries to library.json? Does it make the firmware bigger than it needs to be?

I believe that all of these libraries are new to SensESP with PR #145 , adding the Magnetometer sensor. Could there be a problem with the way some libraries were included in those new files? Maybe all of the missing .h files should just be added to that one new sensor's .h file?

There was one missing .h file that the above approach didn't resolve: EEPROM.h - because I didn't find an Adafruit EEPROM library. (The EEPROM.h that it was complaining about was being called from an Adafruit header, which is why I wanted to find an Adafruit library that included it.) I ended up doing what Ivan Kravets, creator of PlatformIO, said to do in this forum answer: add #include <EEPROM.h> to main.cpp. It worked. https://community.platformio.org/t/eeprom-h-no-such-file-or-directory/626

[mairas]

I started by just adding the library with the missing .h file (Adafruit_Sensor.h) to library.json. That resolved that compiler error, but gave me another very similar one - also about an Adafruit .h file. So I added THAT library to library.json, which resolved that error, and gave another, and another. I eventually added all of these to library.json:
Adafruit Unified Sensor
Adafruit BusIO
Adafruit Sensor Calibration
Adafruit FXAS21002C
Adafruit FXOS8700

I know that PIO is supposed to be smart enough to pull in any library that's required, but it doesn't seem to be doing that. @mairas, is it a bad idea to add these libraries to library.json? Does it make the firmware bigger than it needs to be?

Ideally it'd be better to let PIO resolve the dependencies but if it can't do that, it's not too harmful if they're added. It's just that if any of those explicit dependencies turn out to be unneeded, it'll be unnecessarily downloaded and built. I don't think they'd be linked in the binary if they're not used, so the firmware size shouldn't be affected.

Anyway, I wanted to see what these build problems were all about and pulled the latest commits and deleted the .pio directory just for kicks and BAM, everything went haywire. For some reason PIO doesn't seem to be downloading the dependencies. This needs some investigation...

[mairas]

PlatformIO 5.0.0 was released on 2020-09-03 and got automatically updated at least for me. I bet it introduced some incompatibility. I'll dig into the issue properly tomorrow.

[mairas]

This sounds similar to our issue: https://community.platformio.org/t/dependencies-from-private-lib-disappear-after-upgrading-to-core-5-0-0/15720

[mairas]

OK, tried downgrading platformio:

.platformio/penv/bin/pip install platformio==4.3.4

A new build successfully uses pio 4.3.4 but results in the same failure. So it doesn't seem to be due to PIO 5.0.0.

[doubledutch2]

I had some issues installing PIO on my a new machine yesterday and the guys from Platform IO provided brilliant support to get it resolved (don't let Time Machine try to move VSC / PIO basically as it breaks all sorts of stuff).

I've pointed them into the direction of this issue so maybe they can provide some guidance.

[ivankravets]

Please file an issue at https://github.com/platformio/platformio-core and provide a simple project to reproduce this issue.

See https://docs.platformio.org/en/latest/core/history.html

Automatically enable LDF dependency chain+ mode (evaluates C/C++ Preprocessor conditional syntax) for Arduino library when “library.property” has “depends” field (issue #3607)

It was a bug in whole PIO Core 4.

[ba58smith]

Thank you, @ivankravets !!!

[ba58smith]

UPDATE: Version 5.0.1 of PIO doesn't seem to fix the problem - maybe for a few people, but not everyone (me included). Currently, the "fix" seems to be to include several more Adafruit libraries in the SensESP library.json, (PR # 161), which solves all but one compiler error: "Can't find <EEPROM.h>". That can be worked around by adding #include <EEPROM.h> in your main.cpp.

[BjarneBitscrambler]

Just a note that another workaround for the missing EEPROM library (and any other libraries that fail to get automatically loaded) is to list them in platformio.ini under lib_deps =. This might be preferred over the option of changing source code.

[GaryWSmith]

I recently installed vscode and pio for the first time and immediately began having issues with dependencies.
I'm on the latest version of pio - 5.0.1. Ubuntu 18.04
The problem is very inconsistent but I've never managed to get a clean build first time round using the library - https://github.com/SignalK/SensESP.git

The workaround for me also has been to add additional dependencies to lib_deps such as ESP Async Webserver and others as required.

[mairas]

This issue seems to be an aggregate of multiple individual bugs. There’s a temporary fix in place, provided by PR#170 and SensESP has been verified to build just fine. The remaining SensESP and PIO issues are tracked in #168 and platformio/platformio-core#3668, respectively. Closing.