[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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