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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
