diff --git a/doc/org.eclipse.cdt.doc.isv/guide/dom/index/prebuiltVersioning.html b/doc/org.eclipse.cdt.doc.isv/guide/dom/index/prebuiltVersioning.html
index d64cc8728ad..ec4fabde8f7 100644
--- a/doc/org.eclipse.cdt.doc.isv/guide/dom/index/prebuiltVersioning.html
+++ b/doc/org.eclipse.cdt.doc.isv/guide/dom/index/prebuiltVersioning.html
@@ -5,7 +5,7 @@ xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns="http://www.w3.org/TR/REC-html40">
-
+
diff --git a/doc/org.eclipse.cdt.doc.isv/guide/mbs/extensibilityGuide/Managed_Build_Extensibility.html b/doc/org.eclipse.cdt.doc.isv/guide/mbs/extensibilityGuide/Managed_Build_Extensibility.html
index f8c0eeceec0..2dd20a15d48 100644
--- a/doc/org.eclipse.cdt.doc.isv/guide/mbs/extensibilityGuide/Managed_Build_Extensibility.html
+++ b/doc/org.eclipse.cdt.doc.isv/guide/mbs/extensibilityGuide/Managed_Build_Extensibility.html
@@ -353,7 +353,7 @@ user overrides through the UI between sessions, in the project's .cdtbuild file.
System
There is also a standard build system supplied as part
of the CDT framework that is unrelated to the managed build system. The
-standard system provides a small set of tools to build a user’s
+standard system provides a small set of tools to build a user’s
projects. The user is expected to supply a makefile which includes
enough information to build their project. The UI allows the user to
switch between targets defined in the makefile, and can dynamically
@@ -369,7 +369,7 @@ and maintaining makefiles for projects to be a chore. For these users,
the trade-off for the convenience of not having to maintain them is the
flexibility of being in control of the makefiles.
The CDT user’s model of the MBS
contains the following primary objects:
@@ -442,7 +442,7 @@ contains the following primary objects:
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 Project
-
The CDT user’s experience with the
+
The CDT user’s experience with the
MBS begins when she creates a new Managed Make project. The user picks the type
of project to create from the list of project types defined in the installed
manifest files. The list of project types is, by default, filtered by:
@@ -481,7 +481,7 @@ configuration 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 initial set of
configurations for the project, the user can select any of the standard tabs in
-the “Additional Project Settings” page in order to customize additional options
+the “Additional Project Settings” page in order to customize additional options
that are common to all Managed Build system projects (e.g., the projects that the new project depends upon, etc.).
The user
can proceed to any additional pages provided by the project type in order to
@@ -495,7 +495,7 @@ the user can use any of the Eclipse methods of adding files to the project.
configuration based upon the settings used by one of the existing
configurations. The user can select a different
tool-chain from the project type if desired. This allows a project type to be
-defined (e.g., “Gnu Executable”) that contains tool-chains for multiple
+defined (e.g., “Gnu Executable”) that contains tool-chains for multiple
combinations of host and target platforms, and/or for multiple versions of a
tool-chain. It should be easy for a user to take an existing CDT project to a
different host system and quickly create a configuration that builds on that
@@ -545,21 +545,21 @@ and modify the following attributes of the tool-chain:
The
mapping of an individual resource to a tool:
- The available tools come from the configuration’s
+ The available tools come from the configuration’s
tool-chain, from a different tool-chain or from individually defined tools.
The
mapping of a set file extensions to a category of tools
or a specific tool: The user can modify the current assignments and add new
- assignments. The available tools come from the configuration’s tool-chain,
+ assignments. The available tools come from the configuration’s tool-chain,
from a different tool-chain or from individually defined tools.
2.1.4 Modifying the Tool Options of the Configuration
The 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
-or by selecting a “category” of configurations. The names of the categories are
-defined by the configuration provider – “debug” and “release” are commonly
+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
be useful.
The user can modify the options of
@@ -569,7 +569,7 @@ is not valid. The current value of a build setting is bolded if the value
different from the default value for the tool. The user can easily set the
value back to the default value without knowing what the default value is.
The user
-can modify certain “well known” build settings for multiple selected
+can modify certain “well known” build settings for multiple selected
configurations, even when the configurations do not use the same tool-chain.
The user
can use Build Macros in all options that accept text. MBS pre-defines many
@@ -578,9 +578,9 @@ additional macros. Additional macros can be defined in the MBS preferences
and for individual projects or configurations. Build Macros are referenced in strings by
enclosing them in braces, preceded by a dollar sign.
Tool
-integrators may define property setting “wizards” that modify sets of tool
+integrators may define property setting “wizards” that modify sets of tool
options in order to reach an overall user-desired goal. An example would be a
-“Most Highly Optimized Build” wizard that set options on multiple tools.
+“Most Highly Optimized Build” wizard that set options on multiple tools.
2.1.5 Modifying the Tool Options of an Individual File
The user can specify different
configuration specific build settings for individual files in the project.
@@ -740,7 +740,7 @@ in the UI and new project wizards.
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
+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
@@ -950,7 +950,7 @@ CDT user creates a new Managed Build project:
the selected configuration element.
For each tool element
child of the tool-chain that is the child of the selected configuration
- element, create a tool element child of the cloned configuration’s
+ element, create a tool element child of the cloned configuration’s
tool-chain element that specifies the original tool element as its
superClass.
@@ -1011,12 +1011,12 @@ UI. This is the name that the user entered in the New Project wizard.
The configuration element
represents the configuration in the user model. A tool-integrator defines
default configurations as children of the project type. These provide a
-template for the configurations added to the user’s project, which are stored in
-the project’s .cdtbuild file. A projectType must have at least one default
+template for the configurations added to the user’s project, which are stored in
+the project’s .cdtbuild file. A projectType must have at least one default
configuration defined for it, and a project must always contain at least one
configuration.
The configuration contains one
-child of type tool-chain. This describes how the project’s resources are
+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
@@ -1028,7 +1028,7 @@ the configuration as a whole.
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 configuration contains the information needed to “clean” the build files on
the host machine. The configuration can specify the cleanCommand
attribute which specifies a command that removes the build files.
The prebuildStep,
@@ -1109,7 +1109,7 @@ track of this specific configuration.
The extension that the build goal will have, for example
- ‘.exe’ or ‘.so’
+ ‘.exe’ or ‘.so’
in hierarchy
@@ -1229,7 +1229,7 @@ track of this specific configuration.
The toolChain element represents
the tool chain in the user model. It is a tool-integrator-defined set
-of tools that transform the project’s input into the project’s outputs. A
+of tools that transform the project’s input into the project’s outputs. A
tool-chain can be defined as part of a configuration, or as an independent
specification that is referenced in a separate configuration via the toolChain
superclass attribute.
@@ -1239,7 +1239,7 @@ children of type tool. These define the tools used in the tool-chain.
of type targetPlatform. This defines the architecture/os combination(s) where
the outputs of the project can be deployed.
The toolChain contains one child
-of type builder. This defines the “build” or “make” utility that is used to
+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
@@ -1267,7 +1267,7 @@ 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
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
+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 §
@@ -1575,7 +1575,7 @@ 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
+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
@@ -1613,7 +1613,7 @@ 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.
+then there won’t be any conversion. See § 8.2 for additional information.
Additional builder attributes are described in
the schema table below.
3.6.1 Schema
@@ -1708,7 +1708,7 @@ track of this specific builder.
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
@@ -1778,8 +1778,8 @@ track of this specific builder.
style="border-style: none solid solid none; border-width: medium 1pt 1pt medium; border-right: 1pt solid windowtext; border-bottom: 1pt solid windowtext; padding: 0in 5.4pt;"
valign="top">
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
+ 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
@@ -1801,8 +1801,8 @@ track of this specific builder.
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
+ 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:
@@ -1820,7 +1820,7 @@ track of this specific builder.
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:
+ specified in the “buildVariable” attribute of the “InputType” elements:
these names will always be treated as reserved.
children of type option which define the tool command line settings that can be
changed by the user.
A tool may contain one or more
-children of type optionCategory. These are used to simplify the user’s
-managements of the tool‘s settings by dividing the options into a hierarchy of
+children of type optionCategory. These are used to simplify the user’s
+managements of the tool‘s settings by dividing the options into a hierarchy of
categories.
A tool may contain one or more
children of type inputType and outputType. These define the inputs and
@@ -2228,16 +2228,16 @@ library paths.
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
-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
-‘ccnature’ filter, then the tool will be displayed if the project has a “ccnature”.
+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
+‘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
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
+requires a special output flag, such as ‘-o’ for a compiler or linker, the
implementer must specify that in the outputFlag attribute.
The commandLineGenerator
attribute allows the implementer to specify a class that implements the IManagedCommandLineGenerator
@@ -2252,7 +2252,7 @@ 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.
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.
+no converter extension is provided, then there won’t be any conversion.
See § 8.2 for additional information.
Additional tool attributes are
described in the schema table below.
@@ -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
@@ -2494,7 +2494,7 @@ Gnu C compiler, or g++ for the Gnu C++ compiler.
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
+ 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.
@@ -2531,8 +2531,8 @@ Gnu C compiler, or g++ for the Gnu C++ compiler.
style="border-style: none solid solid none; border-width: medium 1pt 1pt medium; border-right: 1pt solid windowtext; border-bottom: 1pt solid windowtext; padding: 0in 5.4pt;"
valign="top">
Specifies a string that is written to the build output prior to each
- invocation of the tool. The default value is “Invoking tool-name
- (tool-id)…”
+ invocation of the tool. The default value is “Invoking tool-name
+ (tool-id)…”
@@ -2928,7 +2928,7 @@ attributes of the InputType element are described in the table below.
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
+ 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.
@@ -3033,7 +3033,7 @@ to generate correct build files, and to allow for input ordering. The prec
order for determining the output resource names is the following:
- If this is the “target” tool in the tool-chain, and this is the primary
+ If this is the “target” tool in the tool-chain, and this is the primary
OutputType, use the user-defined artifact name and extension.
If the option attribute is specified, use the value of the option.
@@ -3047,7 +3047,7 @@ order for determining the output resource names is the following:
file name.
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
style="border-style: none solid solid none; border-width: medium 1pt 1pt medium; border-right: 1pt solid windowtext; border-bottom: 1pt solid windowtext; padding: 0in 5.4pt;"
valign="top">
The id of the option that is used on the command line to specify this
- output. The default is to use the Tool “outputFlag” attribute if
+ output. The default is to use the Tool “outputFlag” attribute if
primaryOutput is True. If option is not specified, and primaryOutput is
False, then the output file(s) of this outputType are not added to the
command line. If specified, the nameProvider, namePattern and
@@ -3183,7 +3183,7 @@ attribute.
- Id of the input type that is used in determining the build “rules” for the
+ Id of the input type that is used in determining the build “rules” for the
output type and for the default name of the output file. The default is
the input type with primaryInput == true.
valign="top" height="83">
Some tools produce files with a special prefix that must be specified.
For example, a librarian on POSIX systems expects the output to be lib.a
- so ‘lib’ would be the prefix. The default is to use the Tool
- “outputPrefix” attribute if primaryOutput is True, otherwise the default
+ so ‘lib’ would be the prefix. The default is to use the Tool
+ “outputPrefix” attribute if primaryOutput is True, otherwise the default
is an empty string.
valign="top">
Specifies a name pattern with the file extension, using the Gnu pattern
rule syntax, for deriving the output resource name from the input
- resource name. The default, “%”, is to use the input file base filename
+ resource name. The default, “%”, is to use the input file base filename
with the output extension.
valign="top">
A variable used in the build file to represent the list of output files.
The same variable name can be used by an inputType to identify a set of
- output files that contribute to the tool’s input (i.e., those using the
+ output files that contribute to the tool’s input (i.e., those using the
same buildVariable name). The default name is chosen by MBS.
Specifying the type of value an option contains is an important
design decision, since it controls how the build model treats the
-contents of the option’s attributes, and just as importantly, how the
+contents of the option’s attributes, and just as importantly, how the
option is displayed to the user. The basic types are string,
boolean, stringList, and enumerated.
@@ -3493,18 +3493,18 @@ MBS performs the following steps until a value is found:
Examine the value
attribute of the option.
Examine the value
- attribute of the option’s superClass recursively.
+ attribute of the option’s superClass recursively.
Examine the
defaultValue attribute of the option.
Examine the
- defaultValue attribute of the option’s superClass recursively.
+ defaultValue attribute of the option’s superClass recursively.
Use the default value for
the option type.
The type of option will determine
how the build model treats the value it finds associated with the attribute.
Options that define simple string values will use the value as-is as described
-below. For boolean options any value but the string ‘true’ will be treated as
+below. For boolean options any value but the string ‘true’ will be treated as
false. List options treat all the defined list option values as default, and
enumerated options search through the defined enumerated values for the default.
3.13.3 Option Commands
@@ -3512,7 +3512,7 @@ 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
@@ -3762,7 +3762,7 @@ can be the id of the tool which is also a category. The default category
style="border-style: none solid solid none; border-width: medium 1pt 1pt medium; border-right: 1pt solid windowtext; border-bottom: 1pt solid windowtext; padding: 0in 5.4pt; vertical-align: top;" height="18">
Value assigned to the option by the end user or in a
default configuration. For options containing a Boolean
- value, the string ‘true’ is treated as true, any other value as false.
+ value, the string ‘true’ is treated as true, any other value as false.
no
@@ -3777,7 +3777,7 @@ can be the id of the tool which is also a category. The default category
style="border-style: none solid solid none; border-width: medium 1pt 1pt medium; border-right: 1pt solid windowtext; border-bottom: 1pt solid windowtext; padding: 0in 5.4pt; vertical-align: top;">
Optionally specifies the value for the option if the user has
not edited it. For options containing a Boolean value, the string
-‘true’ is treated as true, any other value as false.
+‘true’ is treated as true, any other value as false.
An optional value that specifies the actual command that will
be passed to the tool on the command line. The command
- provides a “pattern” for specifying where the value should be placed for
+ provides a “pattern” for specifying where the value should be placed for
options of type string and stringlist. The pattern can
- contain the replaceable variable “value”. If no ${value} is specified
+ contain the replaceable variable “value”. If no ${value} is specified
in the command, the option value is appended to the end of the specified
command.
@@ -3843,10 +3843,10 @@ needed.
Specifies the resource types that this option
- applies to. The values are “project”, “file”, and “all”. The default
- is “all”. Specifying “project” indicates that the option is displayed
- when modifying a configuration’s options, but not when modifying an
- individual file’s options. Specifying “file” indicates the opposite.
+ applies to. The values are “project”, “file”, and “all”. The default
+ is “all”. Specifying “project” indicates that the option is displayed
+ when modifying a configuration’s options, but not when modifying an
+ individual file’s options. Specifying “file” indicates the opposite.
no
@@ -3996,7 +3996,7 @@ be shown to the user in the UI. It also has a command which
should correspond to the command line option that gets passed to the
tool by the builder if this element is selected.
A default element can be indicated by setting the value of isDefault
-to ‘true’. If the user has not overridden the selection in the UI, the
+to ‘true’. If the user has not overridden the selection in the UI, the
default element will be displayed. If no default is specified, the
first
element in the list is assumed to be the default and is displayed to
@@ -4210,8 +4210,8 @@ attributes are specified in the schema table below.
pathType
- The build path type. Can be one of the following: “buildpathInclude”,
- “buildpathLibrary”
+ The build path type. Can be one of the following: “buildpathInclude”,
+ “buildpathLibrary”
yes
@@ -4238,9 +4238,9 @@ attributes are specified in the schema table below.
Represent the delimiter used to separate the paths.
- If omitted the default system delimiter will be used. That is the “:”
- for Unix-like systems and the “;” for Windows systems. If the
- “buildPathResolver” attribute is specified, the “pathDelimiter” is
+ If omitted the default system delimiter will be used. That is the “:”
+ for Unix-like systems and the “;” for Windows systems. If the
+ “buildPathResolver” attribute is specified, the “pathDelimiter” is
ignored
@@ -4262,7 +4262,7 @@ attributes are specified in the schema table below.
The example of such a tool is gcc for Win32 Cygwin. The cygwin
version of gcc does not accept the windows-style paths stored in the
build paths environment variables. The path must be specified in
- the POSIX format and using the “:” delimiter, for example: “/cygdrive/c/includes:/cygdrive/d/…”
+ the POSIX format and using the “:” delimiter, for example: “/cygdrive/c/includes:/cygdrive/d/…”
no
@@ -4400,8 +4400,8 @@ consists of two drop-down list controls and a button. The first
drop-down list is currently read-only, and displays the type of project.
The second contains a list of configurations that are defined for the
project. The figure below shows a project targeted solely at a Windows shared
-library built with GCC that has two configurations; ‘Release’ (not shown), and
-‘Debug’. Note that the build settings model is queried for the project-type and configuration name information.
+library built with GCC that has two configurations; ‘Release’ (not shown), and
+‘Debug’. Note that the build settings model is queried for the project-type and configuration name information.
There is one main makefile generated for each project configuration. Based on
information for the configuration, the proper clean command is defined as a
macro. Note that for efficiency, wherever possible the default build file
-generator takes advantage of Gnu make's ‘:=’ and ‘+=’ variable
+generator takes advantage of Gnu make's ‘:=’ and ‘+=’ variable
assignment operators so that the contents of the makefile macros are
only evaluated when a value is assigned or modified, not every time
they are used. The makefile includes external makefiles that have a
@@ -4598,7 +4598,7 @@ subdirectory looks like.
title="" alt="Generated fragment makefile">
As you can see, the fragment contributes one file, class1.cpp,
and a
-rule to build all source files with the ‘cpp’ extension in the
+rule to build all source files with the ‘cpp’ extension in the
subdirectory where it is located. The content of
the dependency and command lines is derived from the build settings
model. The dependency line is supplied by the build
@@ -4839,10 +4839,10 @@ Select New
should appear below the extension point. That's a bit verbose, so
rename it to example.toolchain.executable.
-
Let’s give the new projectType a human-readable name. Locate the Let’s give the new projectType a human-readable name. Locate the name
property in the Extension Element
-Details column. For now, let’s use the name Example
+Details column. For now, let’s use the name Example
Executable for our projectType.
Make sure that the values of isTest
and isAbstract areset
@@ -4999,7 +4999,7 @@ Each tool describes its inputs and outputs in InputType and OutputType elements.
org.eclipse.cdt.core.cSource.
The build model needs to know if there are any special file
-extensions that indicate a file is a ‘header’ file. Set the
+extensions that indicate a file is a ‘header’ file. Set the
dependencyContentType
property to be org.eclipse.cdt.core.cHeader and the
@@ -5019,7 +5019,7 @@ property to be org.eclipse.cdt.core.cHeader
Let us
assume that the output of the compiler is an object module that has the
-extension ‘o’. Set the value of the outputs
+extension ‘o’. Set the value of the outputs
property of the
tool to o.
We have now defined enough information to create a project for
our
-new example project-type, so let’s go test it out.
+new example project-type, so let’s go test it out.
Make sure our example project is selected in the Package
@@ -5181,12 +5181,12 @@ specifying your own tool integration.
6.13.1 Adding More
Tools
Unless you just happen to have a compiler on your system that is
-invoked with ‘ccc’, the example tool we created is not going to build
+invoked with ‘ccc’, the example tool we created is not going to build
anything. Further, the tool we defined transforms source files into object
files. Another tool, like a linker, would be needed to transform those object
files into a final build goal. For many tool-chains, defining
a
-compiler and “something else” is usually sufficient, but you may have
+compiler and “something else” is usually sufficient, but you may have
to
define additional tools if your tool-chain requires intermediate build
steps to function properly.
@@ -5206,7 +5206,7 @@ number of sources:
tool options as
special so the build model will know to pay special attention to them.
As the implementer of the tool integration, you should make sure your
-specification has options of type “includePaths” and “definedSymbols”.
+specification has options of type “includePaths” and “definedSymbols”.
The build model will pay special attention to these options and provide
them to the appropriate clients in the CDT core without any further
intervention on your part.
@@ -5216,7 +5216,7 @@ compiler settings. See the org.eclipse.cdt.make.core.ScannerConfigurationD
extension point description in the reference documentation for more information.
If a collector is specified, MBS invokes it to return the pre-defined symbols
and include paths. If a collector is not specified, MBS searches for
-options of type “includePaths” and “definedSymbols” with the builtIn
+options of type “includePaths” and “definedSymbols” with the builtIn
attribute set to true.
Environment include paths: Your build definition may specify a
envVarBuildPath element with the pathType attribute set to "buildpathInclude".
@@ -5230,7 +5230,7 @@ Modules
the final build step. The build model needs to be told to pay special attention
to an option containing libraries so that when the build file generator requests
them, it can provide a valid list. Flag the
-option value type as “libs” for external libraries or “userObjs” for
+option value type as “libs” for external libraries or “userObjs” for
object modules.
6.13.4 ProjectType and Other
Element
@@ -5861,7 +5861,7 @@ the CDT user and to inform the user when support needed by their project is not
installed. If the method 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.
-
In order to provide this functionality, the “isToolChainSupported”
+
In order to provide this functionality, the “isToolChainSupported”
attribute in the toolChain
definition must be specified. The value of this attribute should be set to the
name of the class which implements the IManagedIsToolChainSupported
@@ -5879,11 +5879,11 @@ instance);
The version
argument specifies the version of the ToolChain, or null if the ToolChain does
not have a version number. The instance argument is currently null. It will be
-used when “Multi-Instance” support is implemented.
+used when “Multi-Instance” support is implemented.
A tool-integrator can provide a method to be called that identifies the default
environment variables for the tool-chain. These would typically include the
-build path variables (“bin”, “include”, “lib”). These environment variables are
+build path variables (“bin”, “include”, “lib”). These environment variables are
defined by MBS for the process in which the builder (e.g., make) runs. In
addition to providing environment variables the tool-chain integrator can
specify the names of the environment variables used by the tool for specifying
@@ -5892,7 +5892,7 @@ appropriate information about includes and libraries to the rest of the CDT.
The tool-integrator can provide Project-level and
Configuration-level environment variable suppliers separately:
To provide a Configuration-level
-supplier the “configurationEnvironmentSupplier” attribute in the toolChain
+supplier the “configurationEnvironmentSupplier” attribute in the toolChain
definition must be specified. The value of this attribute should be set to the
name of the class which implements the IConfigurationEnvironmentVariableSupplier
interface
@@ -5916,7 +5916,7 @@ the supplier. The supplier should use this provider to obtain
* the already defined environment instead of using
-the “default” provider returned by the
+the “default” provider returned by the
*
@@ -5974,7 +5974,7 @@ environment variable provider to be used for querying the
the supplier. The supplier should use this provider to obtain
* the already defined environment instead of using
-the “default” provider returned by the
+the “default” provider returned by the
*
@@ -6014,7 +6014,7 @@ higher levels.
}
To provide a Project-level
-supplier the “projectEnvironmentSupplier” attribute in the projectType
+supplier the “projectEnvironmentSupplier” attribute in the projectType
definition must be specified. The value of this attribute should be set to the
name of the class which implements the IProjectEnvironmentVariableSupplier
interface.
@@ -6037,7 +6037,7 @@ the supplier. The supplier should use this provider to obtain
* the already defined environment instead of using
-the “default” provider returned by the
+the “default” provider returned by the
*
@@ -6104,7 +6104,7 @@ the supplier. The supplier should use this provider to obtain
* the already defined environment instead of using
-the “default” provider returned by the
+the “default” provider returned by the
*
@@ -6210,14 +6210,14 @@ value the new
* value will be calculated in the following way:
- * For the “prepend” operation:
+ * For the “prepend” operation:
* <New value> = <the value from the
getValue() method><delimiter><Old value>
- * For the “append” operation:
+ * For the “append” operation:
* <New value> = <Old value><delimiter><the
@@ -6228,7 +6228,7 @@ value from the getValue() method>
* The Environment Variable Provider will also
-remove the duplicates of “sub-values”
+remove the duplicates of “sub-values”
* in the resulting value.
@@ -6239,20 +6239,20 @@ remove the duplicates of “sub-values”
* If the current value is
-“string1:string2:string3”, the getDelimiter() method returns “:”
+“string1:string2:string3”, the getDelimiter() method returns “:”
- * and getValue() method returns “string4:string2”
+ * and getValue() method returns “string4:string2”
the new value will contain:
- * For the “prepend” operation:
-“string4:string2:string1:string3”
+ * For the “prepend” operation:
+“string4:string2:string1:string3”
- * For the “append” operation:
-“string1:string3:string4:string2”
+ * For the “append” operation:
+“string1:string3:string4:string2”
*
@@ -6378,7 +6378,7 @@ supplier. The supplier should use this provider to obtain
* the already defined build macros instead of using
-the “default” provider returned by the
+the “default” provider returned by the
* ManagedBuildManager.getBuildMacroProvider().
@@ -6441,7 +6441,7 @@ supplier. The supplier should use this provider to obtain
* the already defined build macros instead of using
-the “default” provider returned by the
+the “default” provider returned by the
* ManagedBuildManager.getBuildMacroProvider().
@@ -6515,7 +6515,7 @@ supplier. The supplier should use this provider to obtain
* the already defined build macros instead of using
-the “default” provider returned by the
+the “default” provider returned by the
* ManagedBuildManager.getBuildMacroProvider().
@@ -6583,7 +6583,7 @@ supplier. The supplier should use this provider to obtain
* the already defined build macros instead of using
-the “default” provider returned by the
+the “default” provider returned by the
* ManagedBuildManager.getBuildMacroProvider().
@@ -6723,9 +6723,9 @@ names are not very "user-friendly", particularly for a user who intend
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”.
+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
@@ -7662,7 +7662,7 @@ created as the child of each Configuration element. The name and id of your new ToolChain must be the parent
-Configuration id, appended with “.toolchain”. The Target isAbstract,
+Configuration id, appended with “.toolchain”. The Target isAbstract,
osList, archList and scannerInfoCollector attributes are
transferred to the ToolChain element.
A new Builder element can be
@@ -7670,7 +7670,7 @@ created as the child of each ToolChain element. The name and id<
the Builder are not dependent upon the name of any of the old model elements.
However, if you allow users to create CDT 2.1 projects using your CDT 2.0
manifest file, then the id of your new Builder must be the parent
-Configuration id, appended with “.builder”. The target isAbstract
+Configuration id, appended with “.builder”. The target isAbstract
attribute is transferred to the Builder element. The target
makeCommand attribute should be transferred to the Builder element as the
command attribute (Note the name change).The target
@@ -7683,11 +7683,11 @@ created as the child of each ToolChain element. The name and id<
the TargetPlatform are not dependent upon the name of any of the old model
elements. However, if you allow users to create CDT 2.1 projects using your CDT
2.0 manifest file, then the id of your new TargetPlatform must be the
-parent Configuration id, appended with “.targetplatform”. The target
+parent Configuration id, appended with “.targetplatform”. The target
isAbstract and binaryParser attributes are transferred to the
TargetPlatform element. The TargetPlatform element contains osList and
archList attributes that specify the architecture(s) and operating system(s)
-on which the Configuration’s build artifact(s) execute. You can transfer the
+on which the Configuration’s build artifact(s) execute. You can transfer the
Target osList and archList attributes if appropriate.
8.1.4 MBS 2.0 Tool Element
The old model allows Tools to be defined at the top level
@@ -7703,7 +7703,7 @@ Tool attributes are supported by the new model.
must remain unchanged in order to support the conversion of old model project
files. The outputs attribute no longer defaults to an empty string. If
your Tool produces files by default with no extension, you must specify
-‘outputs=””’ in the definition of the Tool or one of its ancestors (superClass).
+‘outputs=””’ in the definition of the Tool or one of its ancestors (superClass).
8.1.5 MBS 2.0 ToolReference Element
The new model does not define a ToolReference element.
Instead, a Tool element can specify the superClass attribute in order to
@@ -7712,7 +7712,7 @@ attributes from another Tool and can override one or more attributes.
The old model uses ToolReferences
in two ways. They can be specified as the child of a Configuration element. In
this case, the ToolReference should be converted a Tool element child of the
-Configuration’s ToolChain, transferring the value of the id attribute to
+Configuration’s ToolChain, transferring the value of the id attribute to
the Tool superClass attribute.
A ToolReference can also be
specified as the child of a Target element. In this case, the ToolReference
diff --git a/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/Howtodeveloptemplates.html b/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/Howtodeveloptemplates.html
index 1f0660b431a..4976df14e8e 100644
--- a/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/Howtodeveloptemplates.html
+++ b/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/Howtodeveloptemplates.html
@@ -2,10 +2,10 @@
"http://www.w3.org/TR/html4/loose.dtd">
-How to develop templates in How to extend the user interface using templates
+How to develop templates in How to extend the user interface using templates
@@ -18,13 +18,13 @@
@@ -866,9 +866,9 @@ make it available for use. For more information on this, refer to
-
-
+
+
diff --git a/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/Howtoregistertemplates.html b/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/Howtoregistertemplates.html
index b124ed25e7a..393eef136bf 100644
--- a/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/Howtoregistertemplates.html
+++ b/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/Howtoregistertemplates.html
@@ -2,10 +2,10 @@
"http://www.w3.org/TR/html4/loose.dtd">
-How to register a template with Eclipse in How to extend the user interface using templates
+How to register a template with Eclipse in How to extend the user interface using templates
@@ -16,12 +16,12 @@
diff --git a/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/exampletemplate.html b/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/exampletemplate.html
index 84bac6848bf..5e536d9a4c2 100644
--- a/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/exampletemplate.html
+++ b/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/exampletemplate.html
@@ -2,10 +2,11 @@
"http://www.w3.org/TR/html4/loose.dtd">
-Example template in How to extend the user interface using templates
+Example template in How to extend the user interface using templates
+
@@ -17,12 +18,12 @@
diff --git a/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/index.html b/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/index.html
index 0c8519ff563..240093bef03 100644
--- a/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/index.html
+++ b/doc/org.eclipse.cdt.doc.isv/guide/projectTemplateEngine/index.html
@@ -2,10 +2,10 @@
"http://www.w3.org/TR/html4/loose.dtd">
-How to extend the user interface using templates
+How to extend the user interface using templates
@@ -16,7 +16,7 @@
-
+
@@ -46,8 +46,8 @@ a plug-in which extends the appropriate extension point.
![[Previous]](_stock/btn_prev.gif){kind=small}
- ![[Top]](_stock/btn_top.gif)
- ![[Next]](_stock/btn_next.gif){kind=small}
![[Previous]](_stock/btn_prev_wt.gif){kind=small}
![[Next]](_stock/btn_next_wt.gif){kind=small}