Community
Participate
Working Groups
Eclipse 3.1 with org.eclipse.cdt-3.0.0-RC3-win32.x86.zip I have moved some Eclipse CDT C++ projects from Linux to Windows (Cygwin). Trying to build those older Linux projects under Windows gives errors and warnings of the following kind: 1 Invalid project path: Include path not found (\usr\include). 1 Invalid project path: Include path not found (\usr\include\w32api). 1 Invalid project path: Include path not found (\usr\lib\gcc\i686-pc-cygwin\3.4.4\include). 1 Invalid project path: Include path not found (\usr\lib\gcc\i686-pc-cygwin\3.4.4\include\c++). 1 Invalid project path: Include path not found (\usr\lib\gcc\i686-pc-cygwin\3.4.4\include\c++\backward). 1 Invalid project path: Include path not found (\usr\lib\gcc\i686-pc-cygwin\3.4.4\include\c++\i686-pc-cygwin). 1 C/C++ Indexer Problem: Preprocessor Inclusion not found: iostream in file: C:\NEW\eclipse_workspace\Templates\Templates.cpp If I create a NEW project under Windows with Cygwin all works fine. It would be nice if projects could be transferred between Linux and Windows.
Looks like the include paths might be controlled by a configuration-level system macro "TargetOsList". After moving a project to Windows that macro still contains "solaris || linux || hpux || aix || qnx". I cannot change that system macro and adding "TargetOsList" as a User Macro for configuration and project with value "win32" did not work (no change in behaviour, user macro gone when restarting eclipse). Maybe it would be enough to give the user control over the "TargetOsList" macro to achieve project portability over different platforms?
Redirected to the build component
In the MBS design, Gnu on Windows (Cygwin) and Gnu on linux are considered different "tool-chain"s. MBS does support a project with different configurations that use different tool-chains. You can have release & debug configurations for Gnu on Windows and release and debug configurations for Gnu on Linux in the same project. However, there isn't much support in the MBS to make this easy yet. You can create these configurations separately and maintain them by hand separately. In the future we would like to add functionality like: 1. Supplying tool-chain converters that can convert a configuration from one tool-chain to another, and have as many of the tool properties as possible applied to the new tool-chain. With Gnu -> Gnu, this should be fairly easy. 2. Cloning a new configuration from an existing configuration, and changing the tool-chain. This would use the coneverters. 3. Selecting a set of configurations and changing their options at the same time. For example, selecting all "debug" configurations, or selecting all "win32" configurations. If you take a look at the document in bugzilla 68232, you can get additional descriptions of things we would like to do. I'm assuming that the problem you had has to do with the fact that Cygwin paths are handled somewhat specially, and that will only happen when the configuration is using the Cygwin tool-chain.
FMI: MBS == Managed Build System (FMI == for my information :-) Thank you for the explanation. Yes, it sounds like tool-chain converters would be the solution to my problem. Even I do not daily switch C++ projects back and forth between Linux and Windows :-) It would be nice to have this fully supported the way you describe it, but it is not a top priority. Please feel free to close this issue or move it to a wishlist... whatever suits best.
I'm setting the severity to "enhancement".
