Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 316693

Summary: Scanner info request should be passed to scanner discovery
Product: [Tools] CDT Reporter: Doug Schaefer <cdtdoug>
Component: cdt-buildAssignee: cdt-build-inbox <cdt-build-inbox>
Status: NEW --- QA Contact: Jonah Graham <jonah>
Severity: normal    
Priority: P3    
Version: 7.0   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:

Description Doug Schaefer CLA 2010-06-12 20:11:17 EDT 
I was just thinking about scanner discovery and how the project model is caching the info, somewhat replicating the caching scanner discovery already does.

When the CDT parsers ask for scanner info, the project model intercepts the request and returns what it has cached.

I wonder if it should pass on the request to the scanner discovery profile (which I believe it used to before the project model came along). What do people think?

The use case I was thinking was for per file discovery. If we get a file we know about, we just return the scanner info in the CommandDSC thing. If we get a file we don't know about, we should use heuristics, like return the scanner info for the CommandDSC that has the most resources (making it the most likely answer?). We can't do that now with the project model cache.
Comment 1 Andrew Gvozdev CLA 2010-06-12 21:30:46 EDT 
The project model returns not only scanner discovery entries but also a few others i.e. user entries from Paths&Symbols page, entries from buildDefinitions extension point, ICExternalSetting entries.
Comment 2 Doug Schaefer CLA 2010-06-13 09:55:35 EDT 
(In reply to comment #1)
> The project model returns not only scanner discovery entries but also a few
> others i.e. user entries from Paths&Symbols page, entries from buildDefinitions
> extension point, ICExternalSetting entries.

Ah, good point. I guess my focus is on the discovered path info cache. Maybe there's ways of merging the two. Or have info reach out to the scanner discovery cache instead dyanamically. I just don't like the duplication of information that we have now.