[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] IBuildContext and launch configurations
|
So the short answer is that the platform build configurations are of little help when it comes to building (other than using MBS) before launch. I'm thinking of adding an extension point to CDT that would allow for a different kind of build to happen when 'Enable auto build' option is enabled in a launch configuration. The build triggered before launch could be similar to a make-target build rather than to a global workspace build.
-sergey
On Mon, Apr 11, 2011 at 2:15 AM, James Blackburn
<jamesblackburn@xxxxxxxxx> wrote:
Hi Sergey,
Platform build configurations are a mechanism for running a project's builders in multiple orthogonal ways where the platform maintains a couple important bits of state:
- resource delta since the build config was last built
- references between the platform build configurations
In 3.7+ the workspace is always building project build configurations. By default each project has at least one build configuration (default-name: ""). Existing builders can ignore this is they don't care about build configurations.
Platform build configurations are a relatively lightweight construct. It's just a string-list of names & associated references to the resource delta tree.
Does the new IBuildContext and friends support the following scenario:
1. There is a project with a custom builder
Builders are registered at the project level in a specific order. When a project is built, all the builders are run in their defined order with the set of requested build arguments. Resource-delta based builders, which don't care about build configurations, continue to work as they build based on the passed in res-delta since they were last invoked.
2. There is a C++ Application launch configuration that belongs to that project.
core.resources has no knowledge of launches or anything else that depends on build output. One way of doing this would be to pass arguments to the builders and embed the knowledge for build-before-launch into the specific integration.
Currently there's no way to pass optional arguments into a top-level WS build. One reason for this is that we're trying to run the builders consistently to produce the desired artifact(s). If the builder changed its beheaviour based on the arguments passed to it (for example built less stuff) then it would potentially lose the useful resource delta passed to that particular build invocation.
3. 'Enable auto build' is turned on in the launch configuration
You can find this out from the build 'kind' in IncrementalProjectBuilder#build
4. When the custom builder is invoked in response to launching the configuration how can it:
a) Determine that is was called because of a launch
b) Determine the name of the launch configuration that triggered it
I can see how this could be achieved by creating as many build configurations as there are launch configurations, but that is hardly feasible since it's not clear how to maintain the two sets in sync.
I think you need as many build configurations as you have disjoint set of build parameters (not necessarily build artifacts...). Wherever you build the same source in multiple ways you would need a different build-config. This is because, to be useful, builders need the WS to remember which source files have changed since last time the source was built.
If you have multiple binary artifacts where all the source is essentially built in the same way (e.g. a unit test suite), it would make sense to use one build configuration with multiple artifacts. This is something not yet supported by the CDT MBS.
The other bit of complexity is that the MBS supports building modular software. One project here has 100+ projects in a workspace where many library projects are brought together into a top-level embedded app. The build configurations + configuration level references are key to ensure that the workspace only re-builds what needs to be rebuilt.
All this is a work in progress. We're working on bits to satisfy our embedded requirements, but input / help & comments are greatly appreciated.
Cheers,
James
