Eclipse should work with MinGW directly. However I also use wxWidgets and building is easiest with Cygwin/MinGW or MSYS/MinGW, I choose the latter. I wasn't aware that Eclipse was able to deal with Cygwin paths, this is a similar issue and should be solvable. I will do some prodding ;-)
As a temporary solution I will 'regexp' the paths in the build output. Thanks for your response, Peter. On 5/9/07, Brandon Van Every <[EMAIL PROTECTED]> wrote:
On 5/8/07, Peter Visser <[EMAIL PROTECTED]> wrote: > > Hello, > > I'm using eclipse with mingw/msys. Eclipse scans the build output for > auto discovery of include paths and defines, which is very useful for auto > completion. I upgraded from CMake 2.4.3 to CMake 2.4.6 and this breaks > the auto discovery from eclipse. The reason for this is that CMake 2.4.3and CMake > 2.4.6 resolve paths in a different way for MSYS. > > CMake 2.4.3: > c:/proj/dir1 > > CMake 2.4.6 : > /c/proj/dir1 > > The approach in CMake 2.4.6 makes more sense in context of MSYS, however > it breaks the auto discovery for eclipse. Is there a way to change this > behaviour? Or is it possible to dump all include paths to a file and do a > STRING(REPLACE ...) or something a like ? > > Any suggestion is appreciated. Since the 2.4.6 design is correct with respect to MSYS, I think you should talk to the Eclipse people about changing their auto-discovery, or give them a patch to change it. I can't see chasing around 2 support cases and toggling between them, that's a recipe for very brittle software. Do you have to use MSYS? Will Eclipse work with straight MinGW? Then I presume you'll get the C:/ paths it's oriented towards. What happens with Cygwin? Their convention is /cygdrive/c/, so I presume the Eclipse people have faced and conquered this sort of path issue before. Last I looked, MinGW support wasn't as good as Cygwin support. Once upon a time, I couldn't have Cygwin and MinGW on the same system because the auto-discovery messed that up. So, they need prodding on MinGW issues, and it would be great if you'd prod them. Cheers, Brandon Van Every _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
