Community
Participate
Working Groups
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.
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.
(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.
