Polyspace - Relative Paths for command line build

I am trying to setup Polyspace for command line build in our project.

That part seems to already be done. Thank you very much.

The problem comes if we have mutliple users build the project, the paths would all point to my home directory.

The options.txt and other necessary files have fixed paths.

So, is there a way to use relative paths in the files for command line build or does each user need to set up Polyspace for his/her environment?

Thank you,

Answer 1

[Anirban]

Just to confirm, the workflow you are envisioning is this: you run polyspace-configure on your build command and share the generated Polyspace options file with others. They will then run polyspace-bug-finder or polyspace-code-prover using your Polyspace options file. You are running into the problem that the -sources lines in the options file uses absolute paths to source files.

You can write a simple search-and-replace script that takes the path to your root directory and replaces it with another root directory. Users who receive your Polyspace options file can run the script to replace the root and create a modified options file (or the script can be made to run automatically on certain triggers such as checking out from an SCM tool).

Just to let you know, the intended usage is: polyspace-configure and polyspace-bug-finder or polyspace-code-prover are meant to be run as a pair by every end user. So like this:

polyspace-configure -output-options-file options.txt buildCommand

polyspace-bug-finder -options-file options.txt

The reason is, the end users might be adding new source files which would not be captured by an options file that was created earlier and shared.

Of course, I understand that adding new source files is not a frequent event, and you probably have other ways to keep the Polyspace options file updated for new source file addition. In that case, a search-and-replace script like the above would be the best way to go.

[Chris Holland]

>>Just to confirm, the workflow you are envisioning is this: you run polyspace-configure on your build >>command and share the generated Polyspace options file with others. They will then run polyspace-bug->>finder or polyspace-code-prover using your Polyspace options file. You are running into the problem >>that the -sources lines in the options file uses absolute paths to source files.

Correct

I got the answer the other day from another one of your colleagues.

On the tool bar next to the green arrow "Run Bug Finder", there is a small drop down arrow.

Click that, then enable "Create new Bug Finder Results folder".

That way, the "BF_Results" folder that I edited, will not be over-written.

Once that is done, I edited the path to be relative to Polyspace ie. "..\" C:\some_path\MyProject\Polyspace

Now, each user that pulls down the project to his/her workspace can run launchingCommand.bat from the .settings directory.

Tada.

Thank you,

[Anirban]

Thanks for the reply here. I did not realize you were going through the route of a Polyspace project. My impression was that you had created an options file with polyspace-configure, and were sharing the options file and a script for a command-line workflow.

I just wanted to make you aware of one subtlety. Since I am not aware of the details of your workflow, this subtlety might not apply to you, but stating the detail here for other readers. When you run polyspace-configure, the command traces the build and creates a project (or options file, if you specify -output-options-file). The project (or options file) contains a reference to all the sources, and also associates with each source, all include paths and additional options required to compile the source (see -options-for-sources). Now, let's say you share the project with another user. When the user adds a new file to the project, the new file gets added but not the associated options for compiling the file. Therefore, the new file might not compile. That is why, one needs to run polyspace-configure and the subsequent Polyspace analysis as a pair when a new file is added.

This subtlety might not matter in practice because if all files are compiled using the same include paths and additional options, the generated project knows this and uses the same options for all files. Then, when a new file gets added, it continues to be compiled using the same options. If your workflow continues to work when a new file is added (without having to rerun polyspace-configure), then you do not need to be worried about the subtlety.