[platform-core-dev] Build questions

[Alex Chapiro <achapiro@xxxxxxx>]

I tried to ask this questions in eclipse.platform newsgroup, but I 
didn't get any response. Probably it was a wrong place for that, so I'm 
trying to repeat these questions in this mailing list. Sorry if it is 
also an inappropriate place.

I'm trying to migrate Eclipse2-compatible code to Eclipse3. I don't 
understand some ideas used in build manager implementation. Actually 
there are two main issues.
1) The role of the CLEAN_BUILD mode. As it works now, if I run builder 
using this mode, it inevitably changes project state (cleans build 
history) so that next INCREMENTAL_BUILD will be switched to FULL_BUILD. 
Maybe it is convenient for Java builder, but not for the build systems 
(I'm talking now about the make-based) that have their own dependency 
control. For example right now in case of CDT make builder raising of 
Clean command causes invocation of CDT make builder twice : once with 
CLEAN_BUILD which usually cause removing of all object files, and then 
FULL_BUILD which is interpreted as cleaning and building. Of course, I 
can change interpretation of FULL_BUILD and consider it always to be 
equal to INCREMENTAL_BUILD:-)) Another evident work around for this 
issue is just to ignore CLEAN_BUILD. However as any illogical solution, 
it is far from perfect.

2) If for some reasons I'd like to clear project build history 
(forgetLastBuildState), next build in INCREMENTAL_BUILD mode will be 
automatically changed to FULL_BUILD mode. This is also prohibit 
dependency control from any builder implementation . In my case it looks 
like that:
- I have two builder attached to my class of projects. The first one is 
responsible for dependency checking, the second one is a real builder. 
To let the first one to do its work, I have to clear history before its 
invocation, otherwise build manager just does not run it. If after the 
first step there are some reasons for launching  of real building, it 
will be always called in FULL_BUILD mode - the same story as for 
CLEAN_BUILD case.

The main problem is that code that determines this behavior is 
concentrated in BuildManager and so is out of control by solution 
vendor. It seems to me to be too rigorous restriction on any builder 
implementation.

I'm blaming in my troubles the following lines of code from 
BuildManager.basicBuild(...) method:

lastBuiltTree = currentBuilder.getLastBuiltTree();
// If no tree is available we have to do a full build
if (!clean && lastBuiltTree == null)
  trigger = IncrementalProjectBuilder.FULL_BUILD;

in case 1) lastBuildTree is always null after CLEAN_BUILD (see below in 
the same method:
if (clean || currentBuilder.wasForgetStateRequested()) {
   currentBuilder.setLastBuiltTree(null);

In case 2) lastBuildTree is null after forgetLastBuildState calling.

Build manager should provide framework for other builders 
implementations. I don't understand why it instead of being transparent 
for user commands implements some hidden undocumented and unmodifiable 
behavior.
Of course I realize that maybe I provide a wrong interpretation. I'd be 
happy if either I will be corrected or any work around will be advised.

Sorry for the long and messy explanation of the problem.

Thanks.