| Summary: | Support new MinGW Installer | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Doug Schaefer <cdtdoug> |
| Component: | cdt-build | Assignee: | Doug Schaefer <cdtdoug> |
| Status: | RESOLVED FIXED | QA Contact: | Andrew Gvozdev <angvoz.dev> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | cdtdoug, lab2k1 |
| Version: | 7.0 | ||
| Target Milestone: | 7.0.2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Doug Schaefer
Need to apply to 7.0 and HEAD. *** cdt cvs genie on behalf of dschaefer *** Bug 333587 - Update to handle new MinGW installer. [*] MingwEnvironmentVariableSupplier.java 1.12 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.managedbuilder.gnu.ui/src/org/eclipse/cdt/managedbuilder/gnu/mingw/MingwEnvironmentVariableSupplier.java?root=Tools_Project&r1=1.11&r2=1.12 *** cdt cvs genie on behalf of dschaefer *** Bug 333587 - Update to work with new MinGW installer. Backported from HEAD. [*] MingwEnvironmentVariableSupplier.java 1.10.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.managedbuilder.gnu.ui/src/org/eclipse/cdt/managedbuilder/gnu/mingw/MingwEnvironmentVariableSupplier.java?root=Tools_Project&r1=1.10&r2=1.10.2.1 Answering the question put as comments in the code (how weird, do you expect the answer in next revision?)
> // Look in PATH values. Look for mingw32-gcc.exe
> // TODO: Since this dir is already in the PATH, why are we adding it here?
It is not certainty that the dir is in the PATH. For systems where both cygwin and mingw are installed it is not rare that users remove one of them or both from the PATH because of interference. And, frankly, using PATH is more transparent for users, we had so many complains because users cannot figure out how to convince CDT to find mingw/cygwin installations, the user forum is full of those.
My point is that the code is trying to set up the PATH so that the build finds the MinGW compiler. The segment where I placed the comment is looking through the PATH to find the compiler. If it's already there, why do we need to do anything? It's a no-op. Unless you have cygwin first in the path, in which case why do you have both there? That doesn't make much sense either. And it's why I've added the segment to use the MINGW_HOME environment variable that the user can add to point at his MinGW install. BTW, also to be clear, this code is not intended to support the MinGW compiler that comes with cygwin. That compiler suffers the same problem that the rest of cygwin does, un-native paths. Code is checked in. marking resolved. (In reply to comment #5) > My point is that the code is trying to set up the PATH so that the build finds > the MinGW compiler. The segment where I placed the comment is looking through > the PATH to find the compiler. If it's already there, why do we need to do > anything? It's a no-op. > Unless you have cygwin first in the path, in which case why do you have both > there? That doesn't make much sense either. There could be various reasons. We are using cygwin because it provides a bunch of utilities which mingw does not, like ssh for example and so cygwin is primary. Mingw is in the path too in order for CDT to be able to find it (it is installed in custom user folder). Another reason is that our corporate system insists on certain system PATH which you don't have permissions to change (that's Windows) and having the path appended in the beginning of PATH is very handy. Hell, you need administrative permissions to change the user PATH on Windows 7. > And it's why I've added the segment to use the MINGW_HOME environment variable > that the user can add to point at his MinGW install. That is definitely good to have variable like that. > Define a MINGW_HOME env var [...] to tell us where the tree is Thanks for that. Don't know what bug it fixed, but it's a useful feature on its own. But now the CDT MinGW FAQ entry badly needs an update. http://wiki.eclipse.org/CDT/User/FAQ#I_installed_MinGW_toolchain_on_my_PC_but_Eclipse_won.27t_find_it. Anyone with a bugzilla account can update the wiki ;) Well, yes, but I thought that's one of those things better left to the pros ;-) Seriously now, I don't have enough background to chime in with any savvy. For one thing, the wiki entry must be true for certain versions (up to sr2, I'd guess) if not the latest. I still think MINGW_HOME is useful enough to deserve documenting somewhere. Right now, the only such places seem to be the source code and this page. |