The toolChain contains one child of type builder. This defines the “build” or “make” utility that is used to drive the transformation of the inputs into outputs.
+The tooChain may contain one or +more children of type optionCategory and option. These define tool-chain +wide settings that are not specific to a particular tool.
Typically a tool-chain is hosted only on a limited subset of operating system/architecture combinations. For example, it does not make much sense to allow a user to try to build a Solaris @@ -3708,7 +3712,11 @@ needed. valign="top">applicability Calculator
The resourceConfiguration element is not visible in the user model. It is a place to store build attributes of individual resources that are different from the configuration as a whole. The resourceConfiguration @@ -3983,7 +3990,7 @@ attributes are specified in the schema table below.
-3.17
+ 3.17
Environment Variable Build Path The tool-integrator can specify the names of the
environment variables used by the tool for specifying the include and the
@@ -4657,7 +4664,6 @@ following list
Each configuration requires a toolChain child that defines the set of tools used by
the configuration.
-6.7 Adding a Builder
Each toolChain can have a builder child that describes the build utility used by
the tool-chain to create the build artifacts of the configuration.org.eclipse.cdt.core.MakeErrorParser;org.eclipse.cdt.core.G
-
Example Builder and the value of id to be
example.toolchain.builder.
make.make.
Each toolChain can have a targetPlatform child that describes the target
operating system(s)/architecture(s) that build artifacts created by the
tool-chain are intended to execute on.
-
Example Target Platform and the value of id to be
@@ -4722,7 +4726,6 @@ example.toolchain.targetplatform.MBS defines a number of element attributes that allow the tool integrator to customize the behavior of the MBS by implementing an MBS-defined interface in a Java class. This section describes these attributes and the interfaces.
@@ -5179,7 +5182,7 @@ instances. Obviously, if you rely on the indexer, you must wait for it to complete its work before it will answer, so your build may take longer to complete.7.4 Replacing the Command Line Generator
+7.4 Replacing the Command Line Generator
You can specify a replacement command line generator for a tool. You must specify and supply a class
that
implements the IManagedCommandLineGenerator
@@ -5249,7 +5252,6 @@ the complete command line, in the IManagedCommandLineInfo interface. The
default MBS implementation does not modify any of the command line parts. It
uses the parts and the pattern to generate the complete command line that can be
retrieved using IManagedCommandLineInfo.getCommandLine.
7.5 Determining if a Tool Chain is Installed
A tool-chain definition can provide a method to be called to determine if support for the tool-chain is currently installed on the @@ -5597,7 +5599,6 @@ getDelimiter() method should
String getDelimiter();
}
-7.7 Defining a Build Path Resolver
To provide a build path resolver, the buildPathResolver attribute in the envVarBuildPath @@ -5639,6 +5640,10 @@ String variableValue,
IConfiguration configuration);
}
++
See +org.eclipse.cdt.managedbuilder.gnu.cygwin.CygwinPathResolver for an example of a +build path resolver. It converts Cygwin paths to Windows paths.
The IConfigurationBuildMacroSupplier interface and the IProjectBuildMacroSupplier interface allow a tool-integrator to define build macros and their values.
@@ -5910,21 +5915,30 @@ holds single String-type value String[] getStringListValue() throws BuildMacroException;}
7.9 Defining a Configuration Name Provider
-All the configuration names must be unique within a -project. Tool Integrators can provide unique configuration names in their -build definitions, or they can use dynamically created unique names. To +
All the configuration names must be unique within a
+project. You can provide unique configuration names in your build
+definitions, or you can dynamically created unique names. To
provide configuration names dynamically, you
must specify and supply a class that implements the IConfigurationNameProvider
interface shown below. The class name is assigned to the projectType element,
configurationNameProvider attribute.
??The basic idea is this. The first configuration asked -gets to use the most “basic” name – e.g. “Debug”. When another configuration is -asked that uses a different tool-chain version, it would see that “Debug” was -already chosen, so it could return “Debug_8.1”. When another configuration is -asked that builds for a different platform, it would see that “Debug” was -already chosen, so it could return “Debug_IPF”. If the ProjectType does not -implement the attribute, the default name provider would add “_2” etc.. to the -configuration name if necessary to get a unique name.
+Consider the following usage for a configuration name +provider. You support multiple versions of your tool-chain within the same +version of CDT (see § 8.2 for a discussion of supporting multiple versions). +For the purpose of this example, assume they are versions 1.0 and 2.0. You +provide default "debug" and "release" configurations for each version of your +tool-chain. You have a choice when assigning names to these default +configurations. You can define unique names statically in your build +definitions (for example, "Debug_1.0", "Debug_2.0", etc.) However, these +names are not very "user-friendly", particularly for a user who intends to use a +single version of your tool-chain. The alternative is to dynamically +assign unique configuration names using a configuration name provider (see the +getNewConfigurationName method below.) The first configuration +that is created gets to use the most “basic” name – for example, “Debug”. When another configuration is +created that uses a different tool-chain version, it would see that “Debug” was +already chosen, so it could return a more qualified name - for example, “Debug_2.0”. +The same technique could be used when your tool-chain supports multiple +host/target platforms.
public interface
IConfigurationNameProvider {
@@ -5938,12 +5952,12 @@ in the project.
String getNewConfigurationName(IConfiguration configuration,
String [] usedConfigurationNames );
-}
-
7.10 Defining an Output Name Provider
+} +7.10 Defining an Output Name Provider
You can specify an output name provider for an outputType. You must specify
and supply a class that implements the IManagedOutputNameProvider
-interface shown below. The class name is assigned to the outputType element, nameProvider attribute.
public interface IManagedOutputNameProvider{
@@ -5964,16 +5978,81 @@ corresponding to the primary input name(s)
getOutputPaths(ITool tool, IPath[] primaryInputs);}
-When multipleOfType -is true, an output name provider, or the outputNames attribute, is required +
When multipleOfType +is true, an output name provider, or the outputNames attribute, is required in order for MBS to know the names of the output files.
- -7.11 Defining an Option Value Handler
-7.12 Defining an Option Applicability Calculator
+7.11 Defining an Option Value Handler
+7.12 Defining an Option Applicability Calculator
+You can specify an option applicability calculator for an option. You
+must specify and supply a
+class that implements the IManagedOutputNameProvider
+interface shown below. The class name is assigned to the outputType element,
+nameProvider attribute. You should implement this interface when an
+option is not always applicable - for example, when an option is only used if
+another option has a particular value.
public interface IOptionApplicability {
+/**
+* This method is queried whenever a makefile or makefile fragment is
+* generated which uses this option, and in the C/C++ Build property
+* pages when displaying the current command line.
+*
+* @param configuration build configuration of option
+* (may be IConfiguration or IResourceConfiguration)
+* @param holder contains the holder of the option
+* @param option the option itself
+*
+* @return true if this option is to be used in command line
+* generation, false otherwise
+*/
+public boolean isOptionUsedInCommandLine(
+ IBuildObject configuration,
+ IHoldsOptions holder,
+ IOption option);
+
+/**
+* This method is queried whenever a new option category is displayed.
+*
+* @param configuration build configuration of option
+* (may be IConfiguration or IResourceConfiguration)
+* @param holder contains the holder of the option
+* @param option the option itself
+*
+* @return true if this option should be visible in the build options page,
+* false otherwise
+*/
+public boolean isOptionVisible(
+ IBuildObject configuration,
+ IHoldsOptions holder,
+ IOption option);
+
+/**
+* Whenever the value of an option changes in the GUI, this method is
+* queried on all other visible options for the same category. Note that
+* this occurs when the GUI changes - the user may opt to cancel these
+* changes.
+*
+* @param configuration build configuration of option
+* (may be IConfiguration or IResourceConfiguration)
+* @param holder contains the holder of the option
+* @param option the option itself
+*
+* @return true if this option should be enabled in the build options page,
+* or false if it should be disabled (grayed out)
+*/
+public boolean isOptionEnabled(
+ IBuildObject configuration,
+ IHoldsOptions holder,
+ IOption option);
+
+}
7.13 Defining a Dynamic Element Provider
Tool integrators may supply a dynamic element provider to dynamically provide the definitions that are otherwise specified in the buildDefinitions extension point. To specify a dynamic element provider, your build definitions must define a dynamicElementProvider element as described in § 3.19.
+7.14 Adding Custom Pages to the New Project Wizard
+This section will be provided in a future version of the document. For +now, refer to the Custom Project Wizard Pages design document in bugzilla +#90334.
8.1 Converting CDT 2.0 Manifest Files
@@ -6108,6 +6187,9 @@ ElementsThis element is supported in the same manner as in CDT 2.0, with the exception that the dynamic elements returned by the provider must use the new object model.
-8.2 Supporting Multiple Versions of a Tool-chain
+8.2 Supporting Multiple Versions of a Tool-chain
+This section will be provided in a future version of the document. For +now, refer to the Tool-chain Multi-version Support design document in bugzilla +#89872.