Unlike the shipped static CCTs, the CCT generated using this technique will have settings specific to the compiler options used. For example, the relevant settings to support a certain C++ standard will be put in the CCT depending on the ‑‑std flag used in the build system. This should result in more accurate analysis results and less time spent manually modifying the standard CCT’s.
The generated CCT will be stored in the user data area, named either generated_cct_C.cct or generated_cct_CPP.cct and will also be copied into the project folder. Generating another CCT for another project will overwrite the temporary copy in the user data area that was created for the previous project.
All synchronization types can create a CCT, but some are more limited than others – there are many factors that determine this. Generally, INJECT and MONITOR will provide the most complete CCT.
JSON and BUILD_LOG synchronization has the following limitations:
- If the sync is unable to examine a child processes, which can be essential when a compiler is just a front-end for another compiler, then the CCT generation can fail.
- While using this method there is no way to copy the environment information from the running process, which may be required to invoke the compiler. If there is a failure creating the CCT, an error will be displayed in the GUI, and the CLI will return code 26.
The generation of a CCT always requires a compiler to be invoked to obtain information about the compiler. This also applies when using the JSON and BUILD_LOG synchronization methods. If the compiler can’t be invoked when doing the synchronization with CCT generation enabled, the synchronization will fail.
Example sync using INJECT (or MONITOR)
Using INJECT with an executable script or command as a parameter, will start the build process. The process will be monitored, and any source files and dependent information will be extracted and added to the specified Helix QAC project.
This will issue the Linux/UNIX ’make’ command in the current directory and synchronize all build files and dependencies into the Helix QAC project within the current directory.
If the compiler is not supported, the synchronization may still add files that were located but a failure will be reported and the command will return a non-zero error code. If you require support for this compiler in a future release then set the log level to TRACE and send support the resulting log file together with details of the compiler.
To see the list of supported compilers for auto CCT, use a command such as:
If the compiler is supported but the executable name is not as expected, it is possible to map executable names to existing filters with the HELIX_QAC_QAINJECT_PROG environment variable. For example, if your GNU compiler executable is called gcc100, the executable could be mapped to the existing GNU filter by setting the environment variable to gcc100=qa_gnu. More than one mapping can be specified by adding a comma between each setting. For example, gcc100=qa_gnu,gcc101=qa_gnu