In order to perform static analysis or unit testing, C++test must collect the following information from your Wind River project:

This information is taken from the Wind River Workbench project structure description and collected by scanning the automatically-generated make files. This process involves the following steps:

  1. You start the C++test Test Configuration.
  2. The C++test plugin internally activates the build process of the tested project and forces regeneration of the existing make files.
  3. When Workbench starts regenerating the make files, the C++test plugin automatically generates the command lines with the option scanning utility, which is used to prefix the compiler calls.
  4. After the make files are regenerated, the actual build process is started—but instead of using the actual compilation/linking command lines, the make file executes the command lines pre-fixed with the option scanning utility. The command line is generally modified as follows:
  5. The option scanner analyzes the command line and stores the following data for further reuse:

After the build process is completed, C++test will have all the necessary data collected.

Depending on the selected C++test use model, you may test your Workbench projects directly or test your source through "Test Projects." In both cases, the general idea behind the process of collecting compilation/linking flags stays the same.

According to the typical make utility behavior, the rule for a given target is performed only when make determines that the product actually needs to be rebuilt. For example, if the test.c source file has an up-to-date object file test.o, then the compilation rule for this file won’t be started. This has significant implications for the options scanning process: if you start C++test analysis (which involves options scanning) on a project that has a current build and has all up-to-date binary files, then the make file won’t execute the compilation or linking command lines... and C++test won’t be able to collect the necessary information. To prevent this, modify the make file command line so that C++test can automatically add the  "-B" option to the make call; this forces make to unconditionally build all targets. To do this:

  1. Right-click the project node, then choose Properties from the shortcut menu.
  2. Select Build Properties.
  3. Go to Build Support and Specs.
  4. In the Buildcommand text field, modify the make file command line by relocating the %makeprefix% marker after the “make” command. For example: make %makeprefix% --no-print-directory.



This modification will allow C++test to replace %makeprefix% with the necessary “-B” flag only when the reading options action is necessary. The original build process will be left unchanged. To avoid having to manually make this changes for every project, you can modify the default of the command line template for make. For more details on how to do this, see Configuring the Wind River Workbench Environment for the C++test Plugin.

If the %makeprefix% marker is already used for a different purpose in your environment, then you can hardcode the “-B” flag in the make command line pattern (%makeprefix% make -B –no-print-directory). This solution has a significant disadvantage: you will probably need to periodically modify the command line template by adding the “-B” flag for testing sessions and then removing it for production builds.

Optionally, you can run analysis on a cleaned project. With this approach, you will need to call the clean action before every test action because the option scanning will also produce project binary targets.

After options scanning and analysis is completed, C++test forces the regeneration of the make files without inserting anything to recreate the original state of your project.

This modification, which will ensure proper project refreshing, should be used for both directly testable Wind River Projects as well as for all projects that are included in the test project.

Known Workbench 3.1-3.3 problem: Workbench allows "Build command" adjustment at the project creation stage (new project wizard, "Build Support" page). However, if any adjustment of
"Build Specs" is made along the way in versions 3.1-3.3, the new command isn't preserved. Instead, the default one still shows up in project's properties.

We recommend that you work with C++test using the Wind River Workbench Application Development Perspective.

Working in this way allows you to select the resources which are not visible in the C++test or C/C++ CDT perspective, and prevents problems with Wind River build information becoming out of date.

If you choose to work with another perspective, note that it has been observed that if the C++test perspective is the first perspective opened after starting Workbench, some internal workbench build information will not be loaded. As a result, scanning the make file may not produce the desired results. The suggested approach is to switch to the default Application Development Workbench perspective (which allows Workbench to load its internal data) and then switch back to the C++test perspective to continue the analysis. This procedure should be performed every time you start Workbench for the given project. You should also ensure that you are in the Application Development perspective when you create new projects.