Re: [cdt-dev] FYI, merged in a bunch of changes

[Chris Recoskie <recoskie@xxxxxxxxxx>]

Changes were posted/discussed here https://bugs.eclipse.org/bugs/show_bug.cgi?id=288545

>From what I recall (it's been a while), deleting the info removes it from the cache. When next the scanner info is asked for, the system sees that it's not in the cache, and creates it again.

That change does not solve everything, but if I recall, it did cut down the number of times scanner discovery got run in some situations by a factor of about 2, so it's an improvement.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

Andrew Gvozdev ---05/13/2010 11:12:03 PM---Chris, There is one change I'd like to clarify. In ScannerConfigBuilder you

From:	Andrew Gvozdev <angvoz.dev@xxxxxxxxx>
To:	"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date:	05/13/2010 11:12 PM
Subject:	Re: [cdt-dev] FYI, merged in a bunch of changes
Sent by:	cdt-dev-bounces@xxxxxxxxxxx

---

Chris,
There is one change I'd like to clarify. In ScannerConfigBuilder you commented out removal of discovered info:

            // update and persist scanner configuration
            CfgSCJobsUtil.updateScannerConfiguration(project, context, instance, buildInfo2, new SubProgressMonitor(monitor, 30));
            
            // this erroneously removes the infor right after it gets created... bad
            //CfgDiscoveredPathManager.getInstance().removeDiscoveredInfo(project, context, false);

If was my understanding that this info is being removed to avoid being accumulated every time when FULL_BUILD is performed. This information has been saved on the line right before that. What is the reason to commenting this line out? It seems to be added deliberately in version 1.2.

And what is the bugzilla for those changes in scanner discovery?

Thanks,
Andrew


On Tue, May 11, 2010 at 6:55 PM, Chris Recoskie <recoskie@xxxxxxxxxx> wrote:

- Merged changes from cdt_5_0 to HEAD. Too many to mention individually.
- Reworked IFileSystem utility so that now it is noimplement/noextend. Clients should now extend from concrete class FileSystemUtility instead to better insulate them from future API changes.
- Reworked the resulting concurrency fixes - indexing and scanner discovery now synchronize on the project root as a scheduling rule. Original HEAD behaviour was to synch on the project's .settings folder for indexing, but that deadlocked with scanner discovery. James, you will probably want to take a look at what I did there and make sure you are comfortable with it, as I know you have been trying to relax the scheduling rules as much as possible. If you think it needs some rework let me know.
- Fixed remote indexing. Changes on HEAD that deprecated CodeReader broke the ability for remote translation units to provide the path to load the file content from. Added API to ITranslationUnit for this purpose.

The tests all pass, but let me know if you run into any problems, particularly if you encounter any concurrency issues.

FYI error parsing seems broken for remote projects. I intend to start looking into that tomorrow.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev