Let's say, I've created multiple target platforms, each named "Eclipse ${eclipse.version} Platform Target" where ${eclipse.version} is each of

{3.5, 3.6, 3.7}. It would be nice to support the ability to build against each of these target platforms in a single configuration.

1) I envision adding a "Buckminster Target Platform" axis, which would work as follows:

- A "Buckminster Target Platform" axis is available that list all Target Platforms (like the JDK-axis lists all JDK installations)
– Perhaps this list would only include Target Platforms for which the "lastBuildOnly" flag is set? Perhaps not?
- The user selects the specific target platforms for the build using the axis (like the JDK-axis)

Specifically, the axis would have the following items:
[ ] Eclipse 3.5 Target Platform
[ ] Eclipse 3.6 Target Platform
[ ] Eclipse 3.7 Target Platform

- The "Run Buckminster"'s "Target Platform" drop down list in the build steps also has an additional option, e.g., "Target Platform Axis" (or something like that), which indicates that the axis-specified Target Platform should be used in each build
– This would allow multiple "Run Buckminster" steps to be present, e.g., for when only a subset of the buckminster commands requires the variable target platforms

The problem with this, however, is that variables used to create the original target platform are no longer present. These may still be necessary to perform the resolution of source code or for other purposes. In our example, "${eclipse.version}" would not be available.

2) To address the variable issue, perhaps a "Matching Name" option could be added to the axis, in which the user could specify the name of the target platform, rather than specifically selecting it. This would allow the following:

- A user adds a user-defined axis, in our example "eclipse.version" in {3.5, 3.6, 3.7}

• Another "Buckminster Target Platform" axis is added, but the user selects the "By Name" option
• The user enters "Eclipse ${eclipse.version} Platform Target" in the field

The results is that the variable is present, and its corresponding target platform is also selected.

Alternatively, the variables for the Target Platform build could be "inherited" in the new environment. But, the problems (e.g., inheriting unwanted variables) seem to outweigh the benefits (e.g., not having to create the variable axis by name) to me.