|
Rex Lam
09/30/2009 1:41 PM
post39109
|
I am using IDE 4.6 (build id I20090510) and IDE 4.6.1 (build id I20090901) on Windows 7 with qnxsdk 6.4.1. After
importing my projects into a new workspace, I set the C++ indexer to full for complete parse. I also checked the
checkbox "Index all files". The C/C++ indexer runs for quite a while, then it stops. That implies that the indexing is
completed.
When I open a file, all the #include have a warning on the left margin - "Unresolved inclusion". If I highlight the
referenced header file, right-click, and select "Open Declaration" or hold down ctrl key and click on it, it gives me an
error - Could not find include file 'xxx.hpp' on include paths.
This occurs when the release variant is selected. If I switch to the debug variant, the "Unresolved inclusion" warning
goes away, and I can then open the header file using the above methods. If I switch back to the release variant, the
problem returns.
I would like to know what caused this problem and whether there is already a fix for it.
|
|
|
|
|
|
Christian Damus(deleted)
09/30/2009 1:48 PM
post39111
|
Hi, Rex,
What do you mean by "switch to" the other variant? Are your projects
managed-make or makefile projects, and you are selecting the
Release/Debug configurations? Or, are they QNX C/C++ projects and you
are enabling or disabling the release/debug variants?
Assuming that you are working with managed-make projects using the QNX
QCC toolchain, have you built the Release configuration? Does
re-building it fix the problem? (the scanner discovery generally runs
only during a build)
What are your scanner discovery settings in the project properties, on
the "C/C++ Build -> Discovery Options" page? Do you have the QNX QCC
per-project or per-file profile selected for the Release configuration?
Do you have the option to parse build output for additional include
paths selected?
Cheers,
Christian
On Wed, 2009-09-30 at 13:41 -0400, Rex Lam wrote:
> I am using IDE 4.6 (build id I20090510) and IDE 4.6.1 (build id I20090901) on Windows 7 with qnxsdk 6.4.1. After
importing my projects into a new workspace, I set the C++ indexer to full for complete parse. I also checked the
checkbox "Index all files". The C/C++ indexer runs for quite a while, then it stops. That implies that the indexing is
completed.
>
> When I open a file, all the #include have a warning on the left margin - "Unresolved inclusion". If I highlight the
referenced header file, right-click, and select "Open Declaration" or hold down ctrl key and click on it, it gives me an
error - Could not find include file 'xxx.hpp' on include paths.
>
> This occurs when the release variant is selected. If I switch to the debug variant, the "Unresolved inclusion"
warning goes away, and I can then open the header file using the above methods. If I switch back to the release variant
, the problem returns.
>
> I would like to know what caused this problem and whether there is already a fix for it.
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post39109
>
|
|
|
|
|
|
Rex Lam
09/30/2009 2:10 PM
post39114
|
Hi Christian,
My projects are QNX C/C++ projects. I am enabling either the release or debug variant, one at a time. Most projects
are configured with only the release variant enabled by default.
I could not find where scanner discovery settings or discovery options are. Is this for managed-make projects only?
Rex
|
|
|
|
|
|
Christian Damus(deleted)
09/30/2009 3:36 PM
post39127
|
Hi, Rex,
That is correct, the settings I was referring to do not apply to QNX
projects.
In the QNX project properties, you can indicate which variant is used
for indexing. This implies the determination of include paths. When
only one variant is to be built, then there is no choice of which to use
for indexing.
I have tried switching build variants in the same way as you described
on the IDE 4.7 development stream, in a QNX C++ project that is imported
from an IDE 4.6 workspace and also in an IDE 4.6 workspace that I open
with IDE 4.7 (thus migrating it). I don't see any problem with
resolution of includes.
Are these system includes that are not resolving, or files in other
projects in the same workspace? You might try the latest pre-release
build of IDE 4.7 from the Foundry download page to see whether it
resolves your problem. Note, however, that it includes an upgrade of
Eclipse CDT from version 5.0.x to 6.0.
HTH,
Christian
On Wed, 2009-09-30 at 14:10 -0400, Rex Lam wrote:
> Hi Christian,
>
> My projects are QNX C/C++ projects. I am enabling either the release or debug variant, one at a time. Most projects
are configured with only the release variant enabled by default.
>
> I could not find where scanner discovery settings or discovery options are. Is this for managed-make projects only?
>
> Rex
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post39114
>
________________________________________________________________________
Christian W. Damus
Software Developer, IDE Team
QNX Software Systems
|
|
|
|
|
|
Rex Lam
09/30/2009 3:57 PM
post39129
|
Christian,
I have tried installing different versions of IDE 4.x concurrently (on a different PC), and have been able to
simultaneously run different IDE versions without issue. Will I be able to do the same between IDE 4.6 and IDE 4.7,
given that there is an upgrade of eclipse on 4.7? I plan to use different workspaces for each of these IDEs. Will that
work? Will my project files be migrated and not be backwards compatible with IDE 4.6 if I start using IDE 4.7?
It is strange that indexing works properly when the debug variant is enabled, but doesn't work properly when the release
variant is enabled. I am building for x86, if that makes a difference.
Rex
|
|
|
|
|
|
Rex Lam
10/01/2009 11:30 AM
post39205
|
I installed IDE 4.7 and imported my projects to a new workspace. Ran full indexing and got the same results. I also
found out that header files that reside in a different project have the "Unresolved Inclusion" warning. Header files
that are in the same project are resolved correctly.
In the compiler properties page, the additional paths are specified under "Extra include paths". For example, one
project has these extra include paths:
$(PROJECT_ROOT)/inc
$(PROJECT_ROOT_System)/inc
$(PROJECT_ROOT_XOS)/inc
Header files in $(PROJECT_ROOT)/inc are resolved, but not from the other two. Does anyone know what the problem might
be?
|
|
|
|
|
|
Christian Damus(deleted)
10/01/2009 12:32 PM
post39215
|
Hi, Rex,
I see, so it's includes from other projects that are not working. This
helps.
Could it be that your extra includes are defined only for the debug
variant, and not for the release variant?
Does building the project succeed? (i.e., is it just an indexing/editor
problem)
With the extra detail of including folders from other workspace
projects, I am still not able to reproduce this problem. Perhaps we
could advance the analysis further if you can share some subset (or a
facsimile) of your projects that demonstrate the symptom? I can be
reached off-line at cdamus at qnx dot com.
Cheers,
Christian
On Thu, 2009-10-01 at 11:30 -0400, Rex Lam wrote:
> I installed IDE 4.7 and imported my projects to a new workspace. Ran full indexing and got the same results. I also
found out that header files that reside in a different project have the "Unresolved Inclusion" warning. Header files
that are in the same project are resolved correctly.
>
> In the compiler properties page, the additional paths are specified under "Extra include paths". For example, one
project has these extra include paths:
> $(PROJECT_ROOT)/inc
> $(PROJECT_ROOT_System)/inc
> $(PROJECT_ROOT_XOS)/inc
>
> Header files in $(PROJECT_ROOT)/inc are resolved, but not from the other two. Does anyone know what the problem might
be?
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post39205
>
|
|
|
|
|
|
Rex Lam
10/01/2009 12:35 PM
post39218
|
Christian,
The projects build successfully. It is just an indexing problem. I will create a small example and send to your email.
Thanks for your help.
Rex
|
|
|
|
|
|
Rex Lam
10/02/2009 2:42 PM
post39315
|
Christian,
I have trouble sending the attachment to you via emaiil. Our IS server has blocked all my attempts. I am attaching it
here so that you can take a look. Please let me know if you have any questions.
The attached projects demonstrates the “Unresolved inclusion” problem on my IDE. I used IDE 4.6.1. Please go ahead
and use the same workspace if you like. Please let me know if you need any other information. I have tried this IDE on
another PC that has qnxsdk 6.3.2 installed, and it works great there. My PC has qnxsdk 6.4.1 installed.
Rex
|
|
|
|
|
|
Rex Lam
10/06/2009 8:42 PM
post39470
|
Any news on this problem? I ran more tests and it appears to be a problem when 6.4 sdk is selected. My PC has both
SDKs. I installed QNX 6.4.1 sdk and copied the 6.3.2 sdk directory from another PC. I renamed the 6.4 sdk directory (D
:\qnxsdk\qnxsdk6.4-001) to D:\qnxsdk\qnxsdk6.4-001_actual) and renamed the 6.3.2 sdk directory to D:\qnxsdk\qnxsdk6.4-
001 so that I could build with 6.3.2 rather than 6.4. All environment variables remain the same, as installed for 6.4.1
.
With 6.3.2 sdk in use, there is no problem with the indexer while using IDE 4.6.1. I can highlight a header file and
select "Open Declaration" or hold down the ctrl key and press the link. It also works with variables and function names
.
Based on these results, it appears to be a problem with the 6.4.1 sdk. I installed only qnxsdp-6.4.1-200905201802-win32
.exe on my PC. Do I need any other files?
|
|
|
|
|
|
Christian Damus(deleted)
10/07/2009 12:18 PM
post39534
|
Hi, Rex,
Sorry for the long delay in replying.
I have tried importing your test projects into an IDE 4.6.1 workspace on
a Windows host that has SPE 6.3.2, 6.4.0, ad 6.4.1 installed and
targeting the 6.4.1 version.
When I first import the projects, of course none of the includes are
resolved because I haven't yet built. Then, after building the
"release" variant only of the "MyProject" project, all of the imports
resolve, including the MyLibrary/inc/Header1.hpp.
Switching to the "debug" variant, the imports still resolve.
Switching back to building only the "release" variant, the imports all
still resolve.
I'm not sure what else could be amiss in your environment. Are you
certain that you're re-building automatically when the QNX C/C++ Project
settings are changed? Discovering include folders depends on the output
of the build. I don't see how the availability of certain SDP targets
would affect the problem.
Cheers,
Christian
On Tue, 2009-10-06 at 20:42 -0400, Rex Lam wrote:
> Any news on this problem? I ran more tests and it appears to be a problem when 6.4 sdk is selected. My PC has both
SDKs. I installed QNX 6.4.1 sdk and copied the 6.3.2 sdk directory from another PC. I renamed the 6.4 sdk directory (D
:\qnxsdk\qnxsdk6.4-001) to D:\qnxsdk\qnxsdk6.4-001_actual) and renamed the 6.3.2 sdk directory to D:\qnxsdk\qnxsdk6.4-
001 so that I could build with 6.3.2 rather than 6.4. All environment variables remain the same, as installed for 6.4.1
.
>
> With 6.3.2 sdk in use, there is no problem with the indexer while using IDE 4.6.1. I can highlight a header file and
select "Open Declaration" or hold down the ctrl key and press the link. It also works with variables and function names
.
>
> Based on these results, it appears to be a problem with the 6.4.1 sdk. I installed only qnxsdp-6.4.1-200905201802-
win32.exe on my PC. Do I need any other files?
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post39470
>
|
|
|
|
|
|
Rex Lam
10/07/2009 5:35 PM
post39560
|
Christian,
I followed your steps, but I still have the unresolved inclusion problem. Do you mind zipping up the IndexTest project
along with your workspace so that I could load it and try please? I am not sure what could be wrong with my environment
. I tried everything I could think of, but it just doesn't work.
I was also wrong about this working when I had 6.3.2 in place of 6.4.1. It worked a little better - more files were
indexed correctly, but most files were not indexed. I have rebuilt all projects in my workspace after a clean. No
change in the results.
By the way, my Windows host is Windows 7. I don't know if this has anything to do with the problem or not. Is there
any configuration I could modify to debug this further? Is there a verbose mode for troubleshooting the indexer?
Rex
|
|
|
|
|
|
Rex Lam
10/08/2009 9:17 PM
post39651
|
Christian,
I found out what the problem was. My .cproject file did not have the correct settings for pathentry. This is what it
used to be:
<storageModule moduleId="org.eclipse.cdt.core.pathentry"/>
After I changed it to this:
<storageModule moduleId="org.eclipse.cdt.core.pathentry">
<pathentry kind="src" path=""/>
<pathentry kind="out" path=""/>
<pathentry kind="con" path="com.qnx.tools.ide.qde.QDE_PROJECT_CONTAINER"/>
</storageModule>
the unresolved inclusion problem was fixed. I also found that the following helped on some other projects:
<pathentry include="./src" kind="inc" path="" system="true"/>
<pathentry include="./inc" kind="inc" path="" system="true"/>
It doesn't appear to work in all cases with relative paths though as this fails:
<pathentry include="../../XOSLib/XOS/inc" kind="inc" path="" system="true"/>
but it works if I specify the full path:
<pathentry include="/Development/projects/AVP/XOSLib/XOS/inc" kind="inc" path="" system="true"/>
It would be better to be able to specify relative paths, but I'm happy that it works right now.
Thank you for your help with this problem.
Rex
|
|
|
|
|
|
Christian Damus(deleted)
10/09/2009 9:10 AM
post39662
|
Hi, Rex,
Good work! I'm sorry that I wasn't of much help to you ... the black
magic of path entry containers is something I am just now learning for
another purpose.
The path entry container that you have restored (it should always be
present in QNX projects; I'm interested to know how it was lost, whether
that was a compare/merge problem or what) discovers include paths by
running a "make" on the project to introspect the INCVPATHS variable
defined by the recursive makefiles infrastructure. So, if you add extra
include paths in the "Compiler" settings of your project, they should be
recorded as EXTRA_INCVPATHS in the common.mk and thus be picked up by
the path entry container. If you preface your extra includes with
$(PROJECT_ROOT), then you should be able to make relative references,
thus:
$(PROJECT_ROOT)/../../XOSLib/XOS/inc
Naturally, I would suggest not editing the .cproject file
"directly" (except that you need to in order to repair it as you have
done) but working with the project properties dialog to add extra
includes. Presumably they need to be in the makefile, anyway, for the
build to work. :-)
I am still concerned by how the .cproject file was corrupted in the
first place. If you see that again, do report it!
Cheers,
Christian
On Thu, 2009-10-08 at 21:17 -0400, Rex Lam wrote:
> Christian,
>
> I found out what the problem was. My .cproject file did not have the correct settings for pathentry. This is what it
used to be:
> <storageModule moduleId="org.eclipse.cdt.core.pathentry"/>
>
> After I changed it to this:
> <storageModule moduleId="org.eclipse.cdt.core.pathentry">
> <pathentry kind="src" path=""/>
> <pathentry kind="out" path=""/>
> <pathentry kind="con" path="com.qnx.tools.ide.qde.QDE_PROJECT_CONTAINER"/>
> </storageModule>
>
> the unresolved inclusion problem was fixed. I also found that the following helped on some other projects:
> <pathentry include="./src" kind="inc" path="" system="true"/>
> <pathentry include="./inc" kind="inc" path="" system="true"/>
>
> It doesn't appear to work in all cases with relative paths though as this fails:
> <pathentry include="../../XOSLib/XOS/inc" kind="inc" path="" system="true"/>
>
> but it works if I specify the full path:
> <pathentry include="/Development/projects/AVP/XOSLib/XOS/inc" kind="inc" path="" system="true"/>
>
> It would be better to be able to specify relative paths, but I'm happy that it works right now.
>
> Thank you for your help with this problem.
>
> Rex
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post39651
>
________________________________________________________________________
Christian W. Damus
Software Developer, IDE Team
QNX Software Systems
|
|
|
|
|
|
Mario Charest
10/09/2009 9:14 AM
post39664
|
I found the .cproject REALLY easy to corrupt if for example you go in the SNV synchronize view and do an update. If
somebody else change something in the project most of the time your .cprojet gets screwed up.
> -----Original Message-----
> From: Christian Damus [mailto:community-noreply@qnx.com]
> Sent: October 9, 2009 9:10 AM
> To: general-ide
> Subject: Re: Unresolved inclusion
>
> Hi, Rex,
>
> Good work! I'm sorry that I wasn't of much help to you ... the black
> magic of path entry containers is something I am just now learning for
> another purpose.
>
> The path entry container that you have restored (it should always be
> present in QNX projects; I'm interested to know how it was lost,
> whether
> that was a compare/merge problem or what) discovers include paths by
> running a "make" on the project to introspect the INCVPATHS variable
> defined by the recursive makefiles infrastructure. So, if you add
> extra
> include paths in the "Compiler" settings of your project, they should
> be
> recorded as EXTRA_INCVPATHS in the common.mk and thus be picked up by
> the path entry container. If you preface your extra includes with
> $(PROJECT_ROOT), then you should be able to make relative references,
> thus:
>
> $(PROJECT_ROOT)/../../XOSLib/XOS/inc
>
> Naturally, I would suggest not editing the .cproject file
> "directly" (except that you need to in order to repair it as you have
> done) but working with the project properties dialog to add extra
> includes. Presumably they need to be in the makefile, anyway, for the
> build to work. :-)
>
> I am still concerned by how the .cproject file was corrupted in the
> first place. If you see that again, do report it!
>
> Cheers,
>
> Christian
>
>
> On Thu, 2009-10-08 at 21:17 -0400, Rex Lam wrote:
>
> > Christian,
> >
> > I found out what the problem was. My .cproject file did not have the
> correct settings for pathentry. This is what it used to be:
> > <storageModule moduleId="org.eclipse.cdt.core.pathentry"/>
> >
> > After I changed it to this:
> > <storageModule moduleId="org.eclipse.cdt.core.pathentry">
> > <pathentry kind="src" path=""/>
> > <pathentry kind="out" path=""/>
> > <pathentry kind="con"
> path="com.qnx.tools.ide.qde.QDE_PROJECT_CONTAINER"/>
> > </storageModule>
> >
> > the unresolved inclusion problem was fixed. I also found that the
> following helped on some other projects:
> > <pathentry include="./src" kind="inc" path="" system="true"/>
> > <pathentry include="./inc" kind="inc" path="" system="true"/>
> >
> > It doesn't appear to work in all cases with relative paths though as
> this fails:
> > <pathentry include="../../XOSLib/XOS/inc" kind="inc" path=""
> system="true"/>
> >
> > but it works if I specify the full path:
> > <pathentry include="/Development/projects/AVP/XOSLib/XOS/inc"
> kind="inc" path="" system="true"/>
> >
> > It would be better to be able to specify relative paths, but I'm
> happy that it works right now.
> >
> > Thank you for your help with this problem.
> >
> > Rex
> >
> >
> >
> > _______________________________________________
> >
> > General
> > http://community.qnx.com/sf/go/post39651
> >
>
>
> _______________________________________________________________________
> _
>
> Christian W. Damus
> Software Developer, IDE Team
> QNX Software Systems
>
>
>
>
> _______________________________________________
>
> General
>...
|
|
|
|
|
|
Rex Lam
10/09/2009 2:16 PM
post39700
|
Christian,
The .cproject files were missing the path entries because my director was seeing a lot of warnings after projects have
been imported. The warnings were something like "Duplicate pathentry". I don't see the same warnings on my PC though.
He deleted those lines and left just this line:
<storageModule moduleId="org.eclipse.cdt.core.pathentry" />
The "duplicate" warnings went away after he did that, so he thought it was not needed.
After I modified the .cproject files last night, several other people saw this warning in their IDE. I am going to run
more tests to figure out which lines I should keep and which lines to remove.
The following lines still produce a duplicate pathentry warning in my director's IDE:
<storageModule moduleId="org.eclipse.cdt.core.pathentry">
<pathentry kind="src" path=""/>
<pathentry kind="out" path=""/>
<pathentry kind="con" path="com.qnx.tools.ide.qde.QDE_PROJECT_CONTAINER"/>
</storageModule>
Initially I though the <pathentry include ...> lines caused the duplicate warnings, but there is more to it. Maybe he
has to reimport all projects again after removing the pathentry include lines from all projects, which he had not done
yet.
One question that we had is, shouldn't the IDE automatically update these lines if they are incorrect? Is there
anything we can do to let the IDE regenerate these lines? The "IndexTest" example I sent you also had this problem.
How were you able to import it and get the inclusions resolved without modifying the .cproject file? Did the IDE modify
it for you or did you create your own .cproject file?
Rex
|
|
|
|
|
|
