Bug 329338

Comment 1 James Blackburn 2010-11-03 08:26:41 EDT

Created attachment 182286 [details]
patch 1

This patch adds a Build context to the build. Allowing the IncrementalProjectBuilder to discover why it's being built: either as the result of a direct call to IProject#build or due to a IWorkspace#build.  The builder can then make intelligent decisions about whether it needs to run.

See bug 216836 for further detail on why this is useful.

Comment 2 James Blackburn 2010-11-03 08:27:03 EDT

Created attachment 182287 [details]
tests v1

Comment 3 James Blackburn 2010-11-03 08:28:24 EDT

Depends on the patch in bug 325489 being applied first.

Comment 4 John Arthorne 2010-11-03 14:41:52 EDT

Putting on the radar for M4.

Comment 5 James Blackburn 2010-11-26 11:19:38 EST

Created attachment 183936 [details]
patch + tests 2

Patch 2 re-based against HEAD.

Comment 6 James Blackburn 2010-11-29 07:02:04 EST

Created attachment 184027 [details]
core.resources patch 3

#Configuration => #Config
Re-base against bug 330197

Comment 7 James Blackburn 2010-11-29 07:03:14 EST

Created attachment 184028 [details]
core.tests.resources patch 3

Comment 8 James Blackburn 2010-11-29 07:37:37 EST

Created attachment 184031 [details]
core.tests.resources patch 4

Fix out of date API usage

Comment 9 James Blackburn 2010-11-29 08:36:19 EST

Created attachment 184036 [details]
example of how build context is used

Szymon's asked that I provide some detail on how / why this API is useful.

The API provides the builder the ability to examine the build order, and potentially optimise a particular build invocation based on what's been built already, and more importantly which configurations will be built subsequently.

Taking a C/C++ example, we have two types of build-time dependencies:
  1) #include's resolved at compile time by the pre-processor
  2) Static archive libraries resolved at link time.

Both of these are represented with build configuration references. 
So actions like: open project + references continue to work correctly.

Consider the following dependencies:
  ExeConfig -> HigherLibConfig
  ExeConfig -> BaseLibConfig
  HigherLibConfig-> BaseLibConfig

ExeConfig, has both kinds of dependency, on HigherLibConfig And BaseLibConfig.  Compiling ExeConfig's files requires source from HigherLib and BaseLib, and linking Exe requires archives built in BaseConfig & HigherLibConfig.

However when the user is working on source in one of those libraries, we can optimise the amount of building done based on the project build configurations being built.
If they're working on HigherLibConfig, we need to rebuild the HigherLibConfig.a whenever source exported (usually .h files) from BaseLib change.  However we don't need to rebuild the BaseLibConfig .a.  This is because the library artifact is only required when linking the final executable.  The BaseLib builder can look at the context in which the builder was called, and short-circuit the particular build invocation using #rememberLastBuiltState() if its build output isn't required in this build invocation.

Similar behaviour could be achieved by not resolving references, and specifying explicitly the configurations to build. However we want, where possible, to be able to re-use platform build actions, and centralise our build logic within the builder.

Note there is already: IncProjBuilder#hasBeenBuilt(IProject). 
This patch generalises the context information within an IBuildContext type.  So it provides: 
  - which build configurations have been built
  - which build configurations will be built next
  - which build configurations the API user requested were built

Comment 10 James Blackburn 2010-11-29 09:10:58 EST

(In reply to comment #9)
> However we want, where possible, to be
> able to re-use platform build actions, and centralise our build logic within
> the builder.

I think for the general case, it would be hard to centralise this logic in the build action. While the simple make builder may not want to be run, other build commands registered on the configuration -- such as a source generation step -- might want to run on each invocation.

Giving the builder visibility of the build order seems to me a relatively clean and powerful way of providing this capability.

Comment 11 Szymon Brandys 2010-11-29 11:21:04 EST

Created attachment 184048 [details]
Minor changes in core.resources patch 3

Comment 12 James Blackburn 2010-11-29 11:40:50 EST

Created attachment 184052 [details]
Syzmon's patch + remove BuildManager#setBuildOrder

BuildManager#setBuildOrder is unneeded as #getRule is only ever called from the context of IProject#build.

Comment 13 James Blackburn 2010-11-29 13:10:45 EST

Created attachment 184062 [details]
tests patch 4

Comment 14 James Blackburn 2010-11-30 04:57:13 EST

Created attachment 184102 [details]
tests patch 5

Tidy up assertion message strings.

Comment 15 Szymon Brandys 2010-11-30 05:13:14 EST

The fix and tests are in HEAD. Thanks James.