Hi everybody.
I have this problem that verification or upload always fails with Compilation error: src\Adafruit-GFX-Library\Adafruit_GFX.h: No such file or directory
"/Users/wyrdlg/Desktop/EarthListener4v0_final/EarthListener4v0_final.ino:19:10: fatal error: src\Adafruit-GFX-Library\Adafruit_GFX.h: No such file or directory
#include "src\Adafruit-GFX-Library\Adafruit_GFX.h" // Core graphics library by Adafruit
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
exit status 1
Compilation error: src\Adafruit-GFX-Library\Adafruit_GFX.h: No such file or directory"

My setup:
The machine: Mac M1 with IDE 2.0.3
The Board / System: Arduino 2560 https://whadda.com/product/earth-listener-wmmi211/
The Code is from GitHub - Velleman/VM211_Firmware
In IDE the board is set to Mega or Mega 2560 with port /dev/cu.usbmodem21401

Files that are not in /src have no problem. The Files themselves lie in the same folder /src in the sketch. Spelling is ok.

Tried an older IDE. Reinstall IDE. Delete and begin from start. Does not help.

Hi @wyrdlg . The reason this only works on Windows is because the \ path separator was used in this #include directive at line 19 of the EarthListener4v0_final.ino sketch file:

#include "src\Adafruit-GFX-Library\Adafruit_GFX.h" // Core graphics library by Adafruit
Windows supports this character as a path separator, but macOS and Linux do not. So you can make the code work for any operating system by replacing the path separators in that #include directive with the universal /:
#include "src/Adafruit-GFX-Library/Adafruit_GFX.h" // Core graphics library by Adafruit
Windows supports / as a path separator in addition to \, so this will not break compatibility with Windows.
 ptillisch:
Windows supports / as a path separator in addition to \, so this will not break compatibility with Windows.
Not sure how this is handled in more recent versions of windows like 7/8/11

But in the older versions of NT based OSes (NT, Vista, and earlier all the way back to maybe even Windows 98)  , the separator was configurable but defaulted to backward slash and only one could be active at time.
The problem is that backward slash in C is used for character escaping.

The gcc tool ports Windows had all kinds of crazy stuff added in the character escape processing and include file name processing to deal with goofy Windows path names that might have backwards slashes in them.

(I think this should never have been done)

It also would change the normal slash to backward slashes  for paths in included filenames to deal with Windows. This part was necessary to work with Windows and eliminates any need to support backward slashes in paths.
i.e. (at least in older Windows OSs) it wasn't Widows that was supporting using slash in path-names but rather the gcc tools that attempted to convert slashes to backward slashes on Windows and would treat backwards slashes in paths as a normal character (leave them in there) verses treat the backwards slash as and escape character.

It was a very UGLY hack just for windows.

IMO, supporting backward slashes in the paths of include filenames never should have been supported.

Supporting backward slashes in included filenames never was and is still not needed.
Another issue that can cause things to work on Windows but not on other OSes is misspelled filenames.

i.e. Windows by default is case insensitive for filenames.

(There used to be an option to be able to fix windows to support case sensitivity so it would work like the other OSs)

If the filename is mispelled by inversion of case of characters,

i.e. 'E' instead of 'e' then it will still work on Windows but not on other OSes.
--- bill
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2022-12-22  10:30 PM                addins
d-----        2022-12-24   8:51 PM                appcompat
PS C:\> Get-ChildItem -Path C:/Windows
    Directory: C:\Windows
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2022-12-22  10:30 PM                addins
d-----        2022-12-24   8:51 PM                appcompat
[...]
https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#canonicalize-separators
All forward slashes (/ ) are converted into the standard Windows separator, the back slash (\ ).