Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 333587

Summary: Support new MinGW Installer
Product: [Tools] CDT Reporter: Doug Schaefer <cdtdoug>
Component: cdt-buildAssignee: 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 CLA 2011-01-05 12:49:02 EST
The new MinGW installer looks pretty good. However it does necessitate some changes to the env var supplier for the toolchain.

First, we shouldn't rely on the uninstaller location to find the toolchain. As we see, this can change any time.

We should add the dependency for MSYS which is now installed with MinGW under it's tree.

Define a MINGW_HOME env var so users can use that to tell us where the tree is if it's not in the default C:\MinGW.
Comment 1 Doug Schaefer CLA 2011-01-05 13:22:51 EST
Need to apply to 7.0 and HEAD.
Comment 2 CDT Genie CLA 2011-01-05 14:23:05 EST
*** 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
Comment 3 CDT Genie CLA 2011-01-05 14:23:09 EST
*** 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
Comment 4 Andrew Gvozdev CLA 2011-01-06 00:42:30 EST
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.
Comment 5 Doug Schaefer CLA 2011-01-06 10:08:39 EST
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.
Comment 6 Doug Schaefer CLA 2011-01-06 10:08:54 EST
Code is checked in. marking resolved.
Comment 7 Andrew Gvozdev CLA 2011-01-06 11:41:27 EST
(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.
Comment 8 Liviu CLA 2011-03-11 23:22:09 EST
> 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.
Comment 9 Doug Schaefer CLA 2011-03-14 10:33:04 EDT
Anyone with a bugzilla account can update the wiki ;)
Comment 10 Liviu CLA 2011-03-14 11:37:31 EDT
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.