[cdt-dev] Excessive rebuilds, including a Tool.setRebuildState() bug

[Don Porges <dporges@xxxxxxxxxxxxxxx>]

[Yes, this is long.]

I’m intending to file a bug on an apparent error in
org.eclipse.cdt.managedbuilder.internal.core.Tool. setRebuildState() and its
interaction with the same class’s saveRebuildState(), but I’d like to
reconstruct my investigation here because it bumps up against a few other
troublesome areas.  The original problem was that, in the C projects we have
created here, we are finding recurring instances of projects, and
depended-on projects, rebuilding their entire generated directory
unnecessarily, and sometimes rebuilding the wrong configurations of some of
the dependees, usually in addition to rebuilding the right one.  The problem
seemed to come and go for mysterious reasons.  I should admit that we’re
using a custom plugin for a non-GNU cross-compiler for our processor, but
I’ve been able to show what I believe to be the same problems in Cygwin GCC
projects, although it’s always possible that something I’ve done wrong in
our plugin is aggravating the problem.

First, here’s the bug.  The code in …Tool.setRebuildState(), when it’s
directed to set the rebuildState to false, does a saveRebuildState() early
on, then walks its children (Options) and sets each their rebuild states to
false.  But look what’s in saveRebuildState():

PropertyManager.getInstance().setProperty(this, REBUILD_STATE,
Boolean.toString(needsRebuild()));

Note the call to needsRebuild().  This routine walks all of the Tool’s
children and re-deduces whether the Tool is in rebuildState.  But since it’s
being called before the outer routine clears all of the children, if any of
the children are in rebuildState, it saves “true” as the tool’s saved
Property, which isn’t what we want in this case.  Moving the
saveRebuildState() call in setRebuildState to after the setting of the child
Options fixes this. (Changing saveRebuildState() to use the current
rebuildState would also work here, but seems more dangerous.) This Property
doesn’t seem to matter until after Eclipse is shut down and restarted, at
which time it reads that property, marks the Tool and thus its ToolChain and
Configuration as needsRebuild, and it gets blown away and everything in it
remade. (Subsequent builds during the same Eclipse session do not do the
full rebuild of the dependee; they just invoke a "make all" that finds
nothing to do, which is the desired result.)

Now:  for several reasons, all of this doesn’t matter to many other CDT
users.  For one thing, for a top-level build, the whole Project gets
“serialized” after the build, which happens to do a saveRebuildstate()
itself; by this time, the children have indeed had their rebuildState
cleared, so it’s ok.  But if the configuration is, instead of a top-level
build, a depended-on project – but ONLY depended-on through the C/C++
Settings, not through the non-C “Project References” panel – this later
serialization does not happen.  If you do a top-level build of the dependee,
the serialization happens, and then the problem magically and mysteriously
goes away.  Using the non-C/C++ Project References panel causes the wrong
configuration of the dependee to be rebuilt – it’s either the current active
configuration or something called the “base” configuration, I’m fuzzy on
that.  But it’s not what we want, and so we’ve been carefully unchecking
those boxes in favor of the C/C++ Settings version, which can refer to a
particular configuration.

Another factor is that the Options are only marked dirty, on creation of the
entire project at Eclipse startup,  if they are “extensions”, that is,
copied from the configuration in the plugin itself.  Occasionally, I think
something happens that makes all the Options concrete in the actual
.cproject, and, for this reason also, the problem goes away.  Furthermore,
in many use cases, the users have been creating the settings through the
setting panels, which also results in the actual options settings being
emitted into the .cproject, and in that case you don’t have this problem. 
But many of our projects are in fact generated as xml by a script that
converted some projects from another IDE we used to use, and those converted
projects didn’t necessarily have all of the options made explicit.  And new
projects -- such as the HelloWorld projects -- don't have all the Options in
the .cproject.

Oh, and I’m convinced that once in a while, the non-C/C++ Project Reference
boxes get re-checked, based on the C/C++ Settings incarnations.  But not
regularly enough for me to find out why.

Anyway…I’d like to file the bug mentioned above, with the proposed fix in
setRebuildState(), but you can see that the bug case is not straightforward,
and I wanted to know if anyone had anything to add before I actually file
the bug.  I can get the bug case by creating two hello-world projects and
having one depend on a config of the other.
-- 
View this message in context: http://www.nabble.com/Excessive-rebuilds%2C-including-a-Tool.setRebuildState%28%29-bug-tp16207032p16207032.html
Sent from the Eclipse CDT - Development mailing list archive at Nabble.com.