- This document describes steps needed to be - done to migrate the existing tool-chain integrations to the CDT 4.0
+ This document describes steps needed to be + done to migrate the existing tool-chain integrations to the CDT 4.0
- Example: to illustrate the above requirement here is how this is handled +
+ Example: to illustrate the above requirement here is how this is handled in the gnu tool-chain definitions:
The gnu plug-in contains the gcc linker tool on Linux is defined as
diff --git a/doc/org.eclipse.cdt.doc.isv/guide/cdt_build_system/whats_new/4.0/whats_new_CBS_40.html b/doc/org.eclipse.cdt.doc.isv/guide/cdt_build_system/whats_new/4.0/whats_new_CBS_40.html index be0d827295a..5136b3e2288 100644 --- a/doc/org.eclipse.cdt.doc.isv/guide/cdt_build_system/whats_new/4.0/whats_new_CBS_40.html +++ b/doc/org.eclipse.cdt.doc.isv/guide/cdt_build_system/whats_new/4.0/whats_new_CBS_40.html @@ -31,7 +31,7 @@ h3 margin-left:0in; page-break-after:avoid; font-size:14.0pt; - font-family:Arial; + font-family:"Arial"; font-style:italic} table.MsoTableGrid {border:1.0pt solid windowtext; @@ -68,11 +68,11 @@ table.MsoTableGrid| What's New in CDT
- Build System 4.0 - This document outlines the new features presented + | What's New in CDT
+ Build System 4.0 + This document outlines the new features presented in the new - CDT build system in CDT 4.0 |
+ CDT build system in CDT 4.0
|
| Modification type | -Possible levels of - modifications | +Modification type | +Possible levels of + modifications | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Changing/substituting the entire tool-chain | @@ -484,12 +484,12 @@ following properties associated with the configuration. (See the "Build Properties mechanism" section for detail on the Build Properties mechanism) -||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
- Property id |
+ Property id
- Description |
+ Description
- Pre-defined Values |
+ Pre-defined Values
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
@@ -848,8 +848,8 @@ Build System-predefined properties
- Automatic tool -settings adjustment with Build Properties +Automatic tool +settings adjustment with Build Properties
Tool-chain ant tool definitions can specify enablement expressions to make their default settings be @@ -994,8 +994,8 @@ font-family:"Courier New";color:navy"></option> information on using enablement expressions please refer to the description of the org.eclipse.cdt.managedbuilder.core.buildDefinitions extension-point.- Specifying the set of supported -build properties +Specifying the set of supported +build properties
The tool-chain modification and New Project Wizard mechanisms need to know the set of build properties each @@ -1077,8 +1077,8 @@ color:black"> Assigning the set of build -properties for configurations/project-types +Assigning the set of build +properties for configurations/project-types
Once the tools/tool-chains has specified the setting adjustment expressions it is possible to use one and the @@ -1102,9 +1102,9 @@ buildArtefactType= -It is possible to specify +It is possible to specify the "buildProperties" attribute for the project type and define the set of build -properties there in the same way as for configuration (see below) +properties there in the same way as for configuration (see below).......> @@ -1114,8 +1114,8 @@ properties there in the same way as for configuration (see below)< <configuration- -... + +...@@ -1138,8 +1138,8 @@ color:navy">> .....>- -... + +...@@ -1172,9 +1172,9 @@ font-family:"Courier New";color:navy"> </toolChain>< The folderInfo is a new element presented in 4.0. The element represents the per-folder settings
The following sections describe how the user interacts with MBS. Text -in red indicates MBS functionality that is not yet +in red indicates MBS functionality that is not yet implemented, but is intended to be implemented in future releases of MBS. 2.1.1 Creating a New ProjectThe CDT user’s experience with the @@ -464,7 +464,7 @@ consideration by turning them off in the MBS Preferences page. filtering, however configurations that use tool-chains that are not installed will not be able to be built on the host system.After selecting the project type, -the user selects 1 … n configurations for her new project from the list +the user selects 1 … n configurations for her new project from the list of configurations defined in the project type. Different configurations can use different tool-chains. The list of configurations is, by default, filtered by: @@ -501,63 +501,63 @@ tool-chain. It should be easy for a user to take an existing CDT project t different host system and quickly create a configuration that builds on that host system using a version of the tool-chain that supports the new host.The user -can also pick 1 … n configurations from the list of default +can also pick 1 … n configurations from the list of default configurations defined in the project type. The list of configurations is, by default, filtered as specified above. 2.1.3 Modifying the Tool-chain of the ConfigurationThe user can select a configuration and modify the following attributes of the tool-chain:
2.1.4 Modifying the Tool Options of the ConfigurationThe user can modify the options of -an individual configuration, or he can make changes to a set of configurations -that he has selected. The user can select a set of configurations individually +an individual configuration, or he can make changes to a set of configurations +that he has selected. The user can select a set of configurations individually or by selecting a “category” of configurations. The names of the categories are defined by the configuration provider – “debug” and “release” are commonly supported. Categories which group configurations by target platform could also @@ -612,18 +612,18 @@ project file (.cdtbuild). When MBS reads a project file with an older version number:
When MBS reads a project file with a newer version number, it displays an error message, and does not load the MBS @@ -634,38 +634,38 @@ also define a version number. The version number is appended to the end of the element id, and stored by MBS with each reference to the element. MBS attempts to resolve references in the following manner:
If a match is found, there are 2 scenarios:
If no match is found, MBS displays an error message, and does not load the MBS information. None of the MBS @@ -681,16 +681,16 @@ describes the format of the grammar and what the information is used for by the build model. See the CDT 3.0 Gnu tool-chain definitions for an example of using the managed build object model. Common Attributes-Many of the MBS elements require the specification of the id + Many of the MBS elements require the specification of the id attribute. The attribute value typically takes a form similar to Eclipse -package names, e.g. "cdt.managedbuild.tool.gnu.c.linker". Each id +package names, e.g. "cdt.managedbuild.tool.gnu.c.linker". Each id must be unique within MBS and among all of the loaded manifest files. It is suggested that you include your company/organization name in -the ids that you create. -Many of the MBS elements can specify the name attribute. The +the ids that you create. +Many of the MBS elements can specify the name attribute. The attribute value is used in the MBS user interface, and may therefore change if your tool-chain supports more than one language. You can use a plugin.properties file in order to define these strings in an external file (see the Gnu tool-chain definitions for an example). -Many of the MBS elements can specify the superClass attribute. + Many of the MBS elements can specify the superClass attribute. The attribute value is the id of an element of the same type as this element. For most attributes, when the value of an attribute is not specified in an element, the value will default to the value defined by the first super-class @@ -708,8 +708,8 @@ that the attribute is required by the schema for every instance of the element.& "No" means that the attribute is never required and an appropriate default is supplied if necessary. "In Hierarchy" means that the attribute is not required by the schema, but MBS requires that the attribute be specified -either by the element itself, or inherited from one of its ancestors (see the superClass - attribute). +either by the element itself, or inherited from one of its ancestors (see the superClass + attribute). The figure below shows a UML model @@ -729,7 +729,7 @@ template for the projects that a user will create. The projectType contain or more children of type configuration. These are the default configurations that the user can choose from. Note that there is no reason to define a projectType element in a .cdtbuild file. It would never be used since projectType elements are used to populate the New Project dialog boxes. -You must provide a unique identifier for the project-type in the id + You must provide a unique identifier for the project-type in the id attribute. The build model uses this information to distinguish between the project-type definitions it finds. You must also @@ -739,22 +739,22 @@ in the UI and new project wizards. Project-types can be arranged into hierarchies to promote the efficient sharing of configurations. If you have defined a project-type that should not be selected by the user, but is a root -for other project-types, it may be declared abstract by setting the -isAbstract attribute to ‘true’. Abstract project-types do not appear in the +for other project-types, it may be declared abstract by setting the +isAbstract attribute to ‘true’. Abstract project-types do not appear in the UI. Descendents of an abstract project-type will have the same configurations that the abstract project-type has. For these children to -function properly, their superClass attribute must contain +function properly, their superClass attribute must contain the unique identifier of the super-class project-type. A concrete project type must have at least one configuration defined for it. A configuration must define (or inherit) a set of tool-chain definitions that work together to produce the build goal as an output. A projectType may define a project
-level environment variable provider in the projectEnvironmentSupplier attribute. See §
+level environment variable provider in the projectEnvironmentSupplier attribute. See §
7.6 for additional information. A projectType may define a project
-level macro provider in the projectMacroSupplier attribute. See §
+level macro provider in the projectMacroSupplier attribute. See §
7.8 for additional information. 3.2.1 Schema @@ -820,7 +820,7 @@ UI.
- The unique identifier of the projectType that this projectType is derived from. |
+ The unique identifier of the projectType that this projectType is derived from.
@@ -835,10 +835,10 @@ UI.
|
- |
Flags the projectType as abstract. An abstract
+ Flags the projectType as abstract. An abstract
projectType can not be selected by the user in the UI, but projectTypes
derived from this projectType will inherit its attributes and children.
- The default value is false.
|
- |
A projectType can be flagged for test purposes only. It
+ A projectType can be flagged for test purposes only. It
can be manipulated programmatically, in JUnit tests for example, but not
- selected by the user in the UI. The default value is false.
|
The following steps occur when a CDT user creates a new Managed Build project:
This prepares the new project/configurations for modification by the user. @@ -998,8 +998,8 @@ UI. This is the name that the user entered in the New Project wizard.
- The unique identifier of the projectType that was used when
- creating this project. |
+ The unique identifier of the projectType that was used when
+ creating this project.
@@ -1019,8 +1019,8 @@ configuration.
child of type tool-chain. This describes how the project’s resources are
transformed into the build artifact. The configuration is responsible for
maintaining the name of the final build goal. The user selects the name of the
-build artifact in the UI, and the configuration maintains it in the
-artifactName and artifactExtension attributes. The
+build artifact in the UI, and the configuration maintains it in the
+artifactName and artifactExtension attributes. The
configuration can contain one or more children of type resourceConfiguration.
These describe build settings of individual resources that are different from
the configuration as a whole.
@@ -1029,10 +1029,10 @@ attribute that will be used by the build model to manage the
configuration. It must also have a name that will be
displayed in the UI in the build property page and new project wizards.
The configuration contains the information needed to “clean” the build files on
-the host machine. The configuration can specify the cleanCommand
+the host machine. The configuration can specify the cleanCommand
attribute which specifies a command that removes the build files.
- |
parent
The prebuildStep, -preannounceBuildStep, postbuildStep and postannouncebuildStep + The prebuildStep, +preannounceBuildStep, postbuildStep and postannouncebuildStep attributes define a custom build step to be run before and/or after the the build steps defined by the tool-chain. These attributes are not typically defined in the manifest file, but are instead added by a user from the @@ -1084,8 +1084,8 @@ track of this specific configuration.
- The unique identifier of the configuration that this
- configuration is derived from. |
+ The unique identifier of the configuration that this
+ configuration is derived from.
no |
@@ -1096,8 +1096,8 @@ track of this specific configuration.
artifactName
- The name of the build goal defined by the configuration.
- This can be set by the user in the UI. |
+ The name of the build goal defined by the configuration.
+ This can be set by the user in the UI.
no |
@@ -1108,8 +1108,8 @@ track of this specific configuration.
artifactExtension
- The extension that the build goal will have, for example
- ‘.exe’ or ‘.so’ |
+ The extension that the build goal will have, for example
+ ‘.exe’ or ‘.so’
in hierarchy |
@@ -1120,8 +1120,8 @@ track of this specific configuration.
cleanCommand
- The command to remove intermediary and output files on the
- build machine. |
+ The command to remove intermediary and output files on the
+ build machine.
@@ -1135,13 +1135,13 @@ track of this specific configuration. |
- The semi-colon separated list of the default error parsers
+ The semi-colon separated list of the default error parsers
to be used with this configuration. The list is ordered with the first
error parser on the list invoked first, the second error parser second,
and so on. The list may contain the error parsers defined by CDT and/or
other installed error parser extensions. The list of error parsers to
be used may be changed by the user on a per-configuration basis. When
- specified, this overrides the tool-chain errorParsers attribute. |
+ specified, this overrides the tool-chain errorParsers attribute.
@@ -1249,33 +1249,33 @@ 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
shared library project if they are running Eclipse and CDT on Windows. You can
specify the operating systems and architectures that the tool-chain is supported
-on as a comma-separated list in the osList and archList
+on as a comma-separated list in the osList and archList
attributes.
- |
A tool-chain should specify the -targetTool attribute to identify the tool that runs to generate the primary + A tool-chain should specify the +targetTool attribute to identify the tool that runs to generate the primary build output. If this is not specified, MBS uses the file extension of the build artifact name supplied by the user. This will work when the user uses one of the extensions expected by the tool, but will not work if they do not. MBS supports multiple versions of -a tool-chain. The versionsSupported attribute contains a +a tool-chain. The versionsSupported attribute contains a list of supported versions of a particular tool chain. This indicates that there is no need to perform a conversion when user imports/loads a project with one of the supported tool chain versions. When a tool integrator decides to no longer support a version of a tool chain, they continue to ship the old tool chain definition and specify the id with version number of the tool chain definition -to convert to in the convertToId attribute. If changes to the project +to convert to in the convertToId attribute. If changes to the project information need to be performed by the conversion, the tool chain must provide a converter extension to perform the conversion. If no converter extension is provided, then there won’t be any conversion. See § 8.2 for additional information. A tool-chain may define a
-configuration level environment variable provider in the configurationEnvironmentSupplier attribute. See §
+configuration level environment variable provider in the configurationEnvironmentSupplier attribute. See §
7.6 for additional information. A tool-chain may define a
configuration
-level macro provider in the configurationMacroSupplier attribute. See §
+level macro provider in the configurationMacroSupplier attribute. See §
7.8 for additional information. A tool-chain may be associated @@ -1329,8 +1329,8 @@ the schema table below. superClass
- The unique identifier of the toolChain that this toolChain
- is derived from. |
+ The unique identifier of the toolChain that this toolChain
+ is derived from.
no |
@@ -1341,11 +1341,11 @@ the schema table below.
isAbstract
- Flags the toolChain as abstract. An abstract toolChain
+ Flags the toolChain as abstract. An abstract toolChain
must be defined as a top level object in the model definition and cannot
be selected by the user in the UI, but tool-chains derived from this
tool-chain will inherit its attributes and children. The default value
- is false. |
+ is false.
no |
@@ -1356,10 +1356,10 @@ the schema table below.
targetTool
- A semi-colon separated
+ A semi-colon separated
list of the identifiers of the tools that can be used to create the
build artifact. A list is required, for example, when there are 2
- versions of a target tool that are used with different project natures. |
+ versions of a target tool that are used with different project natures.
@@ -1371,11 +1371,11 @@ the schema table below.
secondaryOutputs |
- A semi-colon separated
+ A semi-colon separated
list of the identifiers of other output types, besides the primary
output of the targetTool, that are also considered to be build
artifacts. The build file generator will ensure that the outputs
- get built. |
+ get built.
@@ -1387,15 +1387,15 @@ the schema table below.
osList |
-
+
The comma separated list of operating systems that the tool-chain is supported on. The
- valid list of operating systems
- is the string values returned by Platform.getOS(). |
+ operating systems, unless the user has turned off filtering.
- If + valid list of operating systems + is the string values returned by Platform.getOS(). + If the osList attribute is not specified, or if the value is "all", then the tool-chain is supported on all operating systems. Otherwise, the tool-chain is only displayed when CDT is running on one of the specified - operating systems, unless the user has turned off filtering.
@@ -1409,20 +1409,20 @@ the schema table below.
|
-
+
The comma separated list of architectures that the tool-chain is supported on. The
- valid list of
-
- architectures is the string values returned by Platform.getOSArch(). |
+ turned off filtering.
- - If the archList attribute is not + valid list of + + architectures is the string values returned by Platform.getOSArch(). + + If the archList attribute is not specified, or if the value is "all", then the tool-chain is supported on all architectures. Otherwise, the tool-chain is only displayed when CDT is running on one of the specified architectures, unless the user has - turned off filtering.
+ valign="top">
no |
The semi-colon separated list of the default error
+ valign="top">The semi-colon separated list of the default error
parsers to be used with this tool-chain. The list is ordered with the
first error parser on the list invoked first, the second error parser
second, and so on. The list may contain the error parsers defined by
CDT and/or other installed error parser extensions. When specified,
this overrides the tool errorParsers attributes of the tool children of
- the tool-chain and the builder child of the tool-chain. |
+ the tool-chain and the builder child of the tool-chain.
no |
@@ -1486,8 +1486,8 @@ the schema table below.
method to be called to determine if support for the tool-chain is
currently installed on the system. MBS uses this information in
order to filter the choices presented to the CDT user and to inform the
- user when support needed by their project is not installed. If the
- isToolChainSupported callback is not provided by the tool-chain
+ user when support needed by their project is not installed. If the
+ isToolChainSupported callback is not provided by the tool-chain
definition, the tool-chain is treated as supported. If all
configurations defined for the given project type are not supported the
project type is treated as unsupported.
@@ -1575,9 +1575,9 @@ the schema table below.
The builder element represents the utility that drives the build process (typically, but not necessarily, a variant -of “make”). It defines the command needed to invoke the build utility in the -command attribute. Any special flags that need to be passed to the builder -are defined in the arguments attribute. The builder can specify the +of “make”). It defines the command needed to invoke the build utility in the +command attribute. Any special flags that need to be passed to the builder +are defined in the arguments attribute. The builder can specify the error parser(s) to be used to parse its output. The builder also specifies a Java class that generates the build file. MBS provides built-in gnu makefile generation. @@ -1585,7 +1585,7 @@ generation. build macros and how they interact with the build file generator.The builder can specify the template of how to convert a build macro that contains an environment variable into the build file -environment variable format by specifying the variableFormat attribute. +environment variable format by specifying the variableFormat attribute. The builder can specify the builder internal (reserved) macro names and the macro names reserved by a build file generator (used to @@ -1593,24 +1593,24 @@ store the list of objects files, input files, etc.). This information will be used by the build file generator in the case where the build environment variable macros are not to be expanded in the build file. If an environment variable build macro name conflicts with the name of some reserved macro, it -always gets resolved in the build file. See the reservedMacroNames and -reservedMacroNameSupplier attributes below. +always gets resolved in the build file. See the reservedMacroNames and +reservedMacroNameSupplier attributes below.The builder can provide the values for the file-context -build macros. To provide the value for the macro ${<macro_name>}, the -macro<macro_name>Value attribute should be specified. The value of this +build macros. To provide the value for the macro ${<macro_name>}, the +macro<macro_name>Value attribute should be specified. The value of this attribute should be set to the value of the given macro. MBS will resolve the value of unsupported file-context macros to their actual macro value. In this case, a separate rule for each file will be generated when file-specific macros are used. See the gnu tool-chain for an example of setting these attributes for gnu make. MBS supports multiple versions of -a builder. The versionsSupported attribute contains a list +a builder. The versionsSupported attribute contains a list of supported versions of a particular builder. This indicates that there is no need to perform a conversion when user imports/loads a project with one of the supported builder versions. When a tool integrator decides to no longer support a version of a builder, they continue to ship the old builder definition and -specify the id with version number of the new builder to convert to in the -convertToId attribute. If changes to the project information need to be +specify the id with version number of the new builder to convert to in the +convertToId attribute. If changes to the project information need to be performed by the conversion, the tool chain definition must provide a converter extension to perform the conversion. If no converter extension is provided, then there won’t be any conversion. See § 8.2 for additional information. @@ -1636,87 +1636,87 @@ the schema table below.
- id |
+ id
- A unique identifier that the model manager will use to keep
-track of this specific builder. |
+ A unique identifier that the model manager will use to keep
+track of this specific builder.
- yes |
+ yes
- name |
+ name
- Human-readable name for the builder to be used in the UI. |
+ Human-readable name for the builder to be used in the UI.
- no |
+ no
- superClass |
+ superClass
- The unique identifier of the builder that this builder is
- derived from. |
+ The unique identifier of the builder that this builder is
+ derived from.
- no |
+ no
- isAbstract |
+ isAbstract
- Flags the builder as abstract. An abstract builder must be
+ Flags the builder as abstract. An abstract builder must be
defined as a top level object in the model definition and cannot be
selected by the user in the UI, but builders derived from this builder
- will inherit its attributes and children. The default value is false. |
+ will inherit its attributes and children. The default value is false.
- no |
+ no
- command |
+ command
- Specifies the default command to start the build
+ Specifies the default command to start the build
utility for your toolchain. If the user changes this through the UI, the
overriden value will be stored in the project build file. The build
model will default to this value if the user ever resets a change.
- The default is "make". |
+ The default is "make".
- no |
+ no
- arguments |
+ arguments
- Specifies the additional, default arguments
+ Specifies the additional, default arguments
that will be passed to the build utility when it is called by the
builder. If the user changes the flags through the UI, the overriden
value will be stored in the project build settings file. The build model
will default to this value if the user ever resets a change. The default
- is “-k”. |
+ is “-k”.
- no |
+ no
- errorParsers |
+ errorParsers
Specifies the default list of error parsers used by the builder. These
@@ -1727,32 +1727,32 @@ track of this specific builder. |
- no |
+ no
- buildfileGenerator |
+ buildfileGenerator
- The name of a class that implements IManagedBuilderMakefileGenerator.
+ The name of a class that implements IManagedBuilderMakefileGenerator.
See § 7.2 for additional information. |
- no |
+ no
- variableFormat |
+ variableFormat
- |
contain environment variables are resolved by MBS to their actual
value. The user can also specify that build macros that contain
environment variables be resolved to their actual value, as explained
- earlier.
+ earlier.
The value of this attribute should
+ The value of this attribute should
be set to the expression representing the variable format. For example,
to generate macros with the ${macro} format, the attribute would contain
${=}. To generate macros with the @macro format, the attribute would
@@ -1762,107 +1762,107 @@ track of this specific builder.
- no |
+ no
- isVariableCase
- Sensitive |
+ isVariableCase
+ Sensitive
- Specifies whether the
+ Specifies whether the
builder variables are case sensitive or not. Can be set to either “true”
or “false”. The default is “true”. If the builder does not support
case-sensitive variables and there are some build environment variables
that differ only in case (Environment variables on Unix-like operating
systems are case sensitive), then those macros will always get resolved
- in the buildfile. |
+ in the buildfile.
- no |
+ no
- reservedMacro
- Names |
+ reservedMacro
+ Names
- |
+ these names will always be treated as reserved.
Comma-separated list of reserved
+ Comma-separated list of reserved
macro names. The macro name could contain either the exact name or the
java regular expression. The latter could be used to supply the pattern
of variable names that are generated by MBS in case the “buildVariable”
attribute of the “InputType” element is not specified, etc. If
this attribute is specified and the reservedMacroNameSupplier is not
- specified, the following macro names will be treated as reserved: - 1. a + 1. a macro name that is equal to one of the names specified in the - reservedMacroNames value + reservedMacroNames value- 2. a + 2. a macro name that matches one of the regexp patterns specified in the - reservedMacroNames value + reservedMacroNames value- 3. a + 3. a macro name that is equal to one of the build variable names specified - InputType elements of the tools used in the tool-chain - If this attribute is not + InputType elements of the tools used in the tool-chain + If this attribute is not specified, MBS will assume that there are no reserved macro names that could conflict with the build environment variable macros, except names specified in the “buildVariable” attribute of the “InputType” elements: - these names will always be treated as reserved.
- no |
+ no
- reservedMacro
- NameSupplier |
+ reservedMacro
+ NameSupplier
- |
Should be set to the name of the
+ Should be set to the name of the
class that implements the IReservedMacroNameSupplier interface. If this
attribute is specified the reservedMacroNames attribute is ignored, and
- the following macro names will be treated as reserved: - 1. macro - names that the IReservedMacroNamesSupplier specifies as reserved + 1. macro + names that the IReservedMacroNamesSupplier specifies as reserved- 2. a macro + 2. a macro name that is equal to one of the build variable names specified - InputType elements in the tools used in the tool-chain. + InputType elements in the tools used in the tool-chain.
- no |
+ no
- macroInputFile
- NameValue |
+ macroInputFile
+ NameValue
- Represents the InputFileName macro value. The macro
+ Represents the InputFileName macro value. The macro
specifies the input file name. The input file has the following meaning: |
2. If a tool accepts building multiple files of the primary input type
with one tool invocation the input file is undefined and the macros
representing the input file contain information about one of the inputs
- of the primary input type being built.
+ of the primary input type being built.
1. If a tool does not accept building multiple files of the primary input type with one tool invocation, the input file is the file of the @@ -1870,94 +1870,94 @@ track of this specific builder.
- no |
+ no
- macroInputFile
- ExtValue |
+ macroInputFile
+ ExtValue
- Represents the InputFileExt macro value. The macro
- specifies the extension of the input file. |
+ Represents the InputFileExt macro value. The macro
+ specifies the extension of the input file.
- no |
+ no
- macroInputFile
- BaseNameValue |
+ macroInputFile
+ BaseNameValue
- Represents the InputFileBaseName macro value. The macro
+ Represents the InputFileBaseName macro value. The macro
specifies the base name of the input file. That is the file name with an
- extension stripped. |
+ extension stripped.
- no |
+ no
- macroInputFile
- RelPathValue |
+ macroInputFile
+ RelPathValue
- Represents the InputFileRelPath macro value. The macro
- specifies the input file path relative to the builder current directory. |
+ Represents the InputFileRelPath macro value. The macro
+ specifies the input file path relative to the builder current directory.
- no |
+ no
- macroInputDir
- RelPathValue |
+ macroInputDir
+ RelPathValue
- Represents the InputDirRelPath macro value. The macro
+ Represents the InputDirRelPath macro value. The macro
specifies the input file directory path relative to the builder current
- directory. |
+ directory.
- no |
+ no
- macroInputDir
- RelPathValue |
+ macroInputDir
+ RelPathValue
- Represents the InputDirRelPath macro value. The macro
+ Represents the InputDirRelPath macro value. The macro
specifies the input file directory path relative to the builder current
- directory. |
+ directory.
- no |
+ no
| The targetPlatform element represents the os/architecture -combination(s) upon which the output of a tool-chain can be deployed. The -osList and archList attributes contain the Eclipse names of the +combination(s) upon which the output of a tool-chain can be deployed. The +osList and archList attributes contain the Eclipse names of the operating systems and architectures described by this element. CDT offers a facility for parsing binary files if it knows which output format the build artifact has been -produced with. The binaryParser attribute must contain the id of the +produced with. The binaryParser attribute must contain the id of the appropriate parser if you want build artifacts of the tool-chain to be parsed in the workspace. 3.7.1 Schema @@ -2133,8 +2133,8 @@ the workspace. superClass
- The unique identifier of the targetPlatform that this
- targetPlatform is derived from. |
+ The unique identifier of the targetPlatform that this
+ targetPlatform is derived from.
no |
@@ -2145,11 +2145,11 @@ the workspace.
isAbstract
- Flags the targetPlatform as abstract. An abstract
+ Flags the targetPlatform as abstract. An abstract
targetPlatform must be defined as a top level object in the model
definition and can not be selected by the user in the UI, but target
platforms derived from this target platform will inherit its attributes
- and children. The default value is false. |
+ and children. The default value is false.
no |
@@ -2160,12 +2160,12 @@ the workspace.
osList
-
+
The list of operating systems that is valid for this target platform.
- The valid list of operating systems
- is the string values returned by Platform.getOS(). If
+ The valid list of operating systems
+ is the string values returned by Platform.getOS(). If
the osList attribute is not specified, or if the value is "all", then
- the target platform supports all operating systems. |
+ the target platform supports all operating systems.
@@ -2179,12 +2179,12 @@ the workspace.
|
-
+
The list of architectures that is valid for this target platform. The
- valid list of architectures
- is the string values returned by Platform.getOSArch(). If
+ valid list of architectures
+ is the string values returned by Platform.getOSArch(). If
the archList attribute is not specified, or if the value is "all", then
- the target platform supports all architectures. |
+ the target platform supports all architectures.
@@ -2196,8 +2196,8 @@ the workspace.
valign="top">binaryParser |
Semi-colon separated list of the ids of the appropriate parser(s) for the build
- artifact |
+ valign="top">Semi-colon separated list of the ids of the appropriate parser(s) for the build
+ artifact
no |
@@ -2207,7 +2207,7 @@ the workspace.
The tool element represents the tool in the user model. A tool must have a -unique id for the build model, and a name that is displayed to a +unique id for the build model, and a name that is displayed to a user through the UI. A tool can be defined as part of a tool-chain, or as an independent specification. A tool may contain one or more @@ -2227,29 +2227,29 @@ library paths. Certain tools logically belong to certain kinds of projects. For example, the Gnu compiler is invoked differently for C and C++ source files. You can specify a filter for a tool based on the -nature of a project using the natureFilter attribute. When a new C +nature of a project using the natureFilter attribute. When a new C project is created, a “cnature” is added to it. New C++ projects have both a “cnature” and “ccnature”. The build model interprets the filter as follows. If you specify a ‘cnature’ filter, then the tool will only be displayed if the -project has a “cnature” and does not have a “ccnature”. If you specify a +project has a “cnature” and does not have a “ccnature”. If you specify a ‘ccnature’ filter, then the tool will be displayed if the project has a “ccnature”. The default if no filter is specified is to display the tool for all projects. -Each tool specifies a command + Each tool specifies a command that will be placed in the build file during the build file generation stage of building. If the tool requires a special output flag, such as ‘-o’ for a compiler or linker, the -implementer must specify that in the outputFlag attribute. -The commandLineGenerator +implementer must specify that in the outputFlag attribute. +The commandLineGenerator
attribute allows the implementer to specify a class that implements the MBS supports multiple versions of -a tool. The versionsSupported attribute contains a list of +a tool. The versionsSupported attribute contains a list of supported versions of a particular tool. This indicates that there is no need to perform a conversion when user imports/loads a project with one of the supported tool versions. When a tool integrator decides to no longer support a version of a tool, they continue to ship the old tool definition and specify the id with -version number of the tool to convert to in the convertToId attribute. +version number of the tool to convert to in the convertToId attribute. If changes to the project information need to be performed by the conversion, the tool chain must provide a converter extension to perform the conversion. If no converter extension is provided, then there won’t be any conversion. @@ -2318,8 +2318,8 @@ build model.
- The unique identifier of the tool that this tool is derived
- from. |
+ The unique identifier of the tool that this tool is derived
+ from.
@@ -2333,10 +2333,10 @@ build model.
|
- Flags the tool as abstract. An abstract tool must be
+ Flags the tool as abstract. An abstract tool must be
defined as a top level object in the model definition and can not be
selected by the user in the UI, but tools derived from this tool will
- inherit its attributes and children. The default value is false. |
+ inherit its attributes and children. The default value is false.
@@ -2469,7 +2469,7 @@ Gnu C compiler, or g++ for the Gnu C++ compiler. |
- Specifies a command “pattern” that indicates how the parts
+ Specifies a command “pattern” that indicates how the parts
of the command line are used to create the entire command line. The
pattern consists of the replaceable variables COMMAND, FLAGS,
OUTPUT_FLAG, OUTPUT_PREFIX, OUTPUT and INPUTS. The default command line
@@ -2477,7 +2477,7 @@ Gnu C compiler, or g++ for the Gnu C++ compiler. |
${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX}${OUTPUT} ${INPUTS},
except when customBuildStep is true, where the default is $(COMMAND).
White space and other characters are significant and are copied to the
- generated command.
+ generated command.
@@ -2491,13 +2491,13 @@ Gnu C compiler, or g++ for the Gnu C++ compiler. |
- When True, indicates that
+ When True, indicates that
the Tool represents a CDT end-user-defined custom build step. The default is
False. When True, the default value of the commandLinePattern attribute
changes to “$(command)”. This attribute is used by the
implementation of Custom Build Steps on the MBS configuration property
page. It is not intended for use by tools defined by a
- tool-integrator. |
+ tool-integrator.
@@ -2511,12 +2511,12 @@ Gnu C compiler, or g++ for the Gnu C++ compiler. |
- Contains a semi-colon separated, ordered, list of error
+ Contains a semi-colon separated, ordered, list of error
parser ids. MBS adds the error parser(s) to the end of the toolChain
error parser list, if not already present, when a project resource is
defined to use the tool. The error parser(s) can be removed by the CDT
user, and is automatically removed when there are no more project
- resources that use the tool. |
+ resources that use the tool.
@@ -2727,8 +2727,8 @@ attributes of the InputType element are described in the table below.
|
- A unique identifier that
- the MBS will use to track this element. |
+ A unique identifier that
+ the MBS will use to track this element.
@@ -2742,8 +2742,8 @@ attributes of the InputType element are described in the table below.
|
- The name of the input type
- that is displayed to the user in the UI. |
+ The name of the input type
+ that is displayed to the user in the UI.
@@ -2757,8 +2757,8 @@ attributes of the InputType element are described in the table below.
|
- The unique identifier of
- the inputType that this inputType is derived from. |
+ The unique identifier of
+ the inputType that this inputType is derived from.
@@ -2772,10 +2772,10 @@ attributes of the InputType element are described in the table below.
|
- The id of an Eclipse
+ The id of an Eclipse
content type that describes this input type. If both the sources
attribute and the sourceContentType attribute are specified, the
- sourceContentType will be used if it is defined in Eclipse. |
+ sourceContentType will be used if it is defined in Eclipse.
@@ -2789,10 +2789,10 @@ attributes of the InputType element are described in the table below.
|
- A comma-separated list of
+ A comma-separated list of
file extensions that the tool will produce output for. Note that the
user will not be able to modify the set of file extensions as they can
- when sourceContentType is specified. |
+ when sourceContentType is specified.
@@ -2806,11 +2806,11 @@ attributes of the InputType element are described in the table below.
|
- The id of an Eclipse
+ The id of an Eclipse
content type used for dependency files. If both the
dependencyExtensions attribute and the dependencyContentType attribute
are specified, the dependencyContentType will be used if it is defined
- in Eclipse. |
+ in Eclipse.
@@ -2824,10 +2824,10 @@ attributes of the InputType element are described in the table below.
|
- A comma-separated list of
+ A comma-separated list of
file extensions used by dependency files. Note that the user will not be
able to modify the set of file extensions as they can when
- dependencyContentType is specified. |
+ dependencyContentType is specified.
@@ -2876,10 +2876,10 @@ attributes of the InputType element are described in the table below.
|
- True if all of the inputs
+ True if all of the inputs
of this category are used in one invocation of the tool. The inputs can
be project resources, or the outputs of other tools in the tool-chain.
- The default is False. |
+ The default is False.
@@ -2893,8 +2893,8 @@ attributes of the InputType element are described in the table below.
|
- True is this is considered
- the primary input of the tool. The default is False. |
+ True is this is considered
+ the primary input of the tool. The default is False.
@@ -2908,10 +2908,10 @@ attributes of the InputType element are described in the table below.
|
- The name of a class that
+ The name of a class that
provides the source file dependency calculation for the input type. The
class implements the IManagedDependencyGenerator2 interface. The default
- is none. |
+ is none.
@@ -2925,13 +2925,13 @@ attributes of the InputType element are described in the table below.
|
- A variable used in the
+ A variable used in the
build file to represent the list of input files. The same variable name
can be used by an outputType to identify a set of output files that
contribute to this tool’s input (i.e., those using the same
buildVariable name). A build variable is ignored when multipleOfType is
false and this is the primary input of the tool. The default name is
- chosen by MBS. |
+ chosen by MBS.
@@ -2970,12 +2970,12 @@ specified by the user (or tool integrator).
|
- Defines a semi-colon
+ Defines a semi-colon
separated list of the relative or absolute path of the resource(s) to
which this element applies. The resource(s) must be a member of the
project, the output from another tool in the tool-chain, or an external
file. The file name of a path can use GNU Make pattern rule syntax (in
- order to generate the name from the output file name). |
+ order to generate the name from the output file name).
@@ -3005,7 +3005,7 @@ specified by the user (or tool integrator).
AdditionalInputDependency – added as both.
- The default is
+ The default is
AdditionalInputDependency. |
|
If the output of the tool usually has a special prefix, like the prefix -‘lib’ for libraries on POSIX systems, the implementer must specify this in the outputPrefix +‘lib’ for libraries on POSIX systems, the implementer must specify this in the outputPrefix attribute. 3.11.1 Schema The optionCategory element represents the option category in -the user model. A tool can have a large number of options. To help organize the user + The optionCategory element represents the option category in +the user model. A tool can have a large number of options. To help organize the user interface for these options, a hierarchical set of option categories can be defined. A unique identifier must be specified in the id @@ -3401,12 +3401,12 @@ Options'. This will be the name the user sees displayed in the UI. The option element represents the option in the user model. Options are used to organize and maintain the command arguments that are sent to tools during the build. Users interact with the build model through the UI to -set the value of options. Each option must have a unique id for the -build model to properly manage it. A descriptive name that will appear in +set the value of options. Each option must have a unique id for the +build model to properly manage it. A descriptive name that will appear in the UI must be specified. Options can be organized into categories to keep the UI more manageable. If an option category has been defined for the tool, and the option should be displayed as part of that category, then the unique identifier -of the option category must be specified in the category attribute. +of the option category must be specified in the category attribute.3.13.1 Option Types Some options contain commands to turn a feature off or on, such as setting a flag to see descriptive messages from a tool. Others contain @@ -3434,7 +3434,7 @@ in respectively. commands that take a user-defined value. The UI representation for a string option is a text box.3.12.1.2 Boolean Options -Boolean options are used to specify an option that is + Boolean options are used to specify an option that is
either true or false. The UI representation for a boolean option is a
check box. The value of the option is set true by selecting the check
box, and false by deselecting it. If true, the command
@@ -3485,21 +3485,21 @@ is ignored for all other option types. 3.13.2 Values and Default Values An option can define a default value that applies to the option until a value has been specified. An option -defines its default value using the defaultValue attribute. When an +defines its default value using the defaultValue attribute. When an option has a value that has been specifically set, the value is contained in the -value attribute. In order to determine the current value of an option, +value attribute. In order to determine the current value of an option, MBS performs the following steps until a value is found:
The type of option will determine how the build model treats the value it finds associated with the attribute. @@ -3512,18 +3512,18 @@ enumerated options search through the defined enumerated values for the default. are passed to build tools with unique flags, depending on the compiler and the option. For example, an option defining the paths a linker should search for libraries might contain a large number of search paths, but each path is passed -to the linker with a ‘-L’ flag. The command attribute is used to hold the +to the linker with a ‘-L’ flag. The command attribute is used to hold the actual flag to pass along with the option value. The build model handles the value it finds associated with the command attribute differently depending on the type of value the option is managing based on the following heuristic. For string -options the option value is appended to the value of the command -attribute. The command attribute can be empty in order to support an area -for typing in additional options. For enumerated options, the command +options the option value is appended to the value of the command +attribute. The command attribute can be empty in order to support an area +for typing in additional options. For enumerated options, the command associated with the selected enumerated value is used, not the command defined -in the option. For boolean options, the command is used if the option -value is set to true, otherwise the value of the commandFalse attribute -is used. For list options, the command is applied to each element of the +in the option. For boolean options, the command is used if the option +value is set to true, otherwise the value of the commandFalse attribute +is used. For list options, the command is applied to each element of the list. For more information about the Eclipse workbench, see Workbench User Guide > Tasks > Upgrading Eclipse. -For more information about Working sets, see Workbench User Guide > Concepts > Working sets. +For more information about the Eclipse workbench, see Workbench User Guide > Tasks > Upgrading Eclipse. +For more information about Working sets, see Workbench User Guide > Concepts > Working sets.
CDT OverviewThe C/C++ Development Toolkit (CDT) is a set of Eclipse plug-ins that provide C and C++ extensions to the Eclipse workbench. For more information about -Eclipse, see Workbench User Guide > Concepts > Workbench. +Eclipse, see Workbench User Guide > Concepts > Workbench.The CDT provides a C/C++ IDE that simplifies many of the same tools that you can use from the command line. The CDT can also communicate with many external utilities and interpret their responses, for example:
The CDT opens as the C/C++ perspective of the Eclipse workbench. The @@ -36,15 +36,15 @@ views: For more information, see Workbench User Guide > Concepts > Perspectives. +For more information, see Workbench User Guide > Concepts > Perspectives. CDT updates-The Install/Update wizard provides information about your current Eclipse installation and provides the framework to manage your updates. -For more information, see Workbench User Guide > Tasks > Updating and installing software. +The Install/Update wizard provides information about your current Eclipse installation and provides the framework to manage your updates. +For more information, see Workbench User Guide > Tasks > Updating and installing software. To view a list of the updates available for the toolsets that you -installed, click Help > Check for Updates. +installed, click Help > Check for Updates.Additional informationdiff --git a/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_over_dbg.htm b/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_over_dbg.htm index 0f898cc0196..7f4f14cfa99 100644 --- a/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_over_dbg.htm +++ b/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_over_dbg.htm @@ -23,7 +23,7 @@ generated from that original source.The CDT debugger uses GDB as the underlying debug engine. It translates each user interface action into a sequence of GDB commands and processes the output from GDB to display the current state of the program being debugged. -Tip: Editing the source after compiling causes the line numbering to be out of + Tip: Editing the source after compiling causes the line numbering to be out of step because the debug information is tied directly to the source. Similarly, debugging optimized binaries can also cause unexpected jumps in the execution trace. diff --git a/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_perspectives.htm b/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_perspectives.htm index f832c54287f..e1a0cbf16ec 100644 --- a/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_perspectives.htm +++ b/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_perspectives.htm @@ -14,16 +14,16 @@A perspective is a layout of views (development tools) in the Workbench window. Each type of perspective is a combination of views, menus, and toolbars that enable you to perform a particular task. For example, the C/C++ perspective has views that are organized to help you develop C/C++ programs; -the Debug perspective has views that enable you to debug those programs. +the Debug perspective has views that enable you to debug those programs. To Open the C/C++ Perspective, select Window > Open Perspective > Other... and select C/C++
-Selecting / Opening Views:
+Selecting / Opening Views:
diff --git a/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_projects.htm b/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_projects.htm
index e84083cd31a..2a5285bb16d 100644
--- a/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_projects.htm
+++ b/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_projects.htm
@@ -15,7 +15,7 @@
source code, makefiles, binaries, and related files. C/C++ projects are displayed
in the C/C++ Projects view.
-
Tip: Nested projects are not supported. Each project must be organized as a + Tip: Nested projects are not supported. Each project must be organized as a discrete entity. Project dependencies are supported by allowing a project to reference other projects that reside in your workspace. For more information, see Selecting referenced projects. @@ -23,8 +23,8 @@ see Selecting referenced pFor more information about projects and where they are stored, see:
Project types@@ -39,22 +39,22 @@ at any time for existing project. Use diff --git a/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_search.htm b/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_search.htm index ccbfafd1ca7..7fea9893f13 100644 --- a/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_search.htm +++ b/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_search.htm @@ -32,7 +32,7 @@ through the use of search delimiters, correct syntax, and wildcards. -For information on working sets, see Workbench User Guide > Concepts > Workbench > Working sets+For information on working sets, see Workbench User Guide > Concepts > Workbench > Working sets What you can search for@@ -42,8 +42,8 @@ For information on working sets, see Workbench User Guide > Concepts > specify. If you choose to search for matching elements, all types, macros, and typdefs are included in the search.
- |
Implicit references and overloaded operators +Implicit references and overloaded operators
@@ -179,7 +179,7 @@ may contain other information.
|
- |
@@ -197,7 +197,7 @@ may contain other information.
System Includes +System Includes
- |
Indexer Accuracy +Indexer Accuracy
|
- |
Open Declaration +Open Declaration Open Declaration (F3) improved, particularly for unresolved symbols.
| Open Declaration is capable of detecting potential matches. @@ -237,7 +237,7 @@ may contain other information.
- |
Converters +Converters
|
- |
Working Sets +Working Sets
|
- |
Make Targets View +Make Targets View
|
- |
Error and Problem management +Error and Problem management ErrorParserManager has been significantly simplified and improved. See bug 264715 and its subtasks.
@@ -307,25 +307,25 @@ may contain other information.
|
@@ -339,14 +339,14 @@ may contain other information.
In the Problems View, external file locations (outside of the workspace) have been moved to the Location + In the Problems View, external file locations (outside of the workspace) have been moved to the Location column and associated with "Open External Location" menu.
- |
DSF Integration +DSF Integration DSF (Eclipse Debugger Services Framework) integrated. See DSF features for more information. |
- |
Launch Group +Launch Group
| New "Launch Group" launch configuration. Allows to launch several processes at once. @@ -361,7 +361,7 @@ may contain other information.
- |
Bugs fixed +Bugs fixed Bugs fixed in this release:
@@ -379,7 +379,7 @@ may contain other information.
|
- |
texthere +texthere text here.
|
Step 1: Creating a project
- To build a project:
If you see an error message, such as: (Cannot run program "make": Launching failed) then CDT cannot locate the build command, usually make. Either your path is not configured correctly, or you do not have make installed on your system. - |
diff --git a/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_comments.htm b/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_comments.htm
index 2573ad2b11d..c6f3de47a57 100644
--- a/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_comments.htm
+++ b/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_comments.htm
@@ -21,18 +21,18 @@ Two styles of comments are supported by current C/C++ compilers:
- 
diff --git a/doc/org.eclipse.cdt.doc.user/getting_started/cdt_w_basic.htm b/doc/org.eclipse.cdt.doc.user/getting_started/cdt_w_basic.htm
index fbfe781f6f8..362039642f3 100644
--- a/doc/org.eclipse.cdt.doc.user/getting_started/cdt_w_basic.htm
+++ b/doc/org.eclipse.cdt.doc.user/getting_started/cdt_w_basic.htm
@@ -26,43 +26,43 @@ Now with CDT, you now select a project type, and that determines what build syst
on the toolbar.
+ 
