There are 4 different TICS configuration directories for the TICS client and database component:
cfg: This directory contains the basic TICS
configuration. The %TICS% (for Windows) and $TICS
(for Linux/Solaris) environment variables refer to the location of this
directory. A detailed overview of all files in this directory can be found here.
bin: This directory contains all TICS framework
binaries. Its location can be found in the TICSBIN.txt file in the
cfg directory.
chk: This directory contains all code checkers used by
the TICS framework. It is located ../chk relative to the
cfg or bin directories. This location can be
overridden via the TICSCHK.txt file in the cfg
directory. The contents of this file differs per installation. It may contain
tools such as pmd (open source Java code checker),
TICSc (TIOBE's C code checker) and C++test
(commercial C++ code checker).
rules: This directory contains all individual rules of
the used code checkers (in case these are distributed separately). It is
located in the directory ../rules relative to the chk
directory. For example all rules of C++test are usually stored here as
.rule files.
The TICS viewer is configured at a different location:
<WEBSERVER>/settings/. A more detailed
description of this directory can be found here.
The TICS "cfg" directory contains the files below (in alphabetic order).
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.
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.
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:
include path to other IMPL
file.
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):
whererule ID TAB tool TAB implementation ID
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 TOOLSproperty in theSERVER.txtfile.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 TOOLSproperty in theSERVER.txtfile.
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:
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 1has 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.
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:
include path to other IMPL
file.
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):
whererule ID TAB tool TAB implementation ID
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 TOOLSproperty in theSERVER.txtfile.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 TOOLSproperty in theSERVER.txtfile.
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:
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):
whererule ID TAB level TAB category TAB synopsis
rule ID Name of the compiler warning. level A level that indicates the severity of the warning. Here 1has 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.
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.
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.
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@*/: *
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.
This is the TICS license file.
This is a file to configure so called organizational views in the TICS viewer. More details can be found here.
This is a file to configure so called organizational views in the TICS viewer. More details can be found here.
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.
#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).
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.
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.
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.
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.
../bin
//fileserver-3a/TICS6.0.3/bin
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.
../chk
C:/ticschk