Is it possible to create a project file specifically for Bug Finder or Code Prover?

I am creating .psprj files for Bug Finder and Code Prover (different options and checks) using a script to be opened with the Polyspace GUI to run the analysis and check the results manually.

The proplem is now that one has to manually select the correct "Run Bug Finder" or "Run Code Prover" to run the analysis which is error prone an cumbersome.

Is it possible to embed the information about which tool is supposed to be used in the .psprj file or some other workaround?

Answer 1

[Anirban]

The .psprj files are meant for running both Polyspace products, therefore, as far as I understand, there is no way to specify product information in this file. Even though Bug Finder and Code Prover support different options, you can have both sets of options in the same .psprj file. If you run Bug Finder, the Bug Finder options come into play. If you run Code Prover, the Code Prover options come into play.

The only reason to have a separate project for running the two products would be if the same option required a different value for Bug Finder and Code Prover. Is that happening in your case? Could you give an example of an option that requires different values for running the two products?

All this said, you could generate scripts from the .psprj and those scripts could be meant for a particular product only. See Configure Polyspace Analysis Options in User Interface and Generate Scripts. When generating the script, you can use an option to specify which product must run when the script is executed (-bug-finder for Bug Finder scripts and no option for Code Prover scripts).

You can also write a script from scratch to completely run the analysis at the command-line and open the results using a .bat file for instance. The end-users will have to double-click the .bat file and the analysis will run on its own finally opening the results. In this case, you can specify which product to run. For instance, you can use the command polyspace-bug-finder to run Polyspace Bug Finder. See Run Polyspace Analysis from Command Line.

[Peter Bauer]

thank you for the quick response!

• Here are the different options files for Bug Finder and Code Prover. I haven't tried to "merge" them but there are for sure tool-specific options in there and we keep them in separate options files:

### Bug Finder-specific options ###
-code-metrics
# read the Misra C:2012 checks configuration from a file (--checkers-file)
-misra3 from-file
# diabled buildin checks
-disable-checkers NON_POSITIVE_VLA_SIZE
-disable-checkers PTR_TO_DIFF_ARRAY

### Code Prover-specific options ###
# produce stack usage metrics
-stack-usage

-main-generator
-main-generator-writes-variables public

• The current implementation is a script that generates a .psprj files and starts the Polyspace GUI with the respective .psprj file so the users can quickly re-run the analysis after changing the code or adding a justification. So the idea is to not run the analysis automatically by the script. As i understand it the scripts that can be generated as you described it also execute the analysis and afterwards open the results?

[Anirban]

Thanks for the examples! Yes, you can merge the options files and create a single project. Notice that the options you have given are mutually exclusive, so they will not conflict with each other. But there might be a better option.

In a project, you can have several modules (indicated by a <module> element in the psprj). In a module, you can have several configurations (indicated by an <optionset> element in the psprj). You can create either two separate modules, or two separate analysis configurations - one that corresponds to a Bug Finder analysis and another to the Code Prover analysis. That way, your project will still have the clean separation you want. This will still not achieve what you are asking for: namely for the Run button to change to 'Run Bug Finder' or 'Run Code Prover' automatically (as of the current release, this is not possible, but please contact Technical Support in case they have an undocumented way to do this). But at least, you have the separate options files mapped to separate entities in the project. You can use the 'name' attribute of the <module> or <optionset> element to remind your end-users which product they should run.

However, I am still a bit unclear on why you want to create projects in the first place. I would understand if your starting point was a project and you want to share that project. But it looks like your starting points are options files. Since you already have the options files, it sounds like the best approach would be to write scripts that can run the polyspace-bug-finder or polyspace-code-prover command on the relevant options files. Though the scripts would run the analysis and open results, it would do so only after users run them. Users can do so after changing their code, and so on. If they wanted to rerun the analysis, they would just rerun the scripts. (Running a script can be a double-click of a .bat file or selecting a menu item in an IDE if you make the scripts accessible from the IDE - most IDEs allow running of external scripts on current files or IDE projects.)

One reason you want to create projects is that maybe you want users to see the configuration used for the analysis (the configuration in its GUI form). If that is the case, there is a way to do that after the results are opened. On the Dashboard pane in the results, there is a link titled Configuration. Clicking on the link shows the GUI form of the configuration used for the current results.