Community
Participate
Working Groups
If I create a hello world program that includes a standard header, I get "Unresolved inclusion" warning mark on it. What's the reason that CDT issues a warning even for a standard header such as <stdio.h>? I understand the warning can be eliminated by adding Include directories under "Pasths and Symbols". But I would think /usr/include should be added there by default.
(In reply to comment #0) > If I create a hello world program that includes a standard header, I get > "Unresolved inclusion" warning mark on it. > What's the reason that CDT issues a warning even for a standard header such as > <stdio.h>? > I understand the warning can be eliminated by adding Include directories under > "Pasths and Symbols". But I would think /usr/include should be added there by > default. > I am also facing this issue Unresolved inclusion: <assert.h> and many other C++ header files please let me know what to do, how to resolve this issue Thanks
(In reply to comment #1) > (In reply to comment #0) > > If I create a hello world program that includes a standard header, I get > > "Unresolved inclusion" warning mark on it. > > What's the reason that CDT issues a warning even for a standard header such as > > <stdio.h>? > > I understand the warning can be eliminated by adding Include directories under > > "Pasths and Symbols". But I would think /usr/include should be added there by > > default. > > > > I am also facing this issue > > Unresolved inclusion: <assert.h> and many other C++ header files please let me > know what to do, how to resolve this issue > > Thanks > I am also facing this issue Unresolved inclusion: <assert.h> and many other C++ header files please let me know what to do, how to resolve this issue. I already included \usr\include for every workspace. c/c++ include path & symbols still the error persists Thanks
I may have had an unclean environment(?). I'm not seeing this issue with a freshly installed ganymede. I'll let you know if I have a further issue.
I've found that this problem only appears with our integration installed if I have the StandarMakePerFileProfile as part of .c and .cpp tool inputTypes, i.e. <tool outputFlag="-c -o" ...(etc.etc.) <inputType sourceContentType="org.eclipse.cdt.core.cSource" sources="c" scannerConfigDiscoveryProfileId="com.intel.compiler.cdt.managedbuilder.ui.ICCManagedMakePerProjectProfile|com.intel.compiler.cdt.make.core.ICCStandardMakePerFileProfile" .. (etc.etc.) (or alternatively scannerConfigDiscoveryProfileId="com.intel.compiler.cdt.make.core.ICCStandardMakePerFileProfile") I tried with CDT4 and saw the same problem so it's not new to CDT5+. What I don't understand is that I see that gnu plugin.xml (org.eclipse.cdt.managedbuilder.gnu.ui/plugin.xml) virtually the same, i.e. <inputType sourceContentType="org.eclipse.cdt.core.cSource" sources="c" scannerConfigDiscoveryProfileId="org.eclipse.cdt.managedbuilder.core.GCCManagedMakePerProjectProfileC|org.eclipse.cdt.make.core.GCCStandardMakePerFileProfile" .. and CDT doesn't have a problem discoverying include paths.
OK. The problem magically seems to disappear if I use scannerConfigDiscoveryProfileId="com.intel.compiler.cdt.managedbuilder.ui.ICCManagedMakePerProjectProfile|com.intel.compiler.cdt.make.core.ICCStandardMakePerFileProfile" only with cSource and leave it as scannerConfigDiscoveryProfileId="com.intel.compiler.cdt.managedbuilder.ui.ICCManagedMakePerProjectProfile" with cxxSource. That's what gnu really does.., i.e. it only supports perFile with c projects and not with cpp. Now the question is why. I changed the Bugzilla title.
I think if you are working with multi-language project (C + C++ is one of such cases), only Per Language scope makes sense. This one expect per file scanner profile. What is wrong now is that Discovery dialog offers both. I know aboout that. About your last comment. Preparing patch we were limited with requirement do not change API. That's why definition of more than oe profile per input done using such an ugly ay. I'd prefer to change extension point description by adding one more attribute to input descriptor. And of course it should be documented. Attached please find an example extracted from our tool chain integration.
Created attachment 127857 [details] profile definition example
The whole scanner discovery system is a mess and is on the top of my list of things to address for CDT 7.
It would be nice if when somebody fixes this disaster, he/she would also hides UI in order not to scare or annoy customers. Many complains about that. People don't understand what is it about and why they should see it . The main priority in any design should be an end user, then support service, and developer should be the last. I'm afraid this component is an example of the opposite approach..
(In reply to comment #9) > It would be nice if when somebody fixes this disaster, he/she would also hides > UI in order not to scare or annoy customers. Many complains about that. People > don't understand what is it about and why they should see it . The main > priority in any design should be an end user, then support service, and > developer should be the last. I'm afraid this component is an example of the > opposite approach.. > Hell, I don't understand it, and I was there :P.
(In reply to comment #6) > I think if you are working with multi-language project (C + C++ is one of such > cases), only Per Language scope makes sense. This one expect per file scanner > profile. What is wrong now is that Discovery dialog offers both. I know aboout that. Alex, why do you think that Per Language scope expects "per file" scanner profile? I see in the code that "per project" is also activated just fine (in CommonBuilder.contributeToConsoleParserList()). BTW there is no "Per Language" scope concept in the code other than in UI (at least I did not see one wandering over the code). There is Toolchain.isRcTypeBasedDiscovery flag which is regarded as configuration property. This one is easy to confuse with "per file" but they have no relation AFAICS. I added both "per project" and "per file" profiles to both UI scopes "Per Language" and "Configuration-wide" as UI scopes are really just different views to choose one "selected" profile. Let me know guys if I got it wrong. I am using deduction method to figure it out and there is much to deduct yet.
