| Re: [cdt-dev] What use cases does PDOMDependencyCalculator solve? |
Never got any inputs to that question... but I'd like to share some more insights from my side.
In order to speed-up things (see previous post), I patched CDT so that it does *not use PDOMDependencyCalculator* during build. Therefore, I changed the following line:
--- a/build/org.eclipse.cdt.managedbuilder.core/src/org/eclipse/cdt/managedbuilder/internal/core/CommonBuilder.java
+++ b/build/org.eclipse.cdt.managedbuilder.core/src/org/eclipse/cdt/managedbuilder/internal/core/CommonBuilder.java
@@ -952,7 +952,7 @@
//use a build desacription model to calculate the resources to be cleaned
//only in case there are some changes to the project sources or build information
try{
- int flags = BuildDescriptionManager.REBUILD | BuildDescriptionManager.DEPFILES | BuildDescriptionManager.DEPS;
+ int flags = BuildDescriptionManager.REBUILD | BuildDescriptionManager.DEPFILES;
if(delta != null)
flags |= BuildDescriptionManager.REMOVED;
This brought the enormous speed up described in the previous mail.
Unfortunately, today I realized that this causes the following problem: Changing a header file which is included by multiple .cpp (or .c) files does not cause to recompile all these .cpp files (although sometimes it works - don't know yet why). As this problem first occurred after having applied the patch above, I assume that it is that patch causing the issue. (Because this issue is occurring randomly, I'm not 100% sure whether it was already there before).
However, IMHO gnu make should be responsible to build the right .cpp files after changing a .h thanks to the .d files. Therefore, I checked the .d files and encountered that they are buggy: They did not contain a dependency for the .o file to the header files... then I found https://bugs.eclipse.org/bugs/show_bug.cgi?id=391735. Applying that patch immediately fixed the issue. So I right now have the above patch (fixing speed issues) and the 391735 patch (fixing dependency file generation) applied and things seem to work properly again.
Therefore, again: Does anyone know why BuildDescriptionManager.DEPS is being passed for building gnu make based projects and thus PDOMDependencyCalculator is being used to create a dependency hierarchy within CDT? Don't we have gnu make for handling such dependencies?
I currently think we could get rid of BuildDescriptionManager.DEPS in the context of building gnu make based projects once we fixed https://bugs.eclipse.org/bugs/show_bug.cgi?id=391735 and thereby massively improve CDT build performance!
Any thoughts?
On 08/09/2013 08:58 AM, Raphael Zulliger wrote:
In a customers project, they encounter intolerable long times between "project build" invocation and the execution start of "make" which takes more than minutes on some (Windows) systems. This time is consumed during "build configuration" creation. A considerable amount of time is spent in findTypeForExtension called by BuildDescription.completeLinking.
What massively speeds up things (actually fixes the issue) is to avoid PDOMDependencyCalculator being used (e.g. by disabling indexer or by patching the code accordingly). Right now, I'm thinking about patching CDT for our customers to disable PDOMDependencyCalculator - but first I'd like to understood what the purpose of that class acutally is, means: what "real life problem" it solves. While it's obvious that it adds all dependencies (i.e. included headers) to a certain .cpp, it's not obvious to me why this is required for CDT to know. Don't we use make and .d files to generate and handle such dependencies? (note: I'm aware of https://bugs.eclipse.org/bugs/show_bug.cgi?id=108715, which discusses some possible make pitfalls - but I think those are not related to this issue, are they?)
Thanks,
Raphael
_______________________________________________
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