include with absolute unix path not found on MinGW MINGW*

[firewave]

a.h

int h;

a.cpp

#include "/s/GitHub/simplecpp-fw/a.h"

int i;

$  ./simplecpp -l a.cpp
1:
2:
3: int i ;
a.cpp:1: missing header: Header not found: "/s/GitHub/simplecpp-fw/a.h"

$ ls -l /s/GitHub/simplecpp-fw/a.h
-rw-r--r-- 1 User None 6 Oct 13 21:25 /s/GitHub/simplecpp-fw/a.h

It works with a Windows path:

$  ./simplecpp -l a.cpp

#line 1 "s:/GitHub/simplecpp-fw/a.h"
1: int h ;
#line 3 "a.cpp"
3: int i ;

[firewave]

On Cygwin and MinGW MSYS it works with both.

I already tried switching to the stat code but that didn't help.

[glankk]

The MSYS2 MINGW* environments are meant for building native Windows applications, not Cygwin or MSYS applications. I think we should draw a line and treat them as such, meaning that whenever we see _WIN32 (which we do for MINGW32/64, not for MSYS that instead targets MSYS/Cygwin and defines unix), that means we support only windows paths. There's no more reason to support unix paths on MINGW* than there is on MSVC. They're native windows applications that happen to be built within in MSYS2 environment.

[firewave]

If you are using MSYS2 (i.e. the msys shell) on Windows the paths are Unix ones by default. And the application built in MSYS2 might also be run within regular Windows which would be using Windows paths.

With WSL it is the other way around. You can run regular Windows applications within the wsl shell using Unix paths (but I think there is some internal conversion going on - I have not looked into it yet).

I also looked into Cygwin but I cannot remember what its current state is.

I need to adjust the CI to test this properly as currently I am doing it manually.

[glankk]

The MSYS2 shell uses unix paths, but that is only possible with native windows programs (including those compiled with mingw-w64) because these are translated to windows paths when passed to windows programs, as shown in this example:

~ $ pwd
/home/glank

~ $ cmd //c "echo pwd: " $(pwd)
pwd:  C:/msys64/home/glank

Notice how the /c switch to cmd has to be typed as //c to prevent the shell from translating it to C:/. The point is I think this is actually unrelated to how paths should be handled when targeting windows, regardless of our choice of compiler or shell.