[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-core-dev] Build questions
|
Title: Message
60803
describes pretty much the same problem I am having. Not surprising since
we make a CDT-based product :) . I was trying to get this level of
granularity by ignoring AUTO_BUILD events in my builder. However, since in
some situations AUTO_BUILD is turned to FULL_BUILD, it doesn't work 100% of the
time. This causes a long-running (Linux kernel) build to sometimes be run
at an inopportune time. I think our problem is compounded by the fact that
we use forgetLastBuildState() in our builder, which I think now causes slightly
different behavior than it did in the past. Anyways thanks for the
pointer; I'll monitor bugzilla for updates.
Jeremiah
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
