First of all, great idea to bundle the Eclipse CDT and the MinGW GNU toolchain! I have been working for some time now with Eclipse CDT and MinGW/MSYS and it proves to be a great IDE, especially with CDT 4.0.
However I experience a problem with the indexer and MinGW/MSYS paths, the include paths are not discovered correctly, because the MSYS paths are non 'standard' windows paths.
Windows path = C:\proj1\
MSYS path = /c/proj1/
This is especially a problem when using external libraries and sources, e.g. wxWidgets which will be hard to reference with a relative path.
The current work-around that I use is a string replace of the paths during a build and store the output in a build.log. Within Eclipse a 'load output from file'. This works, however it is cumbersome.
make all VERBOSE=1 | sed -e 's|/c/|c:\\|g' -e 's|/d/|d:\\|g' -e 's|/e/|e:\\|g' -e 's|/usr/|c:\\programs\\msys\\|g' -e 's|/|\\|g' > build.log
It would be great to deal with MSYS paths from Eclipse/CDT directly instead of the additional step that I perform now.
A couple of points. First one is that the MinGW tools should be fine with Windows paths, which is what the CDT feeds it.
Second is that CDT for Windows doesn't ship with MSYS. It is really intended for people using CDT's internal builder. So you must be using MSYS from somewhere else on your system. I did have some issues when I had another MinGW was already installed at C:/mingw that I'll need to resolve. And we haven't really tested using MSYS as a shell very much so there may be issues. But those should be raised to the CDT directly.
This message may be a touch too late, but I'll throw it out there for the community at large.
If you're like me and have multiple tools installed, adding tools to the Windows PATH variable can make it grow to the point of it being unreadable (isn't there a limit to the size of system variables?). Also, a global PATH variable can create conflicts. For example, Dev-C++ (http://wxdsgn.sourceforge.net/) installs with its own binaries of MinGW which can get conflicted if you have a separate installation of MinGW. I've seen help-log/postings saying that users should NOT add their MinGW path to the Windows PATH variable to avoid this conflict.
Okay, I understand this has nothing to do with your situation, but the solution could...
You can replace Windows settings Eclipse grabs at start-up for use internally.
- assume you have MinGW fully installed
(You can download a really good Automated Installer for Windows from the Sourceforge page - latest version 5.1.3. Part of this package is a utility exe that can upgrade your MinGW installation. Its not "bleeding edge" but it will help to keep you up to date).
- assume your Eclipse is open and that you have copied the contents of your Windows PATH variable to the clipboard.
Select from the Eclipse menu Windows->Preferences...
With the Eclipse preferences open, expand the C/C++ branch and select Environment entry to show the Environment variables.
Click [New] and enter the following:
VALUE: C:\path\to\msys;C:\path\to\mingw (NOTE: Windows format paths) and paste in the remainder of you path variable from Windows
...and click [OK] to return to the Environment variables. BEFORE clicking [APPLY], make sure you have selected the radio button for "Replace native environment with specified one". Now click [APPLY].
Every time Eclipse opens, it will use what you have entered for the PATH variable internally. So msys and MinGW commands will execute within Eclipse without problems. And since Eclipse knows you're putting in a Windows format for path, let it deal with translation if necessary. A downside (and I think its minor) is that you'll have to remember to update Eclipse settings if you alter or add other external tools you want utilized in Eclipse.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.