Home » Language IDEs » C / C++ IDE (CDT) » includes hosed
| includes hosed [message #217686] |
Mon, 23 June 2008 15:53  |
Eclipse User |
|
|
|
Originally posted by: noah.roberts.eng-software.com
I tried to put my eclipse installation on a different drive than the one
upon which mingw is installed. Unfortunately this caused a bunch of
errors because eclipse "discovered" a bunch of "built-in" include paths
including /mingw, which is just nonsense on a win32 box. This is *in
addition to* the c:\mingw directories that DO make sense.
In attempting to resolve this I tried to turn off discovery. That
didn't make the variables go away. So I put eclipse back on the C drive
and that "solved" the warning problem (the directories are still wrong
but work). So I decided to turn discovery back on.
The next time I built that project, eclipse "discovered" two additional
"built-in" directories that are exactly the same as previously
"discovered" directories. Now I get crap about include directories
being duplicate entries but I am left with absolutely no way to delete
them that I can see.
I've searched google for help...people that ask this question never get
an answer. I've searched high and low in my workspace, eclipse
directory, and "Documents and Settings" tree hoping to find ANYTHING
with "mingw" in a configuration of some sort...hoping to be able to edit
these things away by hand. But there appears to be absolutely nothing
in which this information is stored, which really begs the question of
where the hell it's coming from to begin with (new projects are created
with only the c:\mingw and partner /mingw directories I was originally
concerned with, not the additional copies of the c:\mingw directories).
Furthermore, there doesn't seem to be any way to create a new project
that doesn't do this "discovery" thing. I could set an INCLUDE path
myself if I could just gain control of this interface...get it to stop
trying to be smarter than me. The only method I've found is to change
the name of c:\mingw to something else so the toolkit does not appear.
However, if I do that then there are a bunch of other settings that
possibly need to be altered and set up...I'm hoping to avoid that.
Furthermore, if I then put the new c:\not-mingw\bin into the path then
eclipse begins, once again, "discovering" these paths.
Is there anything I can do about any of this? Is my project permanently
hosed or is there a way to remove these duplicate include entries that
eclipse nicely created for me? Is there a way to both use mingw and not
have it do this to me? Can I somehow bypass this "built-in" behavior
and get real control of my IDE (I'm apparently not allowed to alter
these directories through the interface) or do I have to pray that it
does the right thing...even though it obviously doesn't?
Thanks.
|
|
| |
| Re: includes hosed [message #217731 is a reply to message #217686] |
Tue, 24 June 2008 10:32  |
| Eclipse User |
|
|
|
Noah Roberts wrote:
> I tried to put my eclipse installation on a different drive than the one
> upon which mingw is installed. Unfortunately this caused a bunch of
> errors because eclipse "discovered" a bunch of "built-in" include paths
> including /mingw, which is just nonsense on a win32 box. This is *in
> addition to* the c:\mingw directories that DO make sense.
>
> In attempting to resolve this I tried to turn off discovery. That
> didn't make the variables go away. So I put eclipse back on the C drive
> and that "solved" the warning problem (the directories are still wrong
> but work). So I decided to turn discovery back on.
>
> The next time I built that project, eclipse "discovered" two additional
> "built-in" directories that are exactly the same as previously
> "discovered" directories. Now I get crap about include directories
> being duplicate entries but I am left with absolutely no way to delete
> them that I can see.
>
> I've searched google for help...people that ask this question never get
> an answer. I've searched high and low in my workspace, eclipse
> directory, and "Documents and Settings" tree hoping to find ANYTHING
> with "mingw" in a configuration of some sort...hoping to be able to edit
> these things away by hand. But there appears to be absolutely nothing
> in which this information is stored, which really begs the question of
> where the hell it's coming from to begin with (new projects are created
> with only the c:\mingw and partner /mingw directories I was originally
> concerned with, not the additional copies of the c:\mingw directories).
>
> Furthermore, there doesn't seem to be any way to create a new project
> that doesn't do this "discovery" thing. I could set an INCLUDE path
> myself if I could just gain control of this interface...get it to stop
> trying to be smarter than me. The only method I've found is to change
> the name of c:\mingw to something else so the toolkit does not appear.
> However, if I do that then there are a bunch of other settings that
> possibly need to be altered and set up...I'm hoping to avoid that.
> Furthermore, if I then put the new c:\not-mingw\bin into the path then
> eclipse begins, once again, "discovering" these paths.
>
> Is there anything I can do about any of this? Is my project permanently
> hosed or is there a way to remove these duplicate include entries that
> eclipse nicely created for me? Is there a way to both use mingw and not
> have it do this to me? Can I somehow bypass this "built-in" behavior
> and get real control of my IDE (I'm apparently not allowed to alter
> these directories through the interface) or do I have to pray that it
> does the right thing...even though it obviously doesn't?
>
> Thanks.
This sounds similar to following bugs:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=214029
https://bugs.eclipse.org/bugs/show_bug.cgi?id=214438
If your problem is not covered by the bugs above,
I suggest to file a new bug with steps to reproduce.
Maybe you can try the following workaround to refresh the discovery
info. It works for me.
- open discovery properties
- select Configuration-wide in the scope drop down
- disable Automate discovery...
- OK
- open discovery properties again
- enable Automate discovery...
- OK
HTH
--
Anton Leherbauer
Wind River CDT Team, Austria
|
|
|
| Re: includes hosed [message #217763 is a reply to message #217731] |
Tue, 24 June 2008 15:49 |
| Eclipse User |
|
|
|
Originally posted by: noah.roberts.eng-software.com
Anton Leherbauer wrote:
> Noah Roberts wrote:
>> I tried to put my eclipse installation on a different drive than the
>> one upon which mingw is installed. Unfortunately this caused a bunch
>> of errors because eclipse "discovered" a bunch of "built-in" include
>> paths including /mingw, which is just nonsense on a win32 box. This
>> is *in addition to* the c:\mingw directories that DO make sense.
>>
>> In attempting to resolve this I tried to turn off discovery. That
>> didn't make the variables go away. So I put eclipse back on the C
>> drive and that "solved" the warning problem (the directories are still
>> wrong but work). So I decided to turn discovery back on.
>>
>> The next time I built that project, eclipse "discovered" two
>> additional "built-in" directories that are exactly the same as
>> previously "discovered" directories. Now I get crap about include
>> directories being duplicate entries but I am left with absolutely no
>> way to delete them that I can see.
>>
>> I've searched google for help...people that ask this question never
>> get an answer. I've searched high and low in my workspace, eclipse
>> directory, and "Documents and Settings" tree hoping to find ANYTHING
>> with "mingw" in a configuration of some sort...hoping to be able to
>> edit these things away by hand. But there appears to be absolutely
>> nothing in which this information is stored, which really begs the
>> question of where the hell it's coming from to begin with (new
>> projects are created with only the c:\mingw and partner /mingw
>> directories I was originally concerned with, not the additional copies
>> of the c:\mingw directories).
>>
>> Furthermore, there doesn't seem to be any way to create a new project
>> that doesn't do this "discovery" thing. I could set an INCLUDE path
>> myself if I could just gain control of this interface...get it to stop
>> trying to be smarter than me. The only method I've found is to change
>> the name of c:\mingw to something else so the toolkit does not appear.
>> However, if I do that then there are a bunch of other settings that
>> possibly need to be altered and set up...I'm hoping to avoid that.
>> Furthermore, if I then put the new c:\not-mingw\bin into the path then
>> eclipse begins, once again, "discovering" these paths.
>>
>> Is there anything I can do about any of this? Is my project
>> permanently hosed or is there a way to remove these duplicate include
>> entries that eclipse nicely created for me? Is there a way to both
>> use mingw and not have it do this to me? Can I somehow bypass this
>> "built-in" behavior and get real control of my IDE (I'm apparently not
>> allowed to alter these directories through the interface) or do I have
>> to pray that it does the right thing...even though it obviously doesn't?
>>
>> Thanks.
>
> This sounds similar to following bugs:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=214029
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=214438
>
Actually I think my problem is one of design. I'm not allowed to edit
these values when they are wrong. If eclipse would just let me tell it,
"No, don't do that!" then things would be great.
I can work around it, I think, by putting mingw in a place that is not
c:\mingw. Then mingw doesn't return the /mingw paths as includes and so
eclipse doesn't pick them up. The problem is that when I do this, and I
set the PATH variable correctly, eclipse can't seem to give me access to
the MinGW toolchain. It seems to think that mingw doesn't exist.
One of my coworkers has his mingw in a different location and does not
have this problem. He installed some sort of Qt plugin. He also, as a
consequence, runs eclipse from a batch file. But all that does is set
the PATH variable exactly as I do and call eclipse with a "-clean"
command line argument. It doesn't work for me though.
How does eclipse go about searching for the "compatible" toolchains?
|
|
|
| Re: includes hosed [message #217770 is a reply to message #217763] |
Tue, 24 June 2008 16:29 |
| Eclipse User |
|
|
|
Originally posted by: noah.roberts.eng-software.com
Ok, I seem to have a workaround that will, I hope, meet my needs. I
simply must have mingw and eclipse in the same directory such that it
looks like:
\top
|---eclipse
|.....eclipse.exe
|---mingw
|-----bin
|.......g++ and friends.
Set up like that, and only like that, eclipse seems to magically decide
to look in ..\mingw for MinGW and then gathers the correct, and only the
correct, include directories.
No other combination of things seems to work and after much scouring of
the file tree in eclipse and my workspace I can find nothing that sets
up this behavior; it must be built into the program itself. Good thing
I don't need to do cross-platform development, otherwise I'd have to
have multiple copies of eclipse hanging around; one for each compiler
version.
I really, really cannot stress enough how limiting the inability to edit
the include paths in eclipse is. This is really a terrible "feature".
I should have complete control of the IDE, including any directory it
decides I should have in my include path. The entire discovery process
could be completely broken and it would not be as frustrating as not
being able to alter the list it generates.
|
|
| |
| Re: includes hosed [message #217792 is a reply to message #217777] |
Tue, 24 June 2008 18:30 |
| Eclipse User |
|
|
|
Originally posted by: noah.roberts.eng-software.com
kesselhaus wrote:
> Noah Roberts schrieb:
>> Here is a screenshot of what I'm talking about:
>>
>> http://i42.photobucket.com/albums/e306/nroberts-photos/grrr. png?t=1214251039
>>
>>
>> Notice the duplicates of the c:/mingw directories in addition to the
>> /mingw copies of the same. That makes 3 entries for each individual
>> directory that actually exists.
>
> These /mingw directories make totally sense also on a Win32, since this
> is the path used in the MSYS shell used (which is also used for building
> MinGW and the reason for this paths).
>
Yes, I realize that. But that is the only thing on a win32 system for
which it does make sense. Any program that doesn't pretend it's on a
unix system, is not run from msys, and is run from another drive will
have a really hard time understanding it. Eclipse appears to fall into
the category of not being able to make sense of it.
Quite simply, it's not a standard path specifier on the win32 system and
should be ignored by eclipse. Further, eclipse should certainly allow
one to delete such nonsense paths in the includes.
|
|
|
Goto Forum:
Current Time: Tue May 06 21:17:09 EDT 2025
Powered by FUDForum. Page generated in 0.04414 seconds |
Home