You can use the cpptestscan or cpptesttrace utility to create a C++test project that you would normally build using tools such as GNU make, CMake, and QMake. The utilities collect information from the build process of an existing code base that C++test can use to automatically create a project. You can also build a project and manually configure it using the information collected by the utilities.
The Build Data File concept
Build information, such as the working directory, command line options for the compilation, and link processes of the original build, are stored in a file called the build data file. The following example is a fragment from a build data file:
------- cpptestscan v. 9.4.x.x ------- working_dir=/home/place/project/hypnos/pscom project_name=pscom arg=g++ arg=-c arg=src/io/Path.cc arg=-Iinclude arg=-I. arg=-o arg=/home/place/project/hypnos/product/pscom/shared/io/Path.o
The build data file can be used as a source of information about project source files, compiler executable, compiler options, linker executable, and options used to build the project. There are three ways to use the build data file to create a project: Using the command line to automatically import a project. See Importing a Project from the Command Line. Note Required environment variables can also be stored in the build data file if the following apply: See description of the '--cpptestscanEnvInOutput'
option below.
Using cpptestscan or cpptesttrace to Create a Build Data File
The cpptestscan
and cpptesttrace
executables are located in the C++test installation directory. They collect information from the build process of an existing code base, generate build data files with the information, and append information about each execution into a file.
The cpptestscan
utility is used as a wrapper for the compiler and/or linker during the normal build. To use cpptestscan
with an existing build, build the code base with cpptestscan
as the prefix for the compiler / linker executable of an existing build to build the code base. This can be done in two ways:
- Modify the build command line to use
cpptestscan
as the wrapper for the compiler/linker executables - If you don’t want to (or cannot) override the compiler variable on the command line, embed
cpptestscan
in the actual make file or build script.
To use cpptesttrace
with an existing build, build the code base with cpptesttrace
as the prefix for the entire build command. cpptesttrace
will trace the compiler and linker processes executed during the build and store them in the build data file.
In both cases, you need to either add the C++test installation directory to your PATH environment variable, or specify the full path to either utility.
Additional options for cpptestscan
and cpptesttrace
are summarized in the following table. Options can be set directly for the cpptestscan
command or via environment variables. Most options can be applied to cpptestscan
or cpptesttrace
by changing the prefix in command line.
Basic cpptestscan
usage:
- Windows:
cpptestscan.exe [options] [compile/link command]
- Linux:
cpptestscan [options] [compile/link command]
Basic cpptesttrace
usage:
- Windows:
cpptesttrace.exe [options] [build command]
- Linux:
cpptesttrace [options] [build command]
Option | Environment Variable | Description | Default |
---|---|---|---|
-- cpptestscanOutputFile= <OUTPUT_FILE> -- cpptesttraceOutputFile= <OUTPUT_FILE> | CPPTEST_SCAN_OUTPUT_FILE) | Defines file to append build information to. | cpptestscan.bdf |
| CPPTEST_SCAN_PROJECT_NAME | Defines suggested name of the C++test project. | name of the current working directory |
| CPPTEST_SCAN_RUN_ORIG_CMD | If set to "yes", original command line will be executed. | yes |
| CPPTEST_SCAN_QUOTE_CMD_LINE_MODE | Determines the way C++test quotes parameters when preparing cmd line to run.
cpptestscanQuoteCm dLineMode is not supported on Linux
| all |
| CPPTEST_SCAN_CMD_LINE_PREFIX | If non-empty and running original executable is turned on, the specified command will be prefixed to the original command line. | [empty] |
| CPPTEST_SCAN_ENV_IN_OUTPUT | Enabling dumps the selected environment variables and the command line arguments that outputs the file. For advanced settings use – cpptestscanEnvFile and – cpptestscanEnvars options | no |
| CPPTEST_SCAN_ENV_FILE | If enabled, the specified file keeps common environment variables for all build commands; the main output file will only keep differences. Use this option to reduce the size of the main output file. Use this option with – cpptestscanEnvInOut put enabled | [empty] |
| CPPTEST_SCAN_ENVARS | Selects the names of environment variables to be dumped or '*' to select them all. Use this option with – cpptestscanEnvInOut put enabled. | * |
| CPPTEST_SCAN_USE_VARIABLE | Replaces each occurence of "VALUE" string in the scanned build information with the "${VAR_NAME}" variable usage. | [empty] |
-- cpptesttraceTraceComm and | CPPTEST_SCAN_TRACE_COMMAND | Defines the command names that will be traced when collecting build process information. These names, specified as regular expressions, should match original compiler / linker commands used in the build process. |
Example: Modifying GNU Make Build Command to Using cpptestscan
Assuming that a make-based build in which the compiler variable is CXX and the original compiler is g++:
make -f </path/to/makefile> <make target> [user-specific options] CXX="cpptestscan --cpptestscanOutputFile=/path/to/name.bdf --cpptestscanProjectName=<projectname> g++"
This will build the code as usual, as well as generate a build data file (name.bdf) in the specified directory.
Note
When the build runs in multiple directories:
- If you do not specify output file, then each source build directory will have its own .bdf file. This is good for creating one project per source directory.
- If you want a single project per source tree, then a single .bdf file needs to be specified, as shown in the above example.
Example: Modifying GNU Make Build Command Using cpptesttrace
Assume that a regular make-based build is executed with:
make clean all
you could use the following command line:
cpptesttrace --cpptesttraceOutputFile=/path/to/name.bdf --cpptesttraceProjectName=<projectname> make clean all
This will build the code as usual and generate a build data file (name.bdf) in the specified directory.
Note
If the compiler and/or linker executable names do not match default cpptesttrace
command patterns, they you will need to use --cpptesttraceTraceCommand
option described below to customize them. Default cpptestscan command trace patterns can be seen by running 'cpptesttrace --cpptesttraceHelp' command.
Example: Modifying GNU Makefile to use cpptestscan
If your Makefile uses CXX as a variable for the compiler executable and is normally defined as CXX=g++, you can redefine the variable:
ifeq ($(BUILD_MODE), PARASOFT_CPPTEST)
CXX="/usr/local/parasoft/cpptestscan --cpptestscanOutputFile=<selected_location>/MyProject.bdf --cpptestscanProjectName=MyProject g++"
else
CXX=g++
endif
Next, run the build as usual and specify an additional BUILD_MODE variable for make:
make BUILD_MODE=PARASOFT_CPPTEST
The code will be built and a build data file (MyProject.bdf) will be created. The generated build data file can then be used to create a project from the GUI or from the command line.
Note
The cpptestscan
and cpptesttrace
utilities can be used in the parallel build systems where multiple compiler executions can be done concurrently. When preparing Build Data File on the multicore machine, for example, you can pass the -j <number_of_parallel_jobs>
parameter to the GNU make command to build your project and quickly prepare the Build Data File.
Assuming that you have a CMake-based build, you can produce a build data file using cpptesttrace: Run the original CMake command to use CMake to generate make files. For example: Setup environment variables for A build data file will be generated in the location defined by the CPPTEST_SCAN_OUTPUT_FILE variable. If the varialbe is isn’t set, the build data file(s) will be generated in the Makefiles’ locations. All scripts and commands are bash-based – adapt them as needed for different shells. Assuming a CMake-based build, do the following to produce a build data file using cpptestscan: If original CMake command is Prepare the Original CMake command is Setup environment variables for Note By default CMake-generated make files only print information about performed actions without actual compiler/linker command lines. Add “VERBOSE=1” to the make command line to see executed compiler/linker command lines. For non-make based build systems, usage of cpptestscan and cpptesttrace is very similar to the examples shown above. Typically, a compiler is defined as a variable somewhere in the build scripts. To create a Build Data File from that build system using cpptestscan, prefix the original compiler executable with cpptestscan. To create a Build Data File from that build system using cpptesttrace, prefix whole build command line with cpptesttrace.Example: Using cpptesttrace with CMake build
cmake -G "Unix Makefiles" ../project_root
cpptestscan
making sure to use an absolute path for the output file:export CPPTEST_SCAN_PROJECT_NAME=my_project
export CPPTEST_SCAN_OUTPUT_FILE=$PROJ_ROOT/cpptestscan.bdf
cpptesttrace
executable is available on the PATH.cpptesttrace
as a wrapper. For example if normal build command is make clean all for the build with 'cpptesttrace' the command will be cpptesttrace make clean all
Example: Using cpptestscan with CMake build
cmake -G “Unix Makefiles” ../project_root
, then you need to get rid of existing CMake cache and run cmake overriding compiler variables. The following example assumes 'gcc' is used as a C compiler and 'g++' as a C++ compiler executable:rm CMakeCache.txt
CC="cpptestscan gcc" CXX="cpptestscan g++" cmake -G "Unix Makefiles" ../project_root
cmake
failed in the boot-strap phase because the compiler wasn’t recognized.cpptestscan
wrapper scripts that will behave like a CMake compiler by creating the following BASH scripts. In this example, we assume 'gcc' is used as a C compiler and 'g++' as a C++ compiler executable:>cat cpptest_gcc.sh
#!/bin/bash
cpptestscan gcc --cpptestscanRunOrigCmd=no $* > /dev/null 2>&1 gcc $*
exit $?
>cat cpptest_g++.sh
#!/bin/bash
cpptestscan g++ --cpptestscanRunOrigCmd=no $* > /dev/null 2>&1 g++ $*
exit $?
cpptestscan
to extract options without running the compiler. The second script runs the actual compiler so that the entire script looks and acts like a compiler in order to be “accepted” by CMake.cpptestscan
and the scripts are available on the PATH.cmake -G “Unix Makefiles” ../project_root
then you need to get rid of existing CMake cache and run cmake overriding compiler vari-ables. In the following example, we assume 'gcc' is used as a C compiler and 'g++' as a C++ compiler executable:rm CMakeCache.txt
cmake -G "Unix Makefiles" -D CMAKE_C_COMPILER=cpptest_gcc.sh -D CMAKE_CXX_COMPILER=cpptest_g++.sh ../project_root
cpptestscan
; make sure to use an absolute path for the out-put BDF file:export CPPTEST_SCAN_PROJECT_NAME=my_project
export CPPTEST_SCAN_OUTPUT_FILE=$PROJ_ROOT/cpptestscan.bdf
Using cpptestscan or cpptestrace with other Build Systems
When should I use cpptestscan?
It is highly recommended that the procedures to prepare a build data file are integrated with the build system. In this way, generating the build data file can be done when the normal build is performed without additional actions.
To achieve this, prefix your compiler and linker executables with the cpptestscan utility in your Makefiles / build scripts.
When should I use cpptesttrace?
Use cpptesttrace as the prefix for the whole build command when modifying your Makefiles / build scripts isn’t possible or when prefixing your compiler / linker executables from the build command line is too complex.
Once you have used Custom compiler prerequisite If you are using a custom compiler, add it as described in Configuring Testing with the Cross Compiler before starting the wizard. To create a project from a build data file: Click Finish. C++test will create the specified project(s) in the specified location. The project(s) will include all source files whose options were scanned, and project properties should be set up appropriately. You can also create a BDF-based projects in command line mode by using the If you want to perform analysis (e.g., static analysis and/or test generation) immediately after the project is created, ensure that the cpptestcli command uses -config to invoke the preferred Test Configuration. For example: If you simply want to create the project (without performing any analysis), omit -config. For example: Note that -config "util/CreateProjectOnly", which was previously used for creating a project without testing, is no longer used in the current version of C++test. The fake Test Configuration "util/CreateProjectOnly" is no longer supported. You can define custom project settings in a plain text options file, which is passed to The following examples demonstrate how to create a C++test project from the command line using The examples use a make-based build; however, a .bdf file can be produced from any build system. Notes: The generated build data file can be then used to create a project from the GUI or from the command line.Importing project using Build Data File with the GUI wizard
cpptestscan
or cpptesttrace
to generate a build data file for code you want to test in C++test, you can use the Project Creation wizard to create a C++test project.-list-compilers
switch to cpptestcli
Creating a Project from the Command Line
-bdf <cpptestscan.bdf>
switch to cpptestcli
.cpptestcli -data "</path/to/workspace>" -resource "<projectname>" -config "team://Team Configuration" -localsettings "</path/to/name.properties>" -bdf "</path/to/name.bdf>"
cpptestcli -data "</path/to/workspace>" -resource "<projectname>" -localsettings "</path/to/name.properties>" -bdf "</path/to/name.bdf>"
cpptestcli
using the -localsettings
switch. Settings can be specified in the options file as described in Local Settings (Options) Files.Examples
cpptestscan
. They use C++test’s ATM example, which is available in the <INSTALL_DIR>/Examples/ATM
directoryAssumptions and Prerequisites
cpptestscan
executable should be included on $PATH (it is located in C++test's installa-tion directory).cpptestcli
executable should be included on $PATH (it is located in C++test's installa-tion directory).g++
is assumed to be the original compiler executable./home/MyWorkspace on UNIX/Cygwin
c:\home\MyWorkspace on Windows
c:/home/MyWorkspace on Cygwin
-config
-config Must-HaveRules
).Example 1 - Creating a C++test project in the workspace location with default settings
<INSTALL_DIR>/Examples/ATM
directory.cpptestscan
executable:> make CC="cpptestscan g++" clean all
(cpptestscan.bdf)
was created in the <INSTALL_DIR>/Examples/ATM
directory./home/MyWorkspace
workspace:> cpptestcli -data /home/MyWorkspace -bdf cpptestscan.bdf
<INSTALL_DIR>/Examples/ATM
project.Example 2 - Creating a C++test project in original project's location with "Visual C++ 7.1" set as the compiler and "myProject" set as the project name
<INSTALL_DIR>/Examples/ATM
directory.cpptestscan
executable:> make CC="cpptestscan --cpptestscanProjectName=myProject g++" clean all
(cpptestscan.bdf)
was created in the <INSTALL_DIR>/Examples/ATM
directory. Notice that myProject
was set as project name.opts.properties
in <INSTALL_DIR>/Examples/ATM
.bdf.import.compiler.family=vc_7_1
into the opts.properties
file.cpptestscan.bdf
file (which is located in the original project's directory) by entering:bdf.import.location=BDF_LOC into opts.properties file
/home/MyWorkspace
workspace:cpptestcli -data /home/MyWorkspace -bdf cpptestscan.bdf -localsettings opts.properties
BDF_LOC
variable was used as the project location; this refers to the cpptestscan.bdf
file's location