[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[platform-core-dev] Build questions
|
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.