Share Polyspace Platform Projects, Workspaces, and Configurations

Polyspace Platform is an integrated environment that supports static analysis and dynamic testing of C/C++ code with Polyspace^® products. In the Polyspace Platform user interface, to analyze or test C/C++ code, you start by creating a project. You can then perform the following actions on this project:

Add source files.
Set options for building project or code analysis.
Add tests (graphical tests or C/C++ xUnit tests), build and run them.

This topic describes how to create a Polyspace Platform project that is portable across different computers and can be used by multiple users.

Create Easily Shareable Projects

A project in Polyspace Platform points to resources such as source files, include folders, test files, and so on. To make projects easily shareable, follow these rules:

Ensure that the relative paths between a project file (.psprjx file) and its linked resources is preserved across different computers. To see an example folder structure:
1. In the Polyspace Platform user interface, open an example project by selecting Create and run functional tests on the Start Page pane.
2. On the Projects pane, right-click the folder name below the Code node of the project and select Open Folder.
3. Navigate to the parent folder Getting_Started_Example from the folder you opened. This folder contains the example project Demo_C_PS_Test.psprjx. The subfolders sources, tests, and includes contains the source files, test files and include files respectively.
Alternatively, you can ensure that each resource has the same relative path with respect to a root path across different computers. You can use this root path as a variable in the project.
When adding resources to a project, make sure that you add them by relative path or using variables.
Make sure you do not have absolute paths to resources in the project unless the absolute paths are network locations accessible by all users of the project.

Add Resources by Relative Path

If a project points to the resources using relative paths, you can easily share the project along with the linked resources, using a zipped archive or using source control management. The projects will continue to point to the correct version of the resources as long as their relative paths stay unchanged.

If you add resources to a project using buttons on the Polyspace Platform toolstrip or right-click actions on project nodes, the project points to the resources by their relative paths. The resource path is relative to the project file (.psprjx file) path.
If you add resources from your project configuration, you can add by absolute path or relative path.
For instance, you can add source files from your project configuration. On the Project tab, the option Application Source Files allows you to add source files by absolute or relative path.
You can select to add the absolute path to a source file or select to add a source file relative to the project path. For more information, see Application source files (Polyspace Test).

Add Resources Using Variables

Another way to make projects shareable is to use system environment variables in resource paths.

Define a system environment variable for the root path to your resources.
When adding resources such as sources, tests, and includes to your project, use this variable name enclosed in $() in place of the root path.
To use system environment variables in resource paths in the user interface, add absolute paths to the resources from your project configuration and then replace the root path with the system environment variable. You can also add paths that contain system environment variables using the Polyspace Test™ Python API. For more information, see Workflow Automation Using Python API (Polyspace Test).

For example, say you set a system environment variable SRC_ROOT_PATH to E:\repo. In the Project tab, add $(SRC_ROOT_PATH)\src\moduleMathLibs to the field Application source files instead of E:\repo\src\moduleMathLibs. If another user using the same project refers to the same sources and tests on a different root path, they can have the system environment variable SRC_ROOT_PATH set to their own root path and continue using the project.

Instead of system environment variables, you can also use project variables in resource paths. A project variable is a variable that is defined in the project and can be used in the same way as a system environment variable.

On the Project tab of your project configuration, for the option Project Variables, enter a variable name and the root path to your resources as its value.
In a typical case, you might define a project variable starting from a system environment variable and appending to it. For instance, suppose you define a system environment variable SRC_ROOT_PATH but all your include folders are in an includes subfolder in this path. You can define a project variable INCLUDE_ROOT_PATH with a value $(SRC_ROOT_PATH)\includes and then use $(INCLUDE_ROOT_PATH) as a root path for the option Include paths.
When entering values for options such as Application source files and Include paths, replace the root path with the variable name in $().

For more information, see Project variables.

Support for Relative Paths and Variables

The following options support relative paths and variables. Note that for a small subset of the options that support relative paths, you do not have a button in the project configuration to add a resource by its relative path. Instead, you can type the relative path to the resources or add resources to the project by other means such as by using the Polyspace Test Python API.

Option	Are Relative Paths Supported?	Are Variables Supported?
`Application source files` `Application source folders`	Yes	Yes
`Polyspace xUnit test files` (Polyspace Test) `Polyspace xUnit test folders` (Polyspace Test)	Yes	Yes
`External test files` (Polyspace Test) `External test folders` (Polyspace Test)	Yes	Yes
`Include paths (-I)` `Additional include paths (-I)` `Include paths for external tests` (Polyspace Test)	Yes	Yes
`Library paths` (Polyspace Test) `Library paths for external tests` (Polyspace Test)	Yes	Yes
`Folders to profile (-limit-instrumentation-to)` (Polyspace Test) `Folders to ignore (-ignore-dir)` (Polyspace Test) `Files to ignore (-ignore-file)` (Polyspace Test)	Yes	Yes
`Do not generate results for (-do-not-generate-results-for)` `Generate results for sources and (-generate-results-for)`	Yes	Yes
`OIL files selection (-osek-multitasking)` `ARXML files selection (-autosar-multitasking)`	Yes	Yes
`Forced includes (-include)`	No	Yes
`Command/script to apply to preprocessed files (-post-preprocessing-command)` `Command/script to apply after the end of the code verification (-post-analysis-command)`	No	Yes

Share Projects, Workspaces and Configurations

You can share projects and linked resources using a zipped archive or submit projects (.psprjx files) to source control management just like any other code. If your project refers to resources such as source and test files by relative paths, the best way to keep the project in sync with its resources is to submit both to a version control system.

You can also submit the following kinds of files to source control:

You can submit Polyspace Platform workspaces (.pswks files) containing multiple projects to a version control system along with the projects themselves. Since workspace files point to project files by relative paths, submitting both workspaces and projects to version control ensures that they stay in sync. For more information on workspaces, see Manage Related Projects in Polyspace Platform User Interface Using Workspaces (Polyspace Test).
You can extract Polyspace configuration files (.pscfg files) out of a project and maintain them separately in version control. For more information on external configurations, see Configure Project for Static Analysis in Polyspace Platform User Interface.

You can interact with a Polyspace Platform project file (.psprjx file) in a version control system like any other file. In particular, you can perform the following actions:

Check out the project file from version control.
Open the project in the Polyspace Platform user interface.
Make necessary changes to the project, for instance:
- Add source files.
- Add new tests.
- Change configuration options.
Verify the changes, for instance:
- Make sure that the project continues to build successfully.
- Run tests to make sure they pass.
- Run static analysis to make sure that new bugs have not been introduced.
Submit the modified project to the version control system.
Prior to submission, you can do the following:
- Compare your version of the project with the version in source control.
- Resolve merge conflicts between your project and the latest version in source control.
Polyspace Test provides a user interface for comparing and merging projects. You can integrate this user interface with your source control management (SCM) tool so that the actions of comparing and merging the project in your SCM tool opens this user interface. For more information on how to open and use the interface, see Compare and Merge Polyspace Platform Projects and Configurations Before Submission to Source Control (Polyspace Test).