Community
Participate
Working Groups
Building a project call IScannerInfoConsoleParser.startup() even if nothing changed in the project. On some systems the call g++ -E -P -v -dD specs.cpp takes some seconds.
I was just about to create a bug like that. The problem is that ScannerConfigBuilder is set up as a separate project builder (in properties->Builders) and it is being run on every build event. I think it needs to be configured to be activated on FULL_BUILD event only. Perhaps even that is too often and it should have some additional logic to skip the event if compiler specs were fetched already.
Created attachment 162735 [details] The patch
Committed on HEAD (7.0). This will take effect on new projects. Old projects still can be configured in Project->Properties->Builders->Scanner-Configuration-Builder->Edit. Voodoo by disabling all events except "After a Clean".
(In reply to comment #3) > Committed on HEAD (7.0). This will take effect on new projects. Old projects > still can be configured in > Project->Properties->Builders->Scanner-Configuration-Builder->Edit. Voodoo by > disabling all events except "After a Clean". This may not be the case, but just checking... Does this prevent all scanner info parsing from happening on Incremental build? If so does this mean that scanner discovery won't pick up new paths / symbols if -Is and -Ds are added to the external makefile? Or does this change only affect the discovery of built-ins?
Just tested this change. It looks like scanner info is now only picked up on the first build after a clean. So adding a -D to a makefile, run an incremental build, doesn't cause the discovered defines to be updated.
I have hard time figuring out how that can be. ScannerConfigBuilder is a separate builder running a separate command (to fetch built-in specs). It has no access to regular build output. Regular build output is parsed by BOP parser which is not a builder but mere a line parser which is connected to parse output of CommonBuilder. If you enable all the events in properties, does it start working? Or maybe you use customized scannerInfoProvider?
(In reply to comment #6) > I have hard time figuring out how that can be. ScannerConfigBuilder is a > separate builder running a separate command (to fetch built-in specs). It has > no access to regular build output. Regular build output is parsed by BOP parser > which is not a builder but mere a line parser which is connected to parse > output of CommonBuilder. If you enable all the events in properties, does it > start working? Or maybe you use customized scannerInfoProvider? I'm just trying in my HEAD runtime. (In my product I only use scanner discovery for the built-ins -- I use a DwarfParser for makefile projects...). What I did using a clean head: - Create HelloWorld managed project - Create empty makefile project - Copy the source and Debug directories from the managed project to the makefile project - Change the makefile project build directory to makefileproject/Debug - Build the makefile project - Add some -D's to the makefile, touch hello.c, build. + Before the patch the -Ds are correctly shown in the Symbols page, afterwards they don't seem to be picked up.
(In reply to comment #7) > + Before the patch the -Ds are correctly shown in the Symbols page, > afterwards they don't seem to be picked up. (I had to create a new project to pick up the changed builder as detailed by comment 3). I was under the impression, which could be wrong, that while the BOP runs inline with the make, the paths and symbols are contributed back by the scanner info builder running after the make.
OK, I can see the problem. Let me figure it out.
Created attachment 162840 [details] additional patch (In reply to comment #8) > I was under the impression, which could be wrong, that while the BOP runs inline > with the make, the paths and symbols are contributed back by the scanner info > builder running after the make. You are right. I think that is counter-intuitive and it prevents disabling built-in specs re-discovery on incremental builds. Here is a patch to contribute the entries in CommonBuilder after build output parsing is done.
Is there a good reason for the if in: if (kind == INCREMENTAL_BUILD || kind == FULL_BUILD || kind == AUTO_BUILD) { // Update project model with scanner info ... ? If on CLEAN_BUILD we cleared all the scanner info state, this would fix all those other bugs on not being able to remove builtins... I don't really have any preference as to whether this runs as its own builder or not. But at a first glance the patch looks good to me.
One other question: is the ScannerConfig call in the right place in CommonBuilder? Shouldn't it be in #build(int kind, CfgBuildInfo bInfo, IProgressMonitor monitor) to pick up scanner config on referenced configurations? (In reply to comment #11) > I don't really have any preference as to whether this runs as its own builder > or not. I do now have a preference -- this is a better approach. It looks like ScannerConfigBuilder doesn't run correctly for the configurations which were just built. It updates the settings on the des.getDefaultSettingConfiguration(), which may not be what was built: see CommonBuilder#build(int kind, Map args, IProgressMonitor monitor) :s
(In reply to comment #11) > Is there a good reason for the if in: > if (kind == INCREMENTAL_BUILD || kind == FULL_BUILD || kind == AUTO_BUILD) { > // Update project model with scanner info > If on CLEAN_BUILD we cleared all the scanner info state, this would fix all > those other bugs on not being able to remove builtins... I agree with you and I want to look at that next. It is just that for now ScannerConfigBuilder is not able to do any cleaning and we do not really want to save scanner info collected from clean output. I think we may likely introduce another flag which will instruct ScannerConfigBuilder to clean discovery info and for that we would need to insert in the code if(kind == CLEAN_BUILD) anyway. (In reply to comment #12) > One other question: is the ScannerConfig call in the right place in > CommonBuilder? Shouldn't it be in #build(int kind, CfgBuildInfo bInfo, > IProgressMonitor monitor) to pick up scanner config on referenced > configurations? ScannerConfig saves all scanner info collected before. It was placed in separate builder presumably for efficiency as it persist collected data on disk. If we put it in #build(int kind, CfgBuildInfo bInfo, IProgressMonitor monitor) we place it inside "for" loop. Regarding referenced configurations they are also built via calling #build(int kind, IProject project, IBuilder[] builders, boolean isForeground, IProgressMonitor monitor, MyBoolean isBuild) - where the call is placed - aren't they? > I do now have a preference -- this is a better approach. It looks like > ScannerConfigBuilder doesn't run correctly for the configurations which were > just built. It updates the settings on the des.getDefaultSettingConfiguration(), > which may not be what was built: see CommonBuilder#build(int kind, Map args, > IProgressMonitor monitor) :s Yeah, I thought that that could be a problem looking at the code too
(In reply to comment #13) > configurations they are also built via calling #build(int kind, IProject > project, IBuilder[] builders, boolean isForeground, IProgressMonitor monitor, > MyBoolean isBuild) - where the call is placed - aren't they? Yes you're right: this function calls itself recursively via buildReferencedConfigs.
OK, I committed second patch on HEAD (7.0) too.
Reopening as Doug backed the change, see bug 313370.
