just prerequisites are "interesting projects" for a builder

[haubi]

Only the particular project's prerequisites are "interesting projects" for this project's Xtext builder. Otherwise, we would end with dependency circles causing needless auto build runs. As the ToBeBuiltComputer already does add the "referenced projects", there is nothing left to do for addInterestingProjects().

[haubi]

@szarnekow @jukzi Was there a real reason for every Xtext project in the workspace to be "interesting" to every Xtext project's Xtext builder?

[jukzi]

I guess the idea behind was that it should not be needed to explicitly define dependencies to other lcdsl projects. Is that still the case after this patch?

[haubi]

I guess the idea behind was that it should not be needed to explicitly define dependencies to other lcdsl projects. Is that still the case after this patch?

Well, this was not supported anyway before 1fdcefd011e067ae59651b144c89665a20118a1b I guess? Honestly, not specifying dependencies while possible does not feel like the right thing to do.

[szarnekow]

Indeed the resource for this change was that the projects with the lcdsl files were supposed to be free to refer to any kind of other lcdsl files. This was already implemented for projects in the workspace, but didn't work for projects from the target platform.

The interested projects are used to return the projects for which the eclipse.core.resources are providing delta information to this builder. I'm not even sure if these do have an impact on the build order.

[haubi]

The interested projects are used to return the projects for which the eclipse.core.resources are providing delta information to this builder. I'm not even sure if these do have an impact on the build order.

It's not about the build order, but the decision whether the builder has to be invoked again for a particular project.

Also, there is nothing "broken" as such, because after enough iterations the auto build settles down. The problem here because of these reverse "interests" in our huge application is the duration for the auto build to settle when launching some application, and especially when performing some development - on Linux:

• full build: ~7min, user expects no more pending build tasks
• auto build: ~10min, visible as a whole when disabling/enabling auto build, less time but too annoying when launching some application or performing some workspace changes

Trying to explain what I have discovered while debugging why - right after the successful full build - the auto build needs to compile a lot:

Suppose there's projects A, B, C, having dependencies A <- B <- C.

What does happen during the full build is:

• The build manager does:
  1. Build A
  2. Remember workspace tree snapshot within builder for A
  3. repeat 1 and 2 for B and C
• The user - or even some task in the full build - launches some application, requesting "build before launch"
• The build manager does:
  4. For A, compare remembered workspace tree snapshot of builder for A against current workspace tree
  5. Comparison yields some delta in B and C, because they were built since
  6. Since the builder for A is "interested" in B and C, the builder for A is invoked again, eventually replacing files with same content, modifying the workspace tree
  7. For B, compare remembered workspace tree snapshot of builder for B against current workspace tree
  8. Comparison yields some delta in A and C
  9. Since the builder for B is "interested" in A and C, the builder for B is invoked again
  10. For C, compare remembered workspace tree snapshot of builder for C against current workspace tree
  11. Comparison yields some delta in A and B
  12. Since the builder for C is "interested" in A and B, the builder for C is invoked again

So, again, there's nothing "broken", but circular dependencies don't feel correct in general, and the repeated yet needless auto builds do cause massive developer frustration here, ending up with developers disabling the auto build.

[szarnekow]

Understandable. Reverting this should not cause any harm. This will be taken into account for the next iteration of the work to support lcdsl files coming from the target platform.