-
-
+
+
+
+
+
+SDK Support in Carbide.c++
+
+
+
+
+
+
You're not done installing just yet...
+
Release: 2.0.4
+ Revised: April 2009
+
Read the Release Notes for the latest infomation about this product. In Carbide.c++ simply click Help > Help Contents > Carbide Help > Carbide.c++ User Guide.
+
To complete your installation and start Symbian C++ application development, you must install the following:
+
+
+
Installing Perl
+
+
+
+
The Carbide.c++ tools require a copy of Perl to run build scripts:
The CodeScanner command line tool currently accepts an XML configuration file, which controls scanning behavior, like the file types to ignore and which rules to apply. Using the elements contained here makes it possible to customize the scanning rules to include new rules unique to your development environment.
-
This page describes the format of CodeScanner config file (codescannerconfig.xml), which is used for the following purposes:
-
-
Controls scanning behavior of the CodeScanner command line tool
-
Importing/exporting rules and file types from CodeScanner preference pages in Carbide.c++ IDE
-
-
CODESCANNERCONFIG.XML File
-
The CodeScanner config file is an XML formatted file created by CodeScanner when a scan is performed or when the CodeScaner preference settings are exported. The file contains the following elements:
-
-
Arguments element – specifies the arguments to be passed to CodeScanner
-
Sources element – specifies the file types to be ignored by CodeScanner
-
Scripts element – specifies the rules to be applied by CodeScanner
-
Severities element – specifies the severity levels of rules to be applied by CodeScanner
-
Categories element – specifies the categories of rules to be applied by CodeScanner
-
CustomRules element – specifies user defined rules to be applied by CodeScanner
-
-
Arguments Element
-
Each Arguments element contains one or more of the following arguments:
-
-
Input element (<input>, </input>) – Specify an additional directory or file to scan.
-
Outputformat element (<outputformat>, </outputformat>) – Specify the output format(s) of the results generated by CodeScanner. Currently the following output formats are supported:
-
-
html – generate HTML report
-
xml – generate an XML report
-
std – generate messages in standard console output
-
-
-
LXR element (<lxr>, </lxr>) – Specify the URL to an LXR site. When this argument is present, CodeScanner generates links to the specified LXR site instead of the local file system.
-
LXR version element (<lxrversion>, </lxrversion>) – Specify the LXR version when generating links to an LXR site.
-
Timestampedoutput element (<timestampedoutput>, </timestampedoutput>) – Specify whether to generate results in a time-stamped output directory. Supported values are on and off.
Each Sources element can contain one or more Excludes elements.
-
-
Excludes element (<excludes>, </excludes>) – Each Excludes element contains a string, which is a regular expression that specifies a file type to be ignored by CodeScanner.
Each Scripts element can contain one or more Script elements, each of which corresponds to a CodeScanner script (each script applies a CodeScanner rule):
-
-
Script element The name of each Script element matches the name of the corresponding rule, e.g. baseconstruct, forbiddenwords, magicnumbers. Each Script element has the following attributes:
-
-
enable (boolean) – specifies whether a script is enabled by CodeScanner
-
severity (string) – specifies the severity level of a script
-
category (string) – specifies the category of a script
-
In addition, certain script elements also have special child element or attribute:
-
-
-
wordsRE element (<wordsRE>, </wordsRE>) – Specify the child element of the forbiddenwords script element. The wordsRE element contains a string, which is a regular expression that specifies the forbidden words detected by the forbiddenwords script.
-
length attribute – Attribute of the longlines script element. The length attribute is a string that specifies the maximum length of a line of code, beyond which the longlines script flags as a problem.
-
LFunctionIgnoreRE element (<LFunctionIgnoreRE>, </LFunctionIgnoreRE>) – Specify the child element of the LFunctionCantLeave script element. The LFunctionIgnoreRE element contains a string, which is a regular expression that specifies the L-functions to be ignored by the LFunctionCantLeave script when checking for L-functions inside cannot leave.
-
cclassIgnoreRE element (<cclassIgnoreRE>, </cclassIgnoreRE>) – Specify the child element of the missingcclass script element. The cclassIgnoreRE element contains a string, which is a regular expression that specifies the classes to be ignored by the missingcclass script when checking for C classes not inheriting from other C classes.
-
openIgnoreRE element (<openIgnoreRE>, </openIgnoreRE>) – Specify the child element of this open script element. The openIgnoreRE element contains a string, which is a regular expression that specifies the classes or objects to be ignored by the open script when checking for ignored return type from Open().
-
worryRE element (<worryRE>, </ worryRE>) – Child element of the worryingcomments script element. The worryRE element contains a string, which is a regular expression that specifies the worrying comments detected by the worryingcomments script.
-
-
-
Complete list of currently supported Script elements with default attributes:
Each Severities element can contain one or more Severity elements, each of which corresponds to a severity level:
-
-
Severity element The name of each Severity element matches the name of the corresponding severity level. Each Severity element has the following attribute:
-
-
enable (boolean) – Specifies whether scripts of a particular severity level are enabled by CodeScanner.
-
-
-
-
Complete list of currently supported Severity elements:
Each Categories element can contain one or more Category elements, each of which corresponds to a category of CodeScanner scripts:
-
-
Category element The name of each Category element matches the name of the corresponding script category. Each Category element has the following attribute:
-
-
enable (boolean) – Specifies whether scripts of a particular category are enabled by CodeScanner.
-
-
-
-
Complete list of currently supported Category elements:
Each custom rules element can contain one or more custom rule elements, each of which defines a custom rule to be applied by CodeScanner during scanning operation:
-
-
Custom rule element (<customrule>, </customrule>)
-
-
Each custom rule element contains the following elements:
-
-
Name element (<name>, </name>) – The name element specifies the name used by CodeScanner internally to identify a custom rule. A custom rule element can only have one name element.
-
Keyword element (<keyword>, </keyword>) – A keyword element specifies a keyword to use when applying a custom rule. A custom rule element can have multiple keyword elements.
-
- A keyword element also has the following attribute:
-
-
type(string) – specifies the type of a keyword. Here is a list of currently supported keyword types:
-
-
baseclass (name of the base class from the declaration of a sub-class)
-
call (name of a called method)
-
class (name used in the declaration/definition of a class)
-
comment (keyword from a comment)
-
generic (keyword used in generic search, i.e. look for anything that matches the keyword)
-
local (name used in the definition of a local variable)
-
macro (name used in the definition of a macro)
-
member (name used in the definition of a data member)
-
method (name used in the declaration/definition of a method)
-
parameter (name of a resource statement parameter)
-
-
-
-
-
File type element (<filetype>, </filetype>) – A file type element specifies a file extension type to scan when applying a custom rule. A custom rule element can have multiple file type elements. This element is required.
-
Severity element (<severity>, </severity>) – A severity element specifies the severity level of a custom rule: high, medium or low. A custom rule element can have only one severity element.
-
Title element (<title>, </title>) – A title element specifies a title message associated with a custom rule. This is used as the title of HTML report or stdout warning/error message generated when applying a custom rule. A custom rule element can have only one title element.
-
Description element (<description>, </description>) – A description element specifies a detailed description of a custom rule. This is used when generating HTML reports or warning/error messages for stdout when applying a custom rule. A custom rule element can have zero or one description element.
-
Link element (<link>, </link>) – A link element specifies any external link associated with a custom rule. This is used when generating HTML reports or warning/error messages for stdout when applying a custom rule. A custom rule element can have zero or one link element.
-
-
An example of CustomRules element:
-
<customrules>
- <customrule>
- <name>myOwnRule</name>
- <keyword type=”class”>CMyOwnClass</keyword>
- <filetype>h</filetype>
- <severity>low</severity>
- <title>My own little CodeScanner rule</title>
- <description>Locate the definition of CMyOwnClass::MyFunction()</description>
- <link>http://www.myownsite.nokia.com</link>
- </customrule>
- </customrules>
-
-
-
+
+Customizing CodeScanner Rules
+
+
+
+
+
+
Customizing CodeScanner Rules
+
+
The CodeScanner command line tool currently accepts an XML configuration file, which controls scanning behavior, like the file types to ignore and which rules to apply. Using the elements contained here makes it possible to customize the scanning rules to include new rules unique to your development environment.
+
This page describes the format of CodeScanner config file (codescannerconfig.xml), which is used for the following purposes:
+
+
Controls scanning behavior of the CodeScanner command line tool
+
Importing/exporting rules and file types from CodeScanner preference pages in Carbide.c++ IDE
+
+
CODESCANNERCONFIG.XML File
+
The CodeScanner config file is an XML formatted file created by CodeScanner when a scan is performed or when the CodeScaner preference settings are exported. The file contains the following elements:
+
+
Arguments element – specifies the arguments to be passed to CodeScanner
+
Sources element – specifies the file types to be ignored by CodeScanner
+
Scripts element – specifies the rules to be applied by CodeScanner
+
Severities element – specifies the severity levels of rules to be applied by CodeScanner
+
Categories element – specifies the categories of rules to be applied by CodeScanner
+
CustomRules element – specifies user defined rules to be applied by CodeScanner
+
+
Arguments Element
+
Each Arguments element contains one or more of the following arguments:
+
+
Input element (<input>, </input>) – Specify an additional directory or file to scan.
+
Outputformat element (<outputformat>, </outputformat>) – Specify the output format(s) of the results generated by CodeScanner. Currently the following output formats are supported:
+
+
html – generate HTML report
+
xml – generate an XML report
+
std – generate messages in standard console output
+
+
+
LXR element (<lxr>, </lxr>) – Specify the URL to an LXR site. When this argument is present, CodeScanner generates links to the specified LXR site instead of the local file system.
+
LXR version element (<lxrversion>, </lxrversion>) – Specify the LXR version when generating links to an LXR site.
+
Timestampedoutput element (<timestampedoutput>, </timestampedoutput>) – Specify whether to generate results in a time-stamped output directory. Supported values are on and off.
Each Sources element can contain one or more Excludes elements.
+
+
Excludes element (<excludes>, </excludes>) – Each Excludes element contains a string, which is a regular expression that specifies a file type to be ignored by CodeScanner.
Each Scripts element can contain one or more Script elements, each of which corresponds to a CodeScanner script (each script applies a CodeScanner rule):
+
+
Script element The name of each Script element matches the name of the corresponding rule, e.g. baseconstruct, forbiddenwords, magicnumbers. Each Script element has the following attributes:
+
+
enable (boolean) – specifies whether a script is enabled by CodeScanner
+
severity (string) – specifies the severity level of a script
+
category (string) – specifies the category of a script
+
In addition, certain script elements also have special child element or attribute:
+
+
+
wordsRE element (<wordsRE>, </wordsRE>) – Specify the child element of the forbiddenwords script element. The wordsRE element contains a string, which is a regular expression that specifies the forbidden words detected by the forbiddenwords script.
+
length attribute – Attribute of the longlines script element. The length attribute is a string that specifies the maximum length of a line of code, beyond which the longlines script flags as a problem.
+
LFunctionIgnoreRE element (<LFunctionIgnoreRE>, </LFunctionIgnoreRE>) – Specify the child element of the LFunctionCantLeave script element. The LFunctionIgnoreRE element contains a string, which is a regular expression that specifies the L-functions to be ignored by the LFunctionCantLeave script when checking for L-functions inside cannot leave.
+
cclassIgnoreRE element (<cclassIgnoreRE>, </cclassIgnoreRE>) – Specify the child element of the missingcclass script element. The cclassIgnoreRE element contains a string, which is a regular expression that specifies the classes to be ignored by the missingcclass script when checking for C classes not inheriting from other C classes.
+
openIgnoreRE element (<openIgnoreRE>, </openIgnoreRE>) – Specify the child element of this open script element. The openIgnoreRE element contains a string, which is a regular expression that specifies the classes or objects to be ignored by the open script when checking for ignored return type from Open().
+
worryRE element (<worryRE>, </ worryRE>) – Child element of the worryingcomments script element. The worryRE element contains a string, which is a regular expression that specifies the worrying comments detected by the worryingcomments script.
+
+
+
Complete list of currently supported Script elements with default attributes:
Each Severities element can contain one or more Severity elements, each of which corresponds to a severity level:
+
+
Severity element The name of each Severity element matches the name of the corresponding severity level. Each Severity element has the following attribute:
+
+
enable (boolean) – Specifies whether scripts of a particular severity level are enabled by CodeScanner.
+
+
+
+
Complete list of currently supported Severity elements:
Each Categories element can contain one or more Category elements, each of which corresponds to a category of CodeScanner scripts:
+
+
Category element The name of each Category element matches the name of the corresponding script category. Each Category element has the following attribute:
+
+
enable (boolean) – Specifies whether scripts of a particular category are enabled by CodeScanner.
+
+
+
+
Complete list of currently supported Category elements:
Each custom rules element can contain one or more custom rule elements, each of which defines a custom rule to be applied by CodeScanner during scanning operation:
+
+
Custom rule element (<customrule>, </customrule>)
+
+
Each custom rule element contains the following elements:
+
+
Name element (<name>, </name>) – The name element specifies the name used by CodeScanner internally to identify a custom rule. A custom rule element can only have one name element.
+
Keyword element (<keyword>, </keyword>) – A keyword element specifies a keyword to use when applying a custom rule. A custom rule element can have multiple keyword elements.
+
+ A keyword element also has the following attribute:
+
+
type(string) – specifies the type of a keyword. Here is a list of currently supported keyword types:
+
+
baseclass (name of the base class from the declaration of a sub-class)
+
call (name of a called method)
+
class (name used in the declaration/definition of a class)
+
comment (keyword from a comment)
+
generic (keyword used in generic search, i.e. look for anything that matches the keyword)
+
local (name used in the definition of a local variable)
+
macro (name used in the definition of a macro)
+
member (name used in the definition of a data member)
+
method (name used in the declaration/definition of a method)
+
parameter (name of a resource statement parameter)
+
+
+
+
+
File type element (<filetype>, </filetype>) – A file type element specifies a file extension type to scan when applying a custom rule. A custom rule element can have multiple file type elements. This element is required.
+
Severity element (<severity>, </severity>) – A severity element specifies the severity level of a custom rule: high, medium or low. A custom rule element can have only one severity element.
+
Title element (<title>, </title>) – A title element specifies a title message associated with a custom rule. This is used as the title of HTML report or stdout warning/error message generated when applying a custom rule. A custom rule element can have only one title element.
+
Description element (<description>, </description>) – A description element specifies a detailed description of a custom rule. This is used when generating HTML reports or warning/error messages for stdout when applying a custom rule. A custom rule element can have zero or one description element.
+
Link element (<link>, </link>) – A link element specifies any external link associated with a custom rule. This is used when generating HTML reports or warning/error messages for stdout when applying a custom rule. A custom rule element can have zero or one link element.
+
+
An example of CustomRules element:
+
<customrules>
+ <customrule>
+ <name>myOwnRule</name>
+ <keyword type=”class”>CMyOwnClass</keyword>
+ <filetype>h</filetype>
+ <severity>low</severity>
+ <title>My own little CodeScanner rule</title>
+ <description>Locate the definition of CMyOwnClass::MyFunction()</description>
+ <link>http://www.myownsite.nokia.com</link>
+ </customrule>
+ </customrules>
Added support for Knowledge Base Scanning, the ability to scan code and detect possible API issues related to a specific SDK, for example when porting to a new Touch UI SDK. For each SDK, specific porting information is defined as a set of rules specified in XML files. CodeScanner can merge these into the existing set of CodeScanner rules for scanning operations. The results are displayed in the Console view and as information markers in source code.
-
-
2.1.1
-
-
Added support for user-defined rules. This can be done by adding a <customrules> element to the configuration file.
-
When scanning with low severity rules, CodeScanner now generates informative messages instead of warnings when the StdOut output format is selected.
-
Added support to disable individual error/warning via CodeScanner command embedded in comments.
-
Added new rule to check whether Cancel() function is called in active object's destructor.
-
-
Updated active object checking rule to ignore After() from RTimer type member variables.
-
Updated to skip excluded folders specified in configuration file when generating component summary reports.
-
-
2.1.0
-
-
Updated to skip excluded folders specified in configuration file when generating component summary reports.
-
Updated configuration file format to allow passing arguments to CodeScanner. One can now add an <arguments> element to the
- configuration file.
-
Added new rule to check stack-based resource objects not put on the cleanup stack.
-
Added new rule to check inheritance order of M and C classes.
-
-
Updated rule for L-functions that cannot leave. It is now possible to specify functions to be ignored by this rule in the
- configuration file. This is done by adding a <LFunctionIgnoreRE> element to the <LFunctionCantLeave> script element.
-
-
Updated description of rule for badly-named enum members.
-
Updated NULL equality check rule to ignore pointer comparisons with NULL inside various __ASSERT_XXX() macros.
-
Removed duplicate rule for hard-coded external drive letters.
-
-
Improved rule for accessing array element by [] without checking range.
-
-
-
2.0.9
-
-
Updated check for Open() to allow assignment of return value on a different line.
-
-
2.0.8
-
-
Updated check for C class not inheriting from another C class.
-
Updated check for ignored Open() return value.
-
Fixed a bug where some scripts cannot be disabled from the configuration file.
-
-
2.0.7
-
-
Updated standard console output to include severity level and category information in the error/warning messages.
-
-
Incorporated Psyco module to improve scanning performance. Please refer to the document "MIT license.txt" for licensing info.
-
-
What's New
-
-
-
Added support to disable individual error/warning messages via CodeScanner command in comments.
-
Added support to scan code for porting issues related to new SDKs.
Added support for the following IAD user-defined rules. The new rules include:
+
+
<flags> - new IAD rule to check flag usage
+
<crepository> - new IAD rule to check Central Repository usage
+
<customizableicons> - new IAD rule to check customizable icons
+
+
+
Added support for Knowledge Base Scanning, the ability to scan code and detect possible API issues related to a specific SDK, for example when porting to a new Touch UI SDK. For each SDK, specific porting information is defined as a set of rules specified in XML files. CodeScanner can merge these into the existing set of CodeScanner rules for scanning operations. The results are displayed in the Console view and as information markers in source code.
+
+
2.1.1
+
+
Added support for user-defined rules. This can be done by adding a <customrules> element to the configuration file.
+
When scanning with low severity rules, CodeScanner now generates informative messages instead of warnings when the StdOut output format is selected.
+
Added support to disable individual error/warning via CodeScanner command embedded in comments.
+
Added new rule to check whether Cancel() function is called in active object's destructor.
+
+
Updated active object checking rule to ignore After() from RTimer type member variables.
+
Updated to skip excluded folders specified in configuration file when generating component summary reports.
+
+
2.1.0
+
+
Updated to skip excluded folders specified in configuration file when generating component summary reports.
+
Updated configuration file format to allow passing arguments to CodeScanner. One can now add an <arguments> element to the
+ configuration file.
+
Added new rule to check stack-based resource objects not put on the cleanup stack.
+
Added new rule to check inheritance order of M and C classes.
+
+
Updated rule for L-functions that cannot leave. It is now possible to specify functions to be ignored by this rule in the
+ configuration file. This is done by adding a <LFunctionIgnoreRE> element to the <LFunctionCantLeave> script element.
+
+
Updated description of rule for badly-named enum members.
+
Updated NULL equality check rule to ignore pointer comparisons with NULL inside various __ASSERT_XXX() macros.
+
Removed duplicate rule for hard-coded external drive letters.
+
+
Improved rule for accessing array element by [] without checking range.
+
+
+
2.0.9
+
+
Updated check for Open() to allow assignment of return value on a different line.
+
+
2.0.8
+
+
Updated check for C class not inheriting from another C class.
+
Updated check for ignored Open() return value.
+
Fixed a bug where some scripts cannot be disabled from the configuration file.
+
+
2.0.7
+
+
Updated standard console output to include severity level and category information in the error/warning messages.
+
+
Incorporated Psyco module to improve scanning performance. Please refer to the document "MIT license.txt" for licensing info.
+
+
What's New
+
+
+
Added support to disable individual error/warning messages via CodeScanner command in comments.
+
Added support to scan code for porting issues related to new SDKs.
Carbide licenses can be installed and tested from commands in the Help menu. Additional menu options are also available for licenses. All Carbide.c++ Editions, except Carbide.c++ Express, require a valid license to access and use specific features. Once you register your copy of Carbide.c++ a license for your specific product edition is emailed to you. Use the following information to install, test, view, and generally manage your Carbide license.
Select the install license menu option (Help > Carbide Licenses > Install License...) to display the Install License window (figure 1).
-
-
Figure 1. Install License Window
-
Copy and paste your license key data into the window. Enter a filename for the new license and click the OK button.
-
NOTE Restart Carbide.c++ for the new license to take effect.
-
Select New Active License File...
-
Choose the Select New Active License File... menu option (Help > Carbide Licenses > Select New Active License File...) to display an Open window that allows you to select a license (.lic) file.
-
-
Figure 2. Select New Active License File
-
Test Licenses...
-
Select Help > Carbide Licenses > Test Licenses... to test the validity of the current license file. If the license file is valid a Carbide License Manager Verification window appears and confirms that the file is valid.
Select Help > Carbide Licenses > View License File... to display a Current License Contents window (figure 4). The window displays information about installed features, such as name of feature, related version, expiration date, and status.
-
-
Figure 4. Current License Contents Window
-
Borrow Floating Licenses...
-
Select Help > Carbide Licenses > Borrow Floating Licenses... to display a Borrow License Window (figure 5). Specify a return date and time for features that can be borrowed.
-
-
Figure 5. Borrow License Window
-
Return Borrowed Licenses
-
Select Help > Carbide Licenses > Return Borrowed Licenses to return borrowed licenses to their previous state.
