GCC doesn't find relative includes when passed paths using backward-slashes

[Achim Gratz]

Alexander Grund via Cygwin writes:
> consider the following MWE:
>
> |$ touch bar/foo.h $ cat bar/main.cpp #include "foo.h" int main(){}
> |With this most simple setup calling GCC with `g++ "bar\main.cpp"`
> |results in GCC failing to find the include file. However using `g++
> |"bar/main.cpp"` works as expected. |

Giving any Cygwin tools non-POSIX path constructs is asking for trouble,
notwithstanding the fact that sometimes it works (or seems to work).

> |So the compiler does find the CPP file and also is able to resolve
> | others paths passed with backslashes (e.g. -I arguments) but
> | basically disables resolving includes relative to the file including
> | it. For context: This turned up on CI for Boost where
> | "|C:\cygwin64\bin" is added to the PATH env variable to be able to
> | use the Cygwin GCC with B2. The build system, finding it is running
> | on Windows, will pass paths with backward slashes to the
> | compiler.

Then use a build system that doesn't do this.

> | This happens on both CMD with the added PATH and using the
> | bash. For reference I tried the same with MinGW and there either
> | path separator worked. So it seems to be an issue in the Cygwin
> | builds of GCC.

No it isn't, just like you couldn't expect this to work on Linux.


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs