Home » Language IDEs » C / C++ IDE (CDT) » Yet another Cygwin Issue, CDT_INCLUDE
| Yet another Cygwin Issue, CDT_INCLUDE [message #124797] |
Fri, 22 October 2004 18:53  |
Eclipse User |
|
|
|
Originally posted by: eclipse.dharty.com
Ok, here's the problem:
I have two C projects in my workspace. When I start up Eclipse, I get
the following errors as soon as I select either project:
Invalid path:/SerialTest [CDT_INCLUDE] isSystemInclude:true
includePath:/usr/include
Invalid path:/SerialTest [CDT_INCLUDE] isSystemInclude:true
includePath:/usr/include/w32api
Invalid path:/SerialTest [CDT_INCLUDE] isSystemInclude:true
includePath:/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/include
This is a relatively new problem, as I was able in the past to compile
using a non-cygwin installation of gcc. I have not as yet been able to
compile using cygwin, and switching my path back to the old, non-cygwin
gcc gives me the same problem.
I'm using Eclipse 3.0.1 with CDT 2.0.2, Java 1.5.0 and Cygwin updated as
of just before this posting. I had the same trouble with 3.0.0 and
2.0.1 and I thought updating might help.
My path is:
C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\u sr\cygwin;C:\usr\cygwin\bin
Thanks
|
|
| | | |
| Re: Yet another Cygwin Issue, CDT_INCLUDE [Partial Solution] [message #125288 is a reply to message #125213] |
Wed, 27 October 2004 13:48  |
| Eclipse User |
|
|
|
David,
I am not really sure what problem you are dealing with, but maybe this
will help you figure out where the problem lies. There are two types of
includes path/#define information for most builds. Paths to includes
files that you supply in a project's source tree are supplied through
the makefile in a standard build project and through the properties page
in a managed project. The GNU compiler has a built-in set of include
paths and #defines too, but users generally don't have to see or deal
with them. In order for the CDT scanner/parser to function, we need the
union of those two data sets.
In order for us to discover the built-in settings (which you will not
explicitly specify anywhere), the Managed Build System tries to figure
this out dynamically. For either Windows or POSIX Gnu projects, it will
call the compiler with a preset argument and parse the output for
includes paths and #defines. Even if you create a non-Windows GNU target
and bring it over to Windows, it will still call the build tool for the
target; either 'gcc' or 'g++'. When you install the compiler on Cygwin,
it is called gcc or g++, so if it is in the path, and you haven't
renamed it, and you KNOW FOR SURE that it is installed (because it often
isn't by default), then CDT will find it, call it, and parse the output.
In terms of your own include search paths, a POSIX project will specify
search paths like /home/david/project/include but that likely equates to
a Windows path like C:\Cygwin\home\david\project\include. In that case,
the settings will be wrong and you will have to manually edit them.
To forestall the inevitable question about why we don't automagically
convert the project settings for you, I can only say that we are trying
to come up with a decent way to specify common path elements for the
next major release of the MBS.
Hope this helps. Of course, more detailed explanations of the work-flow
you are attempting and the problems you are seeing would be helpful for
future questions.
Sean
David H wrote:
>
>
> It would appear that if one does not use "Executable (Gnu on Windows)"
> target platform, Eclipse looks for those directories in /usr instead of
> c:\cygwin\usr\. I fixed this by putting copies of the requested
> directories under c:\usr\
>
> Is there any way to change the target platform once the project has been
> created?
>
>
>
>
>
>
>
>
>
>
>
>
>
> David wrote:
>
>> Ok, here's the problem:
>>
>> I have two C projects in my workspace. When I start up Eclipse, I get
>> the following errors as soon as I select either project:
>>
>> Invalid path:/SerialTest [CDT_INCLUDE] isSystemInclude:true
>> includePath:/usr/include
>> Invalid path:/SerialTest [CDT_INCLUDE] isSystemInclude:true
>> includePath:/usr/include/w32api Invalid path:/SerialTest
>> [CDT_INCLUDE] isSystemInclude:true
>> includePath:/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/include
>>
>> This is a relatively new problem, as I was able in the past to compile
>> using a non-cygwin installation of gcc. I have not as yet been able
>> to compile using cygwin, and switching my path back to the old,
>> non-cygwin gcc gives me the same problem.
>>
>> I'm using Eclipse 3.0.1 with CDT 2.0.2, Java 1.5.0 and Cygwin
>> updated as of just before this posting. I had the same trouble with
>> 3.0.0 and 2.0.1 and I thought updating might help.
>>
>> My path is:
>>
>> C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\u sr\cygwin;C:\usr\cygwin\bin
>>
>>
>> Thanks
>>
|
|
|
| Re: Yet another Cygwin Issue, CDT_INCLUDE [Partial Solution] [message #125299 is a reply to message #125288] |
Wed, 27 October 2004 14:39 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.dharty.com
Thanks for the reply Sean.
In an attempt to give you an idea of my workflow (and why I didn't
choose "Executable (Gnu on Windows)" in the firstplace, I am trying to
use Eclipse as an itererim interface for embedded system software which
uses the Integrity Real-Time Operating System. For all practical
purposes, the project has to be built using their IDE which is quite
crappy, but does the things needed for their operating system like
defining IO device interfaces, shared memory (which must be designated
in a special file) and address spaces (Integrity specific) which are not
allowed to access kernel memory or other address spaces directly without
using the proprietary tools.
There is a way to do this all by the command line, given the correct
non-c files which describe the above allowed interfaces, but I was just
hoping to use Eclipse as a better ide with all of the code completion
features etc. When I figure out a way to set up the tools to build from
the command line, I will be able (I hope) to use those instead of the
standard make, but for now I am using gcc to give me a preliminary idea
of whether the code will compile or not.
HTH.
Sean Evoy wrote:
> David,
> I am not really sure what problem you are dealing with, but maybe this
> will help you figure out where the problem lies. There are two types of
> includes path/#define information for most builds. Paths to includes
> files that you supply in a project's source tree are supplied through
> the makefile in a standard build project and through the properties page
> in a managed project. The GNU compiler has a built-in set of include
> paths and #defines too, but users generally don't have to see or deal
> with them. In order for the CDT scanner/parser to function, we need the
> union of those two data sets.
>
> In order for us to discover the built-in settings (which you will not
> explicitly specify anywhere), the Managed Build System tries to figure
> this out dynamically. For either Windows or POSIX Gnu projects, it will
> call the compiler with a preset argument and parse the output for
> includes paths and #defines. Even if you create a non-Windows GNU target
> and bring it over to Windows, it will still call the build tool for the
> target; either 'gcc' or 'g++'. When you install the compiler on Cygwin,
> it is called gcc or g++, so if it is in the path, and you haven't
> renamed it, and you KNOW FOR SURE that it is installed (because it often
> isn't by default), then CDT will find it, call it, and parse the output.
>
> In terms of your own include search paths, a POSIX project will specify
> search paths like /home/david/project/include but that likely equates to
> a Windows path like C:\Cygwin\home\david\project\include. In that case,
> the settings will be wrong and you will have to manually edit them.
>
> To forestall the inevitable question about why we don't automagically
> convert the project settings for you, I can only say that we are trying
> to come up with a decent way to specify common path elements for the
> next major release of the MBS.
>
> Hope this helps. Of course, more detailed explanations of the work-flow
> you are attempting and the problems you are seeing would be helpful for
> future questions.
>
> Sean
>
> David H wrote:
>
>>
>>
>> It would appear that if one does not use "Executable (Gnu on Windows)"
>> target platform, Eclipse looks for those directories in /usr instead
>> of c:\cygwin\usr\. I fixed this by putting copies of the requested
>> directories under c:\usr\
>>
>> Is there any way to change the target platform once the project has
>> been created?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> David wrote:
>>
>>> Ok, here's the problem:
>>>
>>> I have two C projects in my workspace. When I start up Eclipse, I
>>> get the following errors as soon as I select either project:
>>>
>>> Invalid path:/SerialTest [CDT_INCLUDE] isSystemInclude:true
>>> includePath:/usr/include
>>> Invalid path:/SerialTest [CDT_INCLUDE] isSystemInclude:true
>>> includePath:/usr/include/w32api Invalid path:/SerialTest
>>> [CDT_INCLUDE] isSystemInclude:true
>>> includePath:/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/include
>>>
>>> This is a relatively new problem, as I was able in the past to
>>> compile using a non-cygwin installation of gcc. I have not as yet
>>> been able to compile using cygwin, and switching my path back to the
>>> old, non-cygwin gcc gives me the same problem.
>>>
>>> I'm using Eclipse 3.0.1 with CDT 2.0.2, Java 1.5.0 and Cygwin
>>> updated as of just before this posting. I had the same trouble with
>>> 3.0.0 and 2.0.1 and I thought updating might help.
>>>
>>> My path is:
>>>
>>> C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\u sr\cygwin;C:\usr\cygwin\bin
>>>
>>>
>>> Thanks
>>>
|
|
|
Goto Forum:
Current Time: Sun Jul 13 16:45:48 EDT 2025
Powered by FUDForum. Page generated in 0.08907 seconds |
Home