Configure Sources and Build Options in Project for Polyspace Analysis and Testing

R2026b

Before running static analysis or tests with Polyspace Platform projects, you must configure the build options to accurately represent your build environment — compiler, target processor, preprocessor macros, and include paths. You can set sources and build options in one of the following ways:

Configure sources and build options using your build system — This is a fully automated approach, and can be used directly in continuous integration systems. You do not need to know the inner workings of your build system. All you need is a working build command (or a compilation database if your build system generates one).
Configure sources and build options manually — Specify your sources, includes, and build options manually in a project or options file. You can find Polyspace^® options that are equivalent to your compiler options using a semi-automated approach.

Create Project or Options File from Compilation Database or Build Command

The recommended approach is to use polyspace-configure to automatically extract source files, build options, and target configuration from your build system into a Polyspace Platform project or options file. You can provide your build information to polyspace-configure in two ways:

Using a compilation database (if your build system supports creation of a JSON compilation database).
Using a build command.

When possible, providing a compilation database is the recommended approach. Unlike the build command approach, which requires polyspace-configure to track processes and find the compiler invocations, the compilation database approach is faster and has fewer limitations because polyspace-configure simply reads compiler invocation commands from a file.

For information on how to invoke polyspace-configure in the Polyspace Platform user interface, see Create Polyspace Platform Project from Build Command in User Interface.

Create Project from Compilation Database

If your build system supports generation of a JSON compilation database (for instance, CMake with -DCMAKE_EXPORT_COMPILE_COMMANDS=ON), you can pass it directly to polyspace-configure:

polyspace-configure -output-platform-project myProject -compilation-database compile_commands.json

The compilation database contains the exact compiler invocations used to build each source file. The polyspace-configure command reads these invocations and extracts the corresponding Polyspace options. The main limitation of this approach is that not all build systems support compilation database generation.

For an example, see Create Polyspace Platform Projects from CMake Builds.

Create Project from Build Command

If your build system does not support compilation database generation, you can run polyspace-configure on your build command directly. The command traces all processes spawned by the build, identifies compiler invocations among them, and extracts the corresponding Polyspace options.

polyspace-configure -output-platform-project myProject make -B <targetName>

Because this approach relies on tracking processes on the build machine, it has some limitations. For instance, antivirus software and firewalls can block process tracking, the build must run locally to completion, and distributed builds and compiler caches are not supported. For details, see Requirements for Polyspace Project Creation from Build Systems.

For examples, see:

Configure Build Options Manually

If you cannot use polyspace-configure with your full build command or compilation database, you must configure the build options manually. Unlike the automated approach where polyspace-configure uses your actual build to determine the correct options, manual configuration requires you to identify and map your compiler settings to Polyspace options yourself. Ensure that you verify your mapping carefully, as incorrect settings can lead to inaccurate analysis results.

You can still use polyspace-configure to assist with parts of this process, rather than doing the entire mapping manually. If you can determine the compile commands used in your build and deduce a common set of compile options used in the commands, you can invoke polyspace-configure on the compile command launched with those compile options, and find the equivalent Polyspace options.

Determine Polyspace Options from Single Compiler Invocation

Even if you cannot run polyspace-configure on your full build, you can still use it as a starting point to determine Polyspace options equivalent to a single compiler invocation.

To do this:

Determine which compiler executable your build calls and the common set of compiler options used across your source files. You can typically find this information by examining the log output of your build system (some build systems require you to specify an option to print this log).
See Compiler Executable Names for Common Compilers and Architectures for a list of common compiler executables and typical options.
Run polyspace-configure on that compiler invocation with a single source file and the -no-sources option (so that no source files are included in the generated options file):
```
polyspace-configure -no-sources -output-options-file psoptions.txt <compiler> <flags> <source-file>
```
For example, if your build uses arm-none-eabi-gcc with hardware floating-point options, you can enter the following command:
```
polyspace-configure -no-sources -output-options-file psoptions.txt arm-none-eabi-gcc -mfloat-abi=hard -mfpu=neon-fp-armv8 -c main.c
```
From the resulting options file, use the -compiler, -custom-target, and the compiler implicit defines and includes (the -D and -I options) in your project configuration.
For more information on the options, see:

If different source files in your project are compiled with different compiler options that materially affect target characteristics (for instance, different GCC -march flags that change type sizes), this approach might produce incorrect settings for some files. This is typically not the case — most projects use a common set of target-affecting flags across all files. However, for the most accurate results, running polyspace-configure on the full build remains the best approach; single-invocation is a fallback when the full build is not available.

Determine Polyspace Options from Documentation

If polyspace-configure does not support your compiler at all, you must determine the correct Polyspace options entirely from documentation. This is the most manual process. You must read both your compiler documentation and the Polyspace reference documentation to map your compiler settings to the corresponding options:

Compilation toolchain for static analysis (-compiler) — Select the Polyspace compilation toolchain that matches your compiler.
If you also run tests using Polyspace Test™, set the actual compiler value for the option Compilation toolchain (Testing) (Polyspace Test) and set the static analysis compiler value to Same as testing toolchain. The value Same as testing toolchain is available only if you run static analysis and tests using a Polyspace platform project.
Processor (-custom-target) — Specify type sizes, endianness, and alignment for your target.
Preprocessor definitions (-D) — Define macros that your compiler predefines.
Include paths (-I) — Specify paths to your compiler includes.

For more information on all build options, see Polyspace Bug Finder Options in Polyspace Platform User Interface.

Compiler Executable Names for Common Compilers and Architectures

The following table lists common cross-compiler executables and typical compiler options that affect target characteristics. If you are setting your build options manually, use this information to identify the compiler invocation for use with polyspace-configure, or as a starting point for manual configuration.

Compiler	Architecture	Compiler executable	Common compiler options
GNU Arm Embedded Toolchain (GCC)	ARM (32-bit)	`arm-none-eabi-gcc`	`-mfloat-abi=hard -mfpu=neon-fp-armv8 -c`
Arm Compiler (armclang)	ARM (32-bit)	`armclang`	`--target=arm-arm-none-eabi -march=armv8-a -c`
Arm Compiler (armclang)	ARM (64-bit / AArch64)	`armclang`	`--target=aarch64-arm-none-eabi -march=armv8-a -c`
TI ARM CGT Clang	ARM (32-bit)	`tiarmclang`
IAR Embedded Workbench	ARM	`iccarm`	`-e`
IAR Embedded Workbench	RISC-V	`iccriscv`	`--core=RV32MADXandesdsp -e`
IAR Embedded Workbench	RH850	`iccrh850`	`-e`
IAR Embedded Workbench	RL78	`iccrl78`	`-e`
IAR Embedded Workbench	AVR	`iccavr`	`-e -v4`
Hightec GCC	TriCore (Infineon)	`tricore-gcc`
Hightec GCC	MSP430	`gcc-msp430-none`
Wind River^® Diab	PowerPC 64-bit	`dcc`	`-tPPCLP64FH:windiss`
Renesas^® CC-SH	SuperH	`shc`	`-cpu=sh4aldsp -dspc -lang=c`
Renesas CC-RX	RX	`ccrx`	`-isa=rxv2 -lang=c99`
Renesas CC-RH	RH850	`ccrh`
Renesas CC-RL	RL78	`ccrl`	`-cpu=S3`
Texas Instruments^® CGT	ARM	`armcl`	`--float_support=VFPv2 -mv6`
Texas Instruments CGT	C6000 (DSP)	`cl6x`	`--silicon_version=6600`
Texas Instruments CGT	MSP430	`cl430`	`--silicon_version=mspx`
Texas Instruments CGT	C2000 (C28x)	`cl2000`	`-I <ti-cgt-c2000>/include/`
Cosmic	S12Z	`cxs12z`
Microchip XC32	PIC32 (MIPS)	`xc32-gcc`	`-mprocessor=32MX795F512L`
Microchip XC16	PIC24 / dsPIC	`xc16-gcc`	`-mcpu=33FJ256GP710`
Microchip XC8	PIC10/12/16/18	`xc8`	`--chip=16F1947 --std=c99`
Cadence Tensilica XT-CLang	Xtensa	`xt-clang`	`--xtensa-system=<config_path>`
Microsoft^® Visual C++^®	x86-64	`cl`	(run from VS Developer Command Prompt)
LLVM Clang	x86-64 / ARM / AArch64	`clang` / `clang++`	`--target=<triple>`
Intel^® C++ Compiler	x86-64	`icc`