Community
Participate
Working Groups
In case a C/C++ CDT managed build project has been imported from a shared source folder (like a git repo) in more than one workspace AND it has been opened in more than one workspace at the same time, the indexer in the workspaces re-trigger each other. This circular re-triggering can be terminated only by closing all projects except for one. I made some investigation in the CDT code base. It seems that the re-triggering is caused by changes in two files located in the projects folder: .cproject and .settings/language.settings.xml A hash value in the language.settings.xml file ensures that the indexer can detect when the used compiler changes. The hash value is made of the environment variable PATH, the compiler command string, the file path to the used compiler and the language.settings.xml's timestamp. Unfortunately the compiler command string has a dependency to the workspace: This file path is included: C:/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C This dependency to the workspace specific file and the timestamp of the modified file causes the re-trigger of the indexer in other workspaces: The language.settings.xml file will be (re-)written after a change has been detected and the "new" environment settings has been loaded into cache. This load triggers a ILanguageSettingsChangeEvent. One of the listeners is org.eclipse.cdt.internal.core.pdom.LanguageSettingsChangeListener.handleEvent(ILanguageSettingsChangeEvent). The call of redindex in that method causes a new indexer job (PDOMUpdateTask) in the indexer queue. The other workspaces detecting the modified hash in the language.settings.xml file and we are in circle... Similar problem with .cproject file. In case the timestamp of this file changes, the cached CProjectDescription is cleared an reloaded from the possibly externally modified file. This will be detected, because every translation unit during indexing runs TranslationUnit.getScannerInfo. The change will be detected by a sub-sub routine call of XmlProjectDescription.getModificationStamp(IResource). The reload of .cproject causes a write of the .cproject file and a ILanguageSettingsChangeEvent as well. And the event triggers the start of a new queued indexing job (PDOMUpdateTask). The other workspaces will detect the modified timestamp of .project and we have the next circular dependency... The usage of a git project in several workspaces can be questionable, but it should not lead to this behavior of the indexer. As long as there is no support of git-worktree in Eclipse (see bug 477475), the simultaneous work on a git repo in several workspaces is not possible with Eclipse CDT. Has anybody a better approach? Ideas welcome!
Hi Erik, > The usage of a git project in several workspaces can be questionable :-) yes ... > but it should not lead to this behavior of the indexer. correct - lets see what we can do about that. 1. hash: This seems similar to other issues reported in the past that some settings should not be stored in the project directory at all - and I suspect this hash is a perfect example. The hash itself should probably be persisted in the workspace rather than in the xml file in the project. If it were persisted that way I suspect the problem goes away. This also would solve the problem of different users sharing a project which will generate different hashes too. .cproject: the write can implement a compare new contents before write to avoid writes of the same content. We have implemented similar solutions for other places in the past - e.g. Bug 520245 Would you like to tackle this bug? I can provide support to get your contribution reviewed and adopted. Thanks for the report, Jonah
