Community
Participate
Working Groups
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.
Created attachment 182287 [details] tests v1
Depends on the patch in bug 325489 being applied first.
Putting on the radar for M4.
Created attachment 183936 [details] patch + tests 2 Patch 2 re-based against HEAD.
Created attachment 184027 [details] core.resources patch 3 #Configuration => #Config Re-base against bug 330197
Created attachment 184028 [details] core.tests.resources patch 3
Created attachment 184031 [details] core.tests.resources patch 4 Fix out of date API usage
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
(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.
Created attachment 184048 [details] Minor changes in core.resources patch 3
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.
Created attachment 184062 [details] tests patch 4
Created attachment 184102 [details] tests patch 5 Tidy up assertion message strings.
The fix and tests are in HEAD. Thanks James.
