Configuring and Building a Project

Learning Objectives

After this section you will be able to:

Configure application projects
Import and export projects
Build a project

Configuring and setting up the VSB and VIP is known as platform development. The next step for your project is application development.

Creating Application Builds

Application development consists of creating features for your project. During project creation, you have a few different application project types to choose from. The available project types are:

User space applications, known as real-time processes (RTPs)
Shared libraries
Downloadable kernel modules (DKMs)
CMake RTPs and CMake DKMs

In the list above you can see there are two versions of RTP and DKM. This is because they can make use of makefile-based projects. If the CMake option is chosen, the developer defines the build structure and writes the makefile for the project.

The alternative is that there is no build type. This makes it so you have platform-specific environment for static analysis. You also have the ability to disable the build.

Creating Application Builds

When making a new application build you have two choices for where to make the project:

Create a project in your workspace:

Create the project folder
Store the settings in the project

Create a project at an external location:

Supports source control scenarios
All source and settings are under source control
The source tree is not contaminated with build output files.

New Project: RTP

When making the RTP you must base the project on one of the following:

A VSB
A VIP
An existing DKM project

Since the VSB is the root of the project, the RTP inherits the build specifications from it. The build target for the RTP looks for executable objects by default, which are:

VXE extensions
Fully linked or linked against shared libraries

New Project: DKM

Creating a DKM uses the same method as an RTP project. The DKM can use the default build settings or inherit them from another project. You can always modify the build command later.

Adding Build Targets

When working on your project you can add build targets to it. You can create an unlimited number of them, just note that one build target will generate one binary. You can customize the source contents for each target along with modifying the build tools.

If you do not specify a build target, no initial build target will be created.

Managing files and folders in Workbench

Now that you have the project types set up, your VSB, VIP, maybe the RTP and DKM. You will want to add some files to them to start development and adding folders to keep the project organized.

Step 1

Choosing a new file or folder

While in Workbench, you can right click in the Project Explorer to open a drop-down menu. Go the tab that says New, this will show you the different file choices.

Step 2

Picking a New File

Making a new file is simple, you pick the template you want or start from a blank file. The defaults you can choose are:

File (Blank File)
File from Template
Class
Header File
Source File

When you make a new file, you can make it directly inside of a project. During creation you have a few options, the first is picking a local name, or create and use a path variable for the file. Once you decided that you can also use the Advanced option to link it to existing files.

Step 3

Adding Folders to Projects

Folders are much simpler than files, when you go to create one you only have two choices:

Folder (Default)
Source Folder

When you pick the option, you will create a name and chose which project type it will be a part of. Then it will appear in the project structure ready for use.

Step 4

Excluding Files and Folders from a Build

When working on your project you might want to exclude a file or folder without deleting them, you can do this in Workbench and do it for each build target. To exclude them, right-click the file or folder under the desired build target and select Edit Excludes.

The example above uses a DKM named myDKM.

With a configured project, you can share it or load it onto your system with importing a exporting.

Exporting and Importing Projects in Workbench

Exporting and importing projects is a time saver and is a valuable skill in Workbench. Exporting is taking your project and archiving it so that Workbench can read it at a later time. Importing is taking the archive you made or someone else made and adding it to your project. Take a look at the features below:

Export Features

Right-click a project and select Export.
Files, settings, and breakpoints export directly to other projects or to *.zip and *.tar files.
Use *.zip and *.tar files to copy or email project files off-system.
You can export the settings and files to pass them from one project to another project on the same system.

Import Features

Select File > Import.
Importing a project copies its existing items into the workspace.
The resources of an existing project within the present workspace are referenced (not copied).
Selected file systems or archive files are copied into the existing project.
Breakpoints are included.
Import a team project set that was previously defined and exported.

Building a VxWorks Project

When we show up to the present moment with all of our senses, we invite the world to fill us with joy. The pains of the past are behind us. The future has yet to unfold. But the now is full of beauty simply waiting for our attention.

Build Properties

When configuring your project, you will need to add build properties to it. There are three main components to the build properties:

Project-specific build targets
A set of build tools, build macros, and build specs suited to the project type
The make command and a makefile

Workbench has predefined settings for specific builds, these include user applications, shared libraries, kernel objects, or OS images. You can change the predefined settings in the project properties, but the settings and values depend on the project type.

To build the project, right-click the project in the Project Explorer to bring up the menu. Here you have two choices:

Build Project- This is the default build type. This is recursively build all selected projects as a subproject of the VSB. If it's the VSB then it will just compile it normally.
Rebuild Project- Rebuilding will clean the project before doing a standard build. Clean is a process where VxWorks will delete all the libraries first to have a fresh start.

Some notable commands in this drop down also include:

Open VxWorks version Development Shell- This will open the VxWorks shell in the project space you selected.
Refresh- When you refresh a project it will update any files that have not registered changes yet.
Close Project- Closing the project will remove all the files from Workbench but leave the root folder for the project. When you open the project, it will repopulate the files back.

In the Build menu you have two options to build from, these are:

Clean Project- This will remove all the object files and any archived files in the project. This is used before checking a project into source control.
Build Enabled Build Specs- This will allow you to build to a custom build spec that you provide the project.

In this menu you can change the active build spec with Set Active Build Spec... and manage it too with Manage Active Build Specs...

That covers how to build a project! This is great but there is one more important thing to discuss, what happens when the build fails?

Build Output and Errors

When a build fails in Workbench, it ends. This will display in the Build Console with a detailed message about why the build failed. This can be logged and saved as output. To go to the error, double click it in the Build Console to open the Editor View.

When an error occurs, it will be highlighted red in three locations, the build console with a detailed message, the line number of the error in the afflicted file, and lastly in the Project Explorer next to the file.