4.3. Extending Existing Wind River Workbench Projects for Ada

You must extend a newly created Wind River Workbench project to support Ada via GNATbench. This need only be done once, before invoking any Ada operations. To extend the project, invoke the contextual menu on the new project node and select “New”, then “Other”, as shown below:


Then select “Convert to an Ada Project” in the resulting dialog and press OK.

conversion wizard for extending project

The first page of the conversion wizard will appear as shown in the next figure. The defaults are as shown (we have arbitrarily named our project “test”).


This first wizard page presents one of the primary extension options: the origin of the GNAT project file.

  • The first option (“The “Use a local GNAT project file” Option”) is used when a GNAT project file is already located within the existing Workbench project. This could be the case, for example, when you have used the Eclipse file system resource importer to bring in files and folders from the external file system (or perhaps via a configuration management system). The point here is that you did not use the GNAT project import wizard to bring in the GNAT project file. The distinction will be clear momentarily.
  • The second option (“The “Import an external GNAT project file” Option”) is applicable if you have an existing external GNAT project (i.e., not a Wind River Workbench project) and want to make it into a Workbench VxWorks project. You direct the wizard to import it by selecting this option, in which case all of the resources defined by the external GNAT project are imported as well – the source files, source and other binary folders (to the extent possible), and so forth.
  • The last option (“The “Create a new GNAT project file” Option”) is applicable if you are creating a completely new project and do not have an existing GNAT project upon which to base it.


When not using the option of creating a new GNAT project file, you are responsible for maintaining the integrity of the GNAT project file regarding the resources it references and the relationships required for the project.

For example, the GNAT project file name must match the Workbench project name. The project will not build correctly if the names do not match. Note that you can simply rename the GNAT project file in the Explorer but that, as a result, you must then edit the file contents so that the project name matches the file name. (The name of a GNAT project file must always match the name of the project within the file.)

Each of the options is discussed in the following sections. Click on the following option names to go to the corresponding description:

4.3.1. The “Use a local GNAT project file” Option

You may either manually enter the name and location of the existing external GNAT project file, or use the “Search Project” button to specify it (click on the option itself if the button is not enabled).

The following figure illustrates the case in which an existing GNAT project file exists in the workspace. In this specific case the GNAT project file already matches the Workbench project name so no changes are required in that regard. In fact, when the wizard was invoked the existing GNAT project file was detected and entered in the text entry pane by default.


Once the project file is specified there is nothing else required for the wizard to convert the project. However, the “Finish” button is not enabled until we actually choose the option we want, even though the radio button indicates the first option.

After conversion, note the presence of the new makefile in the Project Explorer. This is a makefile fragment that will automatically invoke the Ada compiler and other builder tools when the Workbench project builder is invoked. It must not be deleted.

Remember that resources described by the GNAT project file are not created automatically with this option. For example, the project file may specify an “objects” folder. That folder must exist, so you will have to create it if it does not already exist in the workspace project.

You may also need to specify a VxWorks Ada toolchain when using this option. This change will be required if the existing GNAT project file does not specify the toolchain required for the build spec (or build specs) to be used by the project. To make this change, right-click on the project node and select “Properties” from the contextual menu. In the resulting dialog, select “GNATbench Properties”. This selection will show the page in the following figure. We have set the toolchain to use the PowerPC Ada compiler. Remember that more than one toolchain can be selected.


Typically all these potential changes will not be required because the project is already set up but is simply not yet a GNATbench project. A project checked out from a configuration management system would be an example.

4.3.2. The “Import an external GNAT project file” Option

In this case there is an existing GNAT project and project file outside of the workspace that we want to make into a Workbench VxWorks project. Because the Workbench project name and the GNAT project file names must match, we created the Workbench project using that same name, before invoking the conversion wizard.


We then invoke the conversion wizard, select the project to be converted, and select the option to import an external project file:


We can then press the “Finish” button to end this first part of the conversion. Doing so will invoke another GNATbench wizard to finish the process.

The next page presented will ask for the location of the existing external GNAT project file. You can either manually enter the path, or browse for it.


The project will appear as follows, after the wizard finishes:



When importing the GNAT project file, the wizard will attempt to import all the resources it references, such as source folders and files, and binary folders. This same page allows you to specify whether the wizard should copy these external resources into the workspace version of the project, or whether the workspace version should only contain “links” to the resources. Be sure to select the option to copy the resources into the workspace. This choice is necessary as long as “Standard” managed builds are used by GNATbench. The figure above illustrates having selected the option to make a distinct copy. (By default the “linked” resources option is selected.)

If you do accidentally choose the option for “linked” resources, the wizard will honor that request but Workbench will detect that “Standard” managed builds are in use and will warn you accordingly:


A linked project will have little “arrow” decorators attached to the folder and file nodes:


Subsequent build attempts will then fail, as depicted by the following figure:


4.3.3. The “Create a new GNAT project file” Option

This option will have the wizard walk you through the steps of defining a new project, including source and object folders, main program, and so forth. The wizard will then create those files and folders and will create a new GNAT project file accordingly.


Press Finish. Since we chose to create a new GNAT project file, a “new project” wizard is invoked automatically.

In the new wizard’s first page you specify the unit name of the GNAT project. This is not the name of the file, also known as the “gpr file.” Rather, it is the name of the unit inside the gpr file. The name you enter is displayed within a project unit declaration in a text frame, as you enter it, to make clear the use for the name requested.

new project wizard unit name

The unit name need not be the same as the Eclipse project name, but it must be a legal Ada identifier. An error is indicated in the wizard page if this is not the case for the name you enter. The wizard will attempt to convert the Eclipse project name into a legal Ada identifier but might not succeed. In that case you must manually change the name, but, again, the unit name can be different from the Eclipse project name.

Pressing Next takes you to the wizard page for entering the main program unit name:

project conversion ada main subprogram page

Enter the name of the Ada main subprogram – not the file name – and press Next. In this case we have entered the name “test_main”. Note that a main program is not required. We have also chosen to have the wizard generate the source code for the procedure.

The next page allows selection of the directories that will hold sources and intermediate products. We take all the defaults.


The final page allows selection of one or more toolchains to be available to the project. The appropriate toolchain for the project’s selected build spec will be enabled by default, but can be changed. Multiple toolchains can be convenient for a number of reasons. For example, a project baseline compiler version can be used to build the actual release but a newer version of the same toolchain can also be used for the sake of improved error analysis. This page also allows selection of a “production” and “debug” scenario, in which different switches are applied (e.g., debugging versus optimization) depending on the current development mode. Other build options are also available on the page. We take the defaults and simply press Finish.


After conversion, note the presence of the new makefile in the Project Explorer. This is a makefile fragment that will automatically invoke the Ada compiler and other builder tools when the Workbench project builder is invoked. It must not be deleted.

Also note the “src” folder containing the main subprogram. This file will have the name we specified via the unit name, “test_main.adb”, and will contain a procedure with that unit name:

tutorial main subprogram in editor