Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Excessive rebuilds, including a Tool.setRebuildState() bug


Please submit your bug.  The problem seems to be actual. 

By the way, it seems like "saveRebuildState()" is not required at all in
Reason: possible inconsistency when some changes were made in project,
and then
discarded ("setProjectDescription()" not called). Anyway, problem should
be additionally

One more question. Could you please explain your phrase more detailly:
> we are finding recurring instances of projects

With best regards, Oleg Krasilnikov


-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Don Porges
Sent: Friday, March 21, 2008 11:08 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Excessive rebuilds, including a
Tool.setRebuildState() bug

[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,

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
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

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

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:
Sent from the Eclipse CDT - Development mailing list archive at

cdt-dev mailing list

Closed Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park, 
17 Krylatskaya Str., Bldg 4, Moscow 121614, 
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Back to the top