Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] IBuildContext and launch configurations

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.

On 8 April 2011 00:35, Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx> wrote:
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.


Back to the top