BDF working directory

chrischris Posts: 9

Hi, I created my bdf and everything works as it should. However, i notice in the .bdf file the working directory has an absolute directory, eg working directory = /home/chris/workspace1/projname/
Is there are smart way to update the the .bdf file to have a relative path so if I open my project in a new workspace it will still work. My bdf is located in /home/chris/workspace1/projname/Parasoft/cpptest.bdf so i updated the bdf file's working directory to ../../projname but i don't like using ../.. either, are there any variables that can be used inside the bdf file?

Comments

  • MichaelCMichaelC Posts: 28 admin

    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.

  • chrischris Posts: 9

    hey @MichaelC, thanks for the reply.
    i am using GUI, so here is my scenario, i have a working project with all my parasoft unit tests and stubs and the bdf file..and as i mentioned before the bdf has my working directory /home/chris/workspace/... so then i push my project to our git repository, now i want a coworker to clone the project from git and using my bdf file should be able to run all the tests but obviously he doesnt have /home/chris/... on his computer, his working directory will be where ever he decides to clone the project, so will he have to manually change the working directory in the bdf file? or are you saying once he imports it in his workspace it will update the file automatically?

  • MichaelCMichaelC Posts: 28 admin

    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.

  • chrischris Posts: 9

    thanks that makes sense we will go with importing of the .parasoft file and also change the bdf to have a relative path. this is working for us now, i have other coworkers running my project and also jenkins running my project with cli.
    Thanks for your help, this discussion can be closed.

  • MirekMirek Posts: 101 ✭✭

    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.

  • chrischris Posts: 9

    @Mirek sweet i like this

Sign In or Register to comment.