Structure of a Helix QAC Project
A Helix QAC project consists of many files and directories and these are described in this section.
A typical, trivially small project, has the following structure:
[1] ├── 6162132716885071453.hash
[2] ├── prqa
[3] │ ├── configs
[4] │ │ └── Initial
[5] │ │ ├── cip
[23]│ │ │ └── Helix_Generic_C.cip
[6] │ │ ├── config
[7] │ │ │ ├── DATA
│ │ │ │ ├── core_qaf
│ │ │ │ │ ├── __pycache__
│ │ │ │ │ │ └── qaf.cpython-312.pyc
│ │ │ │ │ └── qaf.py
│ │ │ │ └── Helix_Generic_C
│ │ │ │ ├── Script
│ │ │ │ │ └── Helix_Generic_C.py
│ │ │ │ └── Stub
│ │ │ │ └── include
│ │ │ │ └── iso_c
│ │ │ │ ├── assert.h
│ │ │ │ ├── ...
│ │ │ │ └── wctype.h
[8] │ │ │ ├── default_c.acf
[21]│ │ │ ├── default_c.acf.4.6.0.stamp
[9] │ │ │ ├── default-en_US.rcf
[21]│ │ │ ├── default-en_US.rcf.4.6.0.stamp
[10]│ │ │ ├── Helix_Generic_C.cct
│ │ │ └── single-sop.xml
[11]│ │ ├── logs
[12]│ │ ├── output
[13]│ │ │ ├── prqa.db
[14]│ │ │ ├── qa-checksums.xml
[15]│ │ │ └── _SOURCE_ROOT
│ │ │ └── src
[16]│ │ │ ├── inspect.c.arc
[17]│ │ │ └── inspect.c.qac.via
[18]│ │ └── reports
[19]│ ├── qa-framework-app.xml
│ ├── unified
│ └── upgrade
[20]├── prqaproject.xml
[21]├── prqaproject.xml.4.6.0.stamp
[22]├── prqaproject.xml.status
└── src
└── inspect.c
A Helix QAC project will have a prqaproject.xml
file [20] that contains the main configuration data for the project, with additional data stored in the prqa
directory [2]. The prqa
directory contains several other files and directories, including the configs
directory [3]. In this directory there will be one or more configurations - by default a newly created project has a single config called 'Initial' [4].
The cip
directory [5] contain .cip
files [23], one per CCT. These are generated before analysis starts and provides key information for each compiler such as the location of include paths.
The config
directory [6] holds the primary configuration data for a configuration. There will be one or more .cct
files [10] holding information about each compiler, with additional scripts and stubs held in the DATA
directory [7]. There will be one .acf
file (Analysis Configuration File) [8] detailing the components enabled in the config, together with their settings. There will be one .rcf
file (Results Configuration File) [9] detailing the messages that are enabled in this configuration.
The logs
directory [11] can hold the per-project log-files from running Helix QAC. By default, it will be empty as the default behavior is to have log-files go to the User Data Location (UDL).
The output
directory [12] is the location where all analysis intermediate configuration data and results are stored - it can get very large. prqa.db
[13] is our QAX database that stores analysis results. qa-checksums.xml
is used to determine which files need to be re-analysed after a file or component is modified. There will be a directory per Project Root [15] that holds the input configuration (.via
) [17] and output of individual TU analysis (.arc
) [16]. If the TU is outside of all Project Roots then it is held with a hash directory entry, whose values relates to the TU location.
The reports
directory [18] is the default location for any reports that are generated.
The qa-framework-app.xml
file [19] is used to store setting specific to the project.
prqaproject.xml.status File [22]
This file is used internally to indicate the last update time of certain project attributes.
Deleting the prqaproject.xml.status
file will not cause any functional problems, although it should not be done when a project is open.
.stamp Files [21]
Many of the configuration files are XML based and have a schema associated with them (held in the <install-location>/common/schemata
directory). If no .stamp
file is present and a schema exists then a schema check will be made when the file is attempted to be read. If it fails the schema check then Helix QAC will abort and write details to the log-file. If the schema check passes then a .stamp
file will be created - this will stop the schema check being run on the next invocation.
.stamp
files will not cause any functional problems, although it will have a very slight performance impact..hash Files [1]
On startup, various files and directories are copied from the Helix QAC install to the User Data Location (UDL) - after this is done a .hash
file is created. This file has a hash value of several digits in its name, and ends in .hash
- for example, 1234666999.hash
. The hash value is based on the name and contents of the install
directory.
If this file is present in the User Data Location, it allows the copying operations to be skipped where appropriate, with a resultant uptake in performance.
If you want to force the samples and/or config directory to be updated from the install
directories, simply delete the .hash
file(s) and the working files will be copied the next time that any Helix QAC command is issued or that the GUI is started.
.hash
files will not cause any functional problems, although it will have a very slight performance impact.