Create Easily Shareable Projects for Version Control

Polyspace Platform is an integrated environment that supports static analysis and dynamic testing of C/C++ code with Polyspace^® products. To create a project that is easy to share and works well in version control systems, add resources to the project using relative paths or variables and modularize the project by separating it into multiple files. You can submit your Polyspace Platform project file and other supporting Polyspace files to version control along with your C/C++ source code. For more information on which files to submit, see Submit Polyspace Files to Version Control.

Add Resources Using Relative Paths or Variables

To create a Polyspace Platform project that is portable across different computers and can be shared by multiple users, use relative paths and variables when adding resources such as source files, include folders, and tests. Use absolute paths only if the resource is in a network location accessible by all users of the project.

Add Resources by Relative Path

When a project points to its resources using relative paths, you can share the project and linked resources by using a zipped archive or by submitting to a version control system. The project continues to point to the correct versions of its resources as long as their relative paths do not change.

• If you add resources to a project by 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) path.

• If you add resources from your project configuration, you can add by absolute path or relative path.

  For instance, on the Project tab of the project configuration, the Application Source Files option allows you to add source files by absolute or relative path.

  

  Use the add file button to add the absolute path to a source file or click the add file as relative path button to add a source file relative to the project path. For more information, see Application source files.

Add Resources Using Variables

Another way to make projects shareable is to add resources using variables. You can use system environment variables that apply to all projects or project-specific variables.

System Environment Variables.  To use system environment variables in resource paths:

1. Define a system environment variable for the root path to your resources.

2. Use this variable name enclosed in $() in place of the root path when adding resources such as sources, tests, and include files to your project.

   To use system environment variables in resource paths in the Polyspace Platform user interface, add absolute paths to the resources from your project configuration and then replace the root path with the system environment variable.

For example, if you set the system environment variable SRC_ROOT_PATH to E:\repo, add $(SRC_ROOT_PATH)\src\moduleMathLibs to 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 set the system environment variable SRC_ROOT_PATH to their own root path to continue using the project.

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).

Project Variables.  Instead of system environment variables, you can 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.

1. 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.

2. 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

Most options support the use of relative paths and project variables. 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 using the Polyspace Test Python^® API.

The following options do not support relative paths:

• Forced includes (-include)

• Command/script to apply to preprocessed files (-post-preprocessing-command)

• Command/script to apply after the end of the code verification (-post-analysis-command)

• Other

Modularize a Polyspace Platform Project

Since R2026a

When a single Polyspace Platform project file contains all configurations and graphical test cases, sharing and collaborating on that project can be difficult. By modularizing, or separating your Polyspace Platform project into multiple files, you can improve version control workflows, make it easier to collaborate on large projects, and share single-sourced components across related projects. When you modularize a project, instead of being a single .psprjx project file that contains all configurations and graphical tests, the project file is a container that stores references to external configuration, test, and code files and defines how these components are combined for analysis and testing.

By default, Polyspace creates project-specific configurations and graphical tests that are saved in the Polyspace Platform project file (.psprjx). To modularize your project, convert these project-specific components into external files that the project references:

• Configurations — Extract a build, static analysis, or testing and profiling configuration from a project by converting it to an external .pscfg configuration file that is referenced by the project. For more information on .pscfg configuration files, see Share and Reuse Configuration Variants.

• Graphical tests — Extract Polyspace Test graphical tests from a project by converting them to test references. A test reference is a .pstestd file that is referenced by the project. For more information, see Modularize Project by Converting Graphical Tests to Test References in Polyspace Platform User Interface (Polyspace Test).

• Stubs for undefined functions and variables — In Polyspace Test, instead of using stubs that are defined and saved in the .psprjx project file to work around undefined functions and variables, you can define your stub implementations in C/C++ files. For more information see Stub Undefined Callees Using External Files (Polyspace Test)

To learn which Polyspace files you need to submit to your version control system, see Submit Polyspace Files to Version Control. For an example of how to use the Polyspace Test Python API to modularize a project, see Modularize Existing Project by Using Polyspace Python API (Polyspace Test).