BDF working directory

Hello @chris,

The bdf uses hardcoded path by design to prevent any issue that could be caused by using a relative path. Are you planning on frequently moving your project's working directory to a different location?

You can use the same bdf for importing the project into different workspace if desired. Are you using C++test Professional Edition or C++test Standard Edition. How are you importing your bdf into your workspace? Are you using a GUI or command line to import the bdf.

A quick example of how you can reference the same bdf to import the same project into multiple workspaces. An example is below on how you can use the same bdf to import your project into different locations.

C++test Professional Edition CLI command:
cpptestcli -workspace OriginalWorkspace -bdf /PATH/TO/cpptest.bdf

C++test Standard Edition CLI command:
cpptestcli -data NewWorkspace -input /PATH/TO/cpptest.bdf

Let me know if you have any other questions.

Hi @chris,

If you wish to use .bdf the user will need to make another bdf so that we can get the hardcoded path of the new working directory of this project. You can quickly generate a bdf file by using the following command:

cpptesttrace --cpptesttraceOutput=/PATH/TO/cpptest.bdf

This would be the easiest way to address this issue. How many developers are planning on working on this project. If it's a small team we could

Additionally, you can use different Options Source settings to collect information from your build settings so C++test is configured with your project.

You can modify your Options Source by right-clicking your project and select Properties -> C/C++test -> Build Settings and click at the top of the page to choose different build options.

Use options from a build system

The default Build Command line will look like the following:

make -i -B CXX=${CPPTEST_SCAN} CC=${CPPTEST_SCAN} LD=${CPPTEST_SCAN}

This will ignore all errors during the built process and built your project unconditionally.

CXX is use a default environment C++ compiler environmental variables.
CC is used as a default environment C compiler environmental variables.
LD is used as a default environmental Linker variables.

We use ${CPPTEST_SCAN} as a wrapper for cpptestscan

Original Values within ATM example project:

CC=gcc
CXX=g++
LD=g++

This will be transformed into the following to create smaller bdf that C++test will reference.

make -i -B CXX="cpptestscan --cpptestscanOutputFile=${WORKSPACE}/.cpptest/ATM/common-catergory/cpptestscan.bdf --cpptestscanProjectName=ATM --cpptesttraceRunOrigCmd=off"
C="cpptestscan --cpptestscanOutputFile=${WORKSPACE}/.cpptest/ATM/common-catergory/cpptestscan.bdf --cpptestscanProjectName=ATM --cpptesttraceRunOrigCmd=off"
LD="cpptestscan --cpptestscanOutputFile=${WORKSPACE}/.cpptest/ATM/common-catergory/cpptestscan.bdf --cpptestscanProjectName=ATM --cpptesttraceRunOrigCmd=off"

This would append to our original gcc and g++ build command to generate multiple bdf within your project's workspace.

This is more difficult than generating a bdf for each user because it will require the user to have a greater understanding of their build system to implement. If regenerating a new bdf for each user is not a viable solution you can use this approach instead.

You can import the project with the Parasoft Build Settings information saved (within the .parasoft file) so that any developers in your team can import the project can quickly run C++test.

I hoped that this answered your question please let me know if you have any other questions regarding C++test.

Hi @chris,

In addition to the suggestions provided by MichaelC, you can consider one more solution. There is an option in the cpptesttrace utility that allows you to replace a specific string in the bdf with a variable. This can be used for example to replace a fixed part of the path with a sort of "ROOT" variable.

Using our default ATM example, it would look like this:

cpptesttrace --cpptesttraceUseVariable=ROOT="D:\Program Files\Parasoft\C++test\10.4\examples" make clean all

Here I assume that "D:\Program Files\Parasoft\C++test\10.4\examples" is a "root" directory of my project and it can look differently on other developer machines.

Once this command is executed we get a bdf that looks like:

------- cpptestscan v.10.4.2.20190408B2041 (cpptesttrace) -------
working_dir=${ROOT}\ATM
project_name=ATM
arg=C:\cygwin\bin\g++.exe
arg=-g
arg=-Iinclude
arg=-o
arg=obj/ATM.o
arg=-c
arg=ATM.cxx

And here is the bdf generated with default settings:

------- cpptestscan v.10.4.2.20190408B2041 (cpptesttrace) -------
working_dir=D:\Program Files\Parasoft\C++test\10.4\examples\ATM
project_name=ATM
arg=C:\cygwin\bin\g++.exe
arg=-g
arg=-Iinclude
arg=-o
arg=obj/ATM.o
arg=-c
arg=ATM.cxx

In the next step, all developers importing the project will have to have the ROOT variable defined in their environments to point to their locations of the workspaces.

This makes the setup more portable. But as Michael explained, there can be some issues if bdf is not maintained or updated correctly. "Shared" bdf can be generated as a part of the CI process for example and checked in every night, but in some cases, developers testing their local changes will have to regenerate the bdf local to update it with their modifications that are not yet checked in but require testing.