Hi, Chris,

No need to apologize.  That was just FYI.  I don't know that the thread can be "moved"; I wouldn't worry about that.

Yes, I think the the managed builder tries to integrate the settings from the Paths and Symbols page, but for myself, I 
try to consistently configure managed projects using the managed build settings.  Just in case, and because it's all 
accessible on the one page.

Discovery is intended to find the implicit include paths that are built into the toolchain, in this case QCC.  It is 
only needed by the CDT indexing subsystem, editors, and whatever else besides build that needs this information.  Build 
doesn't need it because the toolchain already knows these paths.  So, discovery does not push the paths and symbols that
 it finds into the project settings for the user to see them (although they are visible in some pages when you toggle 
the "show system" or "show built-in" buttons).

Discovery is always run on the creation of a new project, so this is why you see the system headers at the outset.  They
 should never then disappear.

The yellow folders in the Includes virtual folder denote external directories (not in the workspace).  The blue folders 
donate workspace projects and folders.

The .sc files should be re-built when you build the project (it is implemented as a Project Builder named "Scanner 
Discovery Builder" in the project settings, per the Eclipse Platform project builder framework).  They are also re-built
 whenever you change the discovery settings.  But, as I mentioned, they are always cumulative, so for a clean re-
calculation you have to delete the file.

Would you be able to craft a sample project that demonstrates the problem you are seeing, and attach it to a post?  At 
this point, I think I need to see it in action to get a better sense of how to resolve the situation.

Cheers,

Christian


On 15/04/10 09:57 AM, Chris Trobridge wrote: 

	My apologies!
	
	I saw the IDE forum after.  I classified this as CDT related, and the forum is labelled Core Development Tools, which 
obviously isn't quite the same CDT.
	
	Can you move the thread?
	
	I think I need to re-think this a little.
	
	If Discovery is to allow the IDE to determine the include paths used by the build then this seems a little circular in 
a managed build.  In a managed build the IDE property pages are determining the directories used in the build, hence the
 IDE already knows theses.
	
	It might manage to discover the system headers, however, these files are inserted by the QNX toolchain at the project 
creation - so the system headers do not appear to be being added by the discovery process.
	
	Discovery would appear to be more suitable for an externally managed makefile?
	
	"I suggest for Managed Make projects not to add include directories using the Paths and Symbols project properties page
, but rather using the "C/C++ Build -> Settings" page.  This is where the configuration parameters for the managed build
, among them include paths, are set.  The managed builder "pushes" some of these settings to other parts of the CDT 
system."
	
	Actually the paths from the "Paths and Symbols" page are pushed into the "C/C++ Build/Settings" page.  But I haven done
 as you say and the project include paths are still discovered.
	
	Still no system includes though.
	
	Another difference is (on a new project) the QNX "Includes" entries have a yellow bottom, rather than a blue one and 
the QNX entries can be opened to reveal their contents - while the project "Includes" entries can't.
	
	(I've also set my Discovery options back to the same as a new project - Configuration-wide, Automate discovery, Report 
problems,  Regular make - per project scanning and enable build output scanner info discovery etc.
	
	I deleted the .sc files and they don't seem to be rebuilt all the time, but when I did I got the following in it:
	<collector...