Community
Participate
Working Groups
1. Create a Hello World C++ Makefile Project 2. Remember file size of scanner config file <workspace>/.metadata/.plugins/org.eclipse.cdt.make.core/hello.sc 3. Close/reopen Eclipse 4. Check file size of scanner config file -> it has grown (the increment seems to be its initial size) 5. repeat 2-4 If I change the discovery profile scope from "Per Language" to "Configuration-wide" the scanner config file does not grow on each restart. Managed build projects are not affected.
I see this problem goes as far back as CDT 5. At least it's not regression. It appears that id of a tool (related to language) changes which makes the context different. Scanner config then is saved in the file which is intended to keep the data for all contexts.
(In reply to comment #1) > I see this problem goes as far back as CDT 5. At least it's not regression. It > appears that id of a tool (related to language) changes which makes the context > different. Scanner config then is saved in the file which is intended to keep > the data for all contexts. I bet this is the cause of the ever-growing .cproject file as well. Presumably you see anew scanner config element for each of these ids in the .cproject XML too?
(In reply to comment #2) > (In reply to comment #1) > > I see this problem goes as far back as CDT 5. At least it's not regression. It > > appears that id of a tool (related to language) changes which makes the > context > > different. Scanner config then is saved in the file which is intended to keep > > the data for all contexts. > I bet this is the cause of the ever-growing .cproject file as well. Presumably > you see anew scanner config element for each of these ids in the .cproject XML > too? Scanner discovery does not keep discovered data in .cproject. Only scanner discovery profiles are stored there (of course even those which are not relevant to the project). My .cproject is small and I do not see any extra growth.
(In reply to comment #3) > Scanner discovery does not keep discovered data in .cproject. Only scanner > discovery profiles are stored there (of course even those which are not > relevant to the project). My .cproject is small and I do not see any extra > growth. I never said it did store discovered data there, and lucky you that it doesn't grow... I see scanner discovery grow and grow with hundreds of these, not sure what sequence of actions triggers it, but they never go away: <scannerConfigBuildInfo instanceId="com.broadcom.cdt.build.target.fpexe.debug.1535098180;com.broadcom.cdt.build.target.fpexe.debug.1535098180.;com.broadcom.cdt.build.tool.gnu.c.compiler.base.187864702;com.broadcom.cdt.build.tool.gnu.c.compiler.inputType.1731076159"> <autodiscovery enabled="true" problemReportingEnabled="true" selectedProfileId="com.broadcom.cdt.build.project.scanner"/> <profile id="com.broadcom.eclipse.cdt.make.core.BroadcomGCCStandardMakePerFileProfile"> <buildOutputProvider> <openAction enabled="true" filePath=""/> <parser enabled="true"/> </buildOutputProvider> <scannerInfoProvider id="makefileGenerator"> <runAction arguments="-f ${project_name}_scd.mk" command="make" useDefault="true"/> <parser enabled="true"/> </scannerInfoProvider> </profile> <profile id="com.broadcom.cdt.build.project.scanner"> <buildOutputProvider> <openAction enabled="true" filePath=""/> <parser enabled="true"/> </buildOutputProvider> <scannerInfoProvider id="specsFile"> <runAction arguments="-E -P -v -dD ${plugin_state_location}/specs.c" command="firepath-elf-gcc" useDefault="true"/> <parser enabled="true"/> </scannerInfoProvider> </profile> <profile id="org.eclipse.cdt.make.core.GCCStandardMakePerProjectProfile"> <buildOutputProvider> <openAction enabled="true" filePath=""/> <parser enabled="true"/> </buildOutputProvider> <scannerInfoProvider id="specsFile"> <runAction arguments="-E -P -v -dD ${plugin_state_location}/${specs_file}" command="gcc" useDefault="true"/> <parser enabled="true"/> </scannerInfoProvider> </profile> .......... see also bug 199209 comment 4. I've seen .cprojects with 60,000 'profile's' like this. Looking at the comment there creating resource descriptions is enough to do it with per-language rather than per-configuration set.
