Same Codebase but "No such file or directory"

m4xxx · January 11, 2021, 10:39am

Hi,

I am working on a project here:

Long story short: I tried to add a .h and .cpp file for a new device (just for a new display) with ifdef LILYGO_WATCH_2020_V1. So i added a build flag -D LILYGO_WATCH_2020_V1=1 in platformio.ini

Is this kind of integration right? Am i supposed to do it that way with platformio?
Maybe thats my problem…

I compiled it serveral times so i got it working for the TTGO smartwatch (see commits history). Today i tried to build it and its not working anymore:

I tried to delete .pio or libdeps. Seems like it doest re-download the needed libraries while building… now i have project copys with the same codebase but some compile and others not…

I had this error several times before and i have no clue where it come from…

Anyone an idea?

maxgerhardt · January 11, 2021, 3:29pm

Where is the modified version of the repo? The project builds fine for my end. Without seeinig the exact code and platformio.ini additions it’s hard to help.

m4xxx · January 11, 2021, 4:08pm

Well thats the problem… this repo / branch is my current codebase. I asked my colleague and my branch builds fine for him too. (seems like the codebase is ok…)

I deleted the hole local git project and cloned it -> same errors

As i mentioned before, i got these errors while coding and testing… now i can’t get rid of them

Could it be that platformio have some issues with clean project management or caching?

maxgerhardt · January 11, 2021, 4:14pm

Remove the .pio folder and retry compiling.

m4xxx · January 11, 2021, 4:24pm

Same errors…

.pio\libdeps\ttgo-t-watch\TTGO TWatch Library\src\libraries\GxEPD\src../…/U8g2_for_Adafruit_GFX/src/…/…/TFT_eSPI/Fonts/GFXFF/GFXFF.h:22:76: fatal error: …/…/…/Adafruit-GFX-Library/Fonts/FreeMonoBoldOblique12pt7b.h: No such file or directory

btw. these files aren’t missing

maxgerhardt · January 11, 2021, 4:40pm

Aha, you’re not working on the master branch. I’ve checked out your branch now too.

And now I get the sametype of warnings but not the type of warnings you get, but the firmware still builds.

My dependency graph is

Dependency Graph
|-- <TTGO TWatch Library> 1.4.1
|   |-- <Wire> 1.0.1
|   |-- <ESP32 BLE Arduino> 1.0.1
|   |-- <SPI> 1.0
|   |-- <Ticker> 1.1
|   |-- <SPIFFS> 1.0
|   |   |-- <FS> 1.0
|   |-- <FS> 1.0
|   |-- <SD(esp32)> 1.0.5
|   |   |-- <FS> 1.0
|   |   |-- <SPI> 1.0
|-- <WifiManager> 2.0.3-alpha+sha.321034b
|   |-- <DNSServer> 1.1.0
|   |   |-- <WiFi> 1.0
|   |-- <ESPmDNS> 1.0
|   |   |-- <WiFi> 1.0
|   |-- <WebServer> 1.0
|   |   |-- <WiFi> 1.0
|   |   |-- <FS> 1.0
|   |-- <WiFi> 1.0
|-- <ArduinoJson> 6.17.2
|-- <Sqlite3Esp32> 2.3.0
|-- <Ticker> 1.1
|-- <ESP32 BLE Arduino> 1.0.1
|-- <SPI> 1.0
|-- <Wire> 1.0.1
|-- <SPIFFS> 1.0
|   |-- <FS> 1.0
|-- <HTTPClient> 1.2
|   |-- <WiFi> 1.0
|   |-- <WiFiClientSecure> 1.0
|   |   |-- <WiFi> 1.0

Which is identical to the one you’ve posted above. Also the ESP32 platform version and packages match.

Nethertheless, the warning should be eliminated. Looking at the commad line, the macro -DARDUINO_T-Watch might be causing it since it has a - in it. But still, it builds. Edit: Yes the - is a forbidden character in a macro name. Fix proposed in Fix invalid ARDUINO_x macro name for ttgo watch board by maxgerhardt · Pull Request #468 · platformio/platform-espressif32 · GitHub.

A problem I do see however that paths are getting very long. And since Windows has a limit of the path length since it’s from the stoneage, that might be a problem. Does it help when you move the project root folder to a shorter, path, e.g. C:\project? Or alternatively, can you enable long paths?

m4xxx · January 11, 2021, 6:36pm

I enabled long paths, but that wasnt enough. I moved the project folder to C: and BOOM!
Now everything compiles correctly, thank you so much!

Yeah, thats the problem for the warnings… seems to be mentioned in issues but not merged or fixed yet.
Thumbs up, I hope they merge the fix someday.

maxgerhardt · January 11, 2021, 6:39pm

Such things may need a reboot. But great that it works now

Since I opened it 2h ago it’ll take some time but such a minor fix should be accepted pretty soon… can potentially also be done in the platformio.ini with some build_unflags = -DARDUINO_T-Watch and build_flags = -DARDUINO_TWatch directives, or fixing the board JSON file locally. But as said, it’s a minor thing.