Community
Participate
Working Groups
Scanner discovery to fetch compiler specs is run 6 times when Hello World project is created (well, with autobuild enabled but anyway). 2 times would be understandable (one for C and one for C++) although no *.c files are in the project. Then it runs again and again when the project is built during regular cycle. I change compiler on a given project very rare if ever and don't want unnecessary delays which are noticeable. Anyway, it is not possible to remove/replace the specs it collected on the first run.
I have run into this as well. The problem is all the more compounded when the scanner discovery builds are running remotely. I will be poking into this in the next week or two. Have you found out anything interesting yet?
I am frying bigger fish bug 290631 which is redesign of scanner discovery. Having good progress so far. I will probably look at this issue in order not to repeat that mistake at the same time frame but not for legacy stuff. Feel free to take the bug if you have to fix it for older release.
One thing I noticed is that project model is asking for scanner discovery data when .cproject is persisted which triggers scanner discovery build.
Created attachment 153143 [details] patch that improves the number of invocations on project creation The attached patch reduces the number of invocations on project creation to 2 (from about 6). There was a problem where the discovered data was immediately deleted after creating it, causing it to be recreated again. I have simply removed the delete. I am committing this patch to cdt_5_0 The number of invocations on project open is unchanged. As far as the opening behaviour, what I see is that there are three scanner info context created for my project. The build system walks the input types of the toolchain and adds a context for each one, a context consisting of a pair of tool and content type. In the typical case, this means one for the C sources content type, one for the C++ sources content type (both paired with the compiler). There is a third context that get created, not paired with a tool, but associated with the project root folder. I am not sure if it is really supposed to be there or not. Anyway, the scanner discovery builder will build the scanner info for every context that it has. This means that as intended, there should be three builds. However, after all three contexts are built, they are built again when something else tries to read the discovered data. I am not fully sure why the second build happens. At that point the data should be cached and just looked up. I have a theory that the caching may be broken due to incorrect nested implementations of equals() and hashcode() in the build model. The context objects refer to build objects such as the toolchain, and if at any point in the hierarchy of objects that are referred by that in the nested equals() and hashcode() calls doesn't come out the way it should, then that will break the caching, as the cache is just a hashmap. This would explain the second build, as the system thinks there is no info for the context, and creates it again. I took a stab at implementing equals() and hashcode() for the contexts, but it didn't seem to help. I'm not sure if there were problems in equals() and hashcode() for other nested objects that was screwing things up though. I will try to dig some more when I get time.
I fixed another side of the puzzle in bug 306708. I think you can port that idea to 5.0 by checking and filtering out all events except FULL_BUILD in ScannerConfigBuilder.build() which overrides IncrementalProjectBuilder.build(). I still think that it is being called too often, and I tend to think that spawning scanner discovery build inside setProjectDescription() is plain wrong.
