Project Configuration

There are 4 different TICS configuration directories for the TICS client and database component:

The TICS viewer is configured at a different location: <WEBSERVER>/settings/. A more detailed description of this directory can be found here.

TICS Configuration files

The TICS "cfg" directory contains the files below (in alphabetic order).


ARCHIVE.txt   (optional)

The ARCHIVE.txt is used by TICSQServer to determine what files need to be stored in the quality database. It contains boolean expressions that are evaluated against each file encountered on the file system. See the ARCHIVE Reference Page for more information on specifying the contents of ARCHIVE files. Note that the ARCHIVE.txt file doesn't need to have this name, but it is best to use this name or a variant of this such as ARCHIVE-project1.txt or ARCHIVE-project2.txt to better understand what it contains.


CanonicalPath.pm   (optional)

This file contains a redefinition of the default way TICS calculates paths for files. Usually the TICS way of calculating unique paths suffices, but in case there are symbolic links or other complex ways of maintaining code archives, this file may be needed.


CFGVERSION.txt   (mandatory)

This is a file that is used by TICS internally to determine whether a configuration update is needed.

Coding Standards IMPL.txt   (mandatory)

The IMPL.txt file contains the implementation for each supported coding standard rule. For each rule, the following fields are given: the rule id, the tool (static code checker) that is used to implement the rule and the internal representation for the rule's implementation (this is in terms of the tool that implements the rule). Some of the rules may take another file as argument, e.g. to specify the allowed the copyright statements. These extra files are also located in the codingstandards/<language>/ directory.

The file format is line based. A line can be one of the following:

  1. An empty line (or a line containing only white space).
  2. A comment line (a line starting with //).
  3. An include directive of the form include path to other IMPL file.
  4. An actual configuration line.

Empty lines and comment lines are ignored.

An include directive includes the given IMPL file (whose path is resolved against the directory of the including IMPL file). Its effect is the same as if the contents of that file was inserted at the location of the include directive. The file name may be enclosed by quotes (either '' or ""), but this is not required. Example:

// Include the Java rules
include "../java/IMPL.txt"

The fourth kind of lines must have tabular format of four columns that are separated by TABs ('\t' in C notation or ASCII character 9):

rule ID TAB tool TAB implementation ID
where
rule ID Name of the rule as used in the coding standard. This name must have a matching name in the RULES.txt.
tool Name of the static analyzer tool that is used to check this rule. The name must match one of the tool names in the TOOLS property in the SERVER.txt file.
implementation ID  Name that identifies the implementation for the tool. The syntax of the name is tool specific and this name must match the pattern given by the value corresponding to the tool in the TOOLS property in the SERVER.txt file.

Coding Standards RULES.txt   (mandatory)

The RULES.txt file contains the coding standard information. For each rule the rule ID (from the coding standard document), level (the severity of the rule), category and synopsis are specified.

The file format is line based. A line can be one of the following:

  1. An empty line (or a line containing only white space).
  2. A comment line (a line starting with //).
  3. An actual configuration line.

Empty lines and comment lines are ignored. The third kind of lines must have tabular format of five columns that are separated by TABs ('\t' in C notation or ASCII character 9):

rule ID TAB level TAB category TAB synopsis

where

rule ID Name of the rule as used in the coding standard.
level A level that indicates the severity of the rule. Here 1 has the highest severity. Higher levels indicate lower severity. As many levels as is desired can be distinguished (i.e., there is no hard upper limit).
category  The category to which the coding rule belongs. As many categories as is desirable may be defined.
synopsis  The rule's synopsis from the coding standard document.

The RULES.txt file must at least have an entry for each rule ID occurring in the IMPL.txt file.


Compiler Warnings IMPL.txt   (mandatory)

The IMPL.txt file contains the implementation for each supported compiler warning. For each warning, the following fields are given: the rule id, the tool (compiler) that checks the warning and the internal representation for the warning's implementation (this is in terms of the compiler that implements the warning).

The file format is line based. A line can be one of the following:

  1. An empty line (or a line containing only white space).
  2. A comment line (a line starting with //).
  3. An include directive of the form include path to other IMPL file.
  4. An actual configuration line.

Empty lines and comment lines are ignored.

An include directive includes the given IMPL file (whose path is resolved against the directory of the including IMPL file). Its effect is the same as if the contents of that file were inserted at the location of the include directive. The file name may be enclosed by quotes (either '' or ""), but this is not required. Example:

// Include the Java rules
include "../java/IMPL.txt"

The fourth kind of lines must have tabular format of four columns that are separated by TABs ('\t' in C notation or ASCII character 9):

rule ID TAB tool TAB implementation ID
where
rule ID Name of the compiler warning. This name must have a matching name in the RULES.txt.
tool Name of the used compiler. The name must match one of the tool names in the TOOLS property in the SERVER.txt file.
implementation ID  Name that identifies the implementation for the tool. The syntax of the name is tool specific and this name must match the pattern given by the value corresponding to the tool in the TOOLS property in the SERVER.txt file.

Compiler Warnings RULES.txt   (mandatory)

The RULES.txt file contains the compiler warning information. For each warning the rule ID, level (the severity of the warning), category and synopsis are specified.

The file format is line based. A line can be one of the following:

  1. An empty line (or a line containing only white space).
  2. A comment line (a line starting with //).
  3. An actual configuration line.

Empty lines and comment lines are ignored. The third kind of lines must have tabular format of five columns that are separated by TABs ('\t' in C notation or ASCII character 9):

rule ID TAB level TAB category TAB synopsis
where
rule ID Name of the compiler warning.
level A level that indicates the severity of the warning. Here 1 has the highest severity. Higher levels indicate lower severity. As many levels as is desired can be distinguished (i.e., there is no hard upper limit).
category  The category to which the compiler warning belongs. As many categories as is desirable may be defined.
synopsis  The warning's synopsis.

The RULES.txt file must at least have an entry for each compiler warning ID occurring in the IMPL.txt file.


DEFINES.txt   (optional)

For languages that require a preprocessor.

Languages that require preprocessing and have macros that can be used as functions and identifiers in source text may require that expansions of such macros be ignored by the code checker. Potential violations by such macros can be silently suppressed by specifying a line in DEFINES.txt containing the name of the macro and a list of rules that should be suppressed for occurrences of the macro.

The DEFINES.txt file contains entries of the form

macro: wildcard [wildcard]...
where
macro ::= \*?\w+\*? | /\*[^:]+\*/
wildcard ::= rule | * | rule with parts replaced by * or ?
rule ::= one of the rule IDs of the IMPL.txt

Empty lines and lines starting with // are ignored.

For macros with leading or trailing *, a suffix resp, prefix match is performed on identifiers in the source code. E.g., ENUM* matches all identifiers starting with ENUM. And *STRUCT matches all identifiers ending with STRUCT.

A macro of the form /*...*/ is a comment that is to be matched exactly to comments in the source file.

For rules, each * and ? is expanded to all matching rules.

Example
AFX_MANAGE_STATE: *
assert: *
FAILED: *
GetDlgItem: *
MESSAGE_HANDLER: *
S_OK: *
SUCCEEDED: *
USES_CONVERSION: *
WAIT_OBJECT_0: *
ENUM*: *
*STRUCT: *
/*@unused@*/: *

An include directive includes the given DEFINES file (whose path is resolved against the directory of the including DEFINES file). Its effect is the same as if the contents of that file were inserted at the location of the include directive. The file name may be enclosed by quotes (either '' or ""), but this is not required.

Example of using include statements in DEFINES files:

File DEFINES.txt:

AFX_MANAGE_STATE: *
assert: *
FAILED: *
GetDlgItem: *
MESSAGE_HANDLER: *
include DEFINES-SPECIFIC.txt

File DEFINES-SPECIFIC.txt:

S_OK: *
SUCCEEDED: *
USES_CONVERSION: *
WAIT_OBJECT_0: *
ENUM*: *
*STRUCT: *
/*@unused@*/: *

DEFINES-project.txt   (optional)

For languages that require a preprocessor.

The contents of this file has the same format as DEFINES.txt except that the contents is only taken into account for those input files that belong to the associated project. The file need not exist for a project. The project must match one of the projects from the PROJECTS property in the SERVER.txt.


lic.dat   (mandatory)

This is the TICS license file.


ORGANIZATION_<project>.txt   (optional)

This is a file to configure so called organizational views in the TICS viewer. More details can be found here.


ORGMAPPING_<project>.txt   (optional)

This is a file to configure so called organizational views in the TICS viewer. More details can be found here.


PREDEFINES-compiler.txt   (mandatory)

For languages that require a preprocessor.

This file contains preprocessor directives for the associated compiler. Usually, the file contains non-ANSI constructs that must be defined away, or macros, identifiers and functions that must be redefined. The compiler must be one of the compilers mentioned in one of the BUILDTYPE properties of the SERVER.txt.

Example
#define _INTEGRAL_MAX_BITS 64
#define __ptr32
#define __ptr64
#define __w64

If the input is known to be strict standards conforming, this file may remain empty (although it must exist).


PROJECTS.txt   (mandatory)

(see here for the viewer equivalent)

The PROJECTS.txt is the configuration file that contains all project specific options. For more details on the PROJECTS.txt configuration options see the PROJECTS.txt Reference Page.


SERVER.txt   (mandatory)

The SERVER.txt is the global configuration file and contains all options related to location of source code, build environments, SCM tooling, analyzers used, language mapping and some miscellaneous options. For more details on the SERVER.txt configuration options see the SERVER.txt Reference Page.


TICS<modulename>.pm   (optional)

These Perl modules overrule the default TICS Perl modules that are part of the official TICS distribution. Try to keep the number of these custom modules as low as possible.


TICSBIN.txt   (mandatory)

This file contains one line referring to the directory in which the TICS binaries can be found. This may be an absolute or relative path. By changing the contents of this file, a complete TICS installation (client and server) can be upgraded at once.

Example 1
../bin
Example 2
//fileserver-3a/TICS6.0.3/bin

TICSCHK.txt   (optional)

This file contains one line referring to the directory in which the TICS checkers can be found. This may be an absolute or relative path. By changing the contents of this file, the code checkers location can be changed to a shared, central location for example.

Example 1
../chk
Example 2
C:/ticschk