RE: [platform-core-dev] Build questions

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

To clarify, this behaviour was added
in Eclipse 3.0 intentionally. There is no longer a trigger in the UI for
FULL_BUILD to be kicked off. Without the line of code mentioned, it would
no longer be possible to induce a FULL_BUILD. The first build after a CLEAN_BUILD
would have been an incremental build (either auto or not), but with a null
resource delta. Although it has always been specified that null deltas
can occur, we discovered that in practice many builders were not handling
it properly. Thus, when the delta is null, a FULL_BUILD now occurs. Without
a delta, it is impossible to perform a correct incremental build anyway.

I acknowledge that the Eclipse build
infrastructure is designed for builders that can perform incremental compilation.
Builders that don't care about project deltas, but just want builders with
varying types of triggers are not well served by the build manager. It
is especially difficult for heterogenous workspaces where some builders
are incremental and others are not. This is discussed for example in:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=60803
--

platform-core-dev-admin@xxxxxxxxxxx wrote on 08/26/2004
04:57:54 PM:

> FYI - This builder behavior also causes problems for me.  It
particular,
> we would like to respond to an AUTO_BUILD request differently than
an
> INCREMENTAL_BUILD or a FULL_BUILD.  However the code that Alex
mentions
> changes the "kind" flag that is passed to my builder.  Therefore
even
> when it is really an AUTO_BUILD, my builder sometimes gets the
> FULL_BUILD flag and therefore performs the wrong operation.  It
would be
> nice if you could leave the decision to change the flag up to each
> builder individually.
> 
>   Jeremiah
> 
> -----Original Message-----
> From: Alex Chapiro [mailto:achapiro@xxxxxxx] 
> Sent: Thursday, July 22, 2004 5:49 PM
> To: platform-core-dev@xxxxxxxxxxx
> Subject: [platform-core-dev] Build questions
> 
> 
> <beginning of message snipped>
> ...
> 
> 
>  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.
> 
> 
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-core-dev
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-core-dev