NOTE: For a tutorial introduction to the project facility and its use with the integrated version of the VxWorks target simulator and other Tornado tools, see the Tornado Getting Started Guide.

	WARNING: Use of the project facility for configuring and building applications is largely independent of the methods used prior to Tornado 2.x. (These methods included manually editing the configuration files config.h or configAll.h, while the project tool uses .cdf files). The project facility provides the recommended and simpler means for configuring and building, although the configuration file method may still be used (see 5. Command Line Configuration and Build). To avoid confusion and errors, the two methods should rarely be used together for the same project.
	One exception is for any configuration macro that is not accessible through the project facility GUI (which may be the case, for example, for some BSP driver parameters). You can use a Find Object dialog box to determine if a macro is accessible or not (see Finding VxWorks Components and Configuration Macros). If it is not accessible through the GUI, a configuration file must be edited, and the project facility will implement the change in the subsequent build.
	The order of precedence for determining configuration is (in descending order):         project facility         config.h         configAll.h For any macro that is exposed through the project facility GUI, changes made after creation of a project in either of the configuration files will not appear in the project.
	A second exception may be building a project based on a BSP. If you have customized your BSP by modifying config.h and other configuration files, you can convert it to a project and combine it with your application in the project facility. See 5.7 Building Projects from a BSP.
	In general, changes to header files in the BSP or the BSP makefile are only carried over to projects by recreating the projects. However, changes to .c files are automatically picked up by existing projects.

There are several key terms that you must understand before you can use the project facility documentation effectively:

Downloadable application

A downloadable application consists of one or more relocateable object modules,¹ which can be downloaded and dynamically linked to VxWorks, and then started from the shell or debugger. A novel aspect of the Tornado development environment is the dynamic loader, which allows objects to be loaded onto a running system. This provides much faster debug cycles compared with having to rebuild and re-link the entire operating system. A downloadable application can consist of a single file containing a simple "hello world" routine, or a complex application consisting of many files and modules that are partially linked as a single object (which is created automatically by the project facility as projectName.out).

Bootable application

A bootable application consists of an application linked to a VxWorks image. The VxWorks image can be configured by including and excluding components of the operating system, as well as by resetting operating system parameters. A bootable application starts when the target is booted.

Project

A project consists of the source code files, build settings, and binaries that are used to create a downloadable application or a bootable application. The project facility provides a simple means of defining, modifying, and maintaining a variety of build options for each project. Each project requires its own directory.

When you first create a project, you define it as either a downloadable application or a bootable application. In this context, custom-configured VxWorks images can be considered bootable applications.

Workspace

A workspace is a logical and graphical "container" for one or more projects. It provides you with a useful means for working with related material, such as associating the downloadable application modules, VxWorks images, and bootable applications that are developed for a given product; or sharing projects amongst different developers and products; and so on.

Component

A component is a VxWorks facility that can be built into, or excluded from, a custom version of VxWorks or a bootable application. Many components have parameters that can be reset to suit the needs of an application. For example, various file system components can be included in, or excluded from, VxWorks; and they each include a parameter that defines the maximum number of open files.

Toolchain

A toolchain is a set of cross-development tools used to build applications for a specific target processor. The default toolchains provided with Tornado are based on the GNU preprocessor, compiler, assembler, and linker (see the GNU ToolKit User's Guide) except for the ColdFire architecture. ColdFire uses the Diab toolchain. Diab is also available as an optional product for all architectures except Pentium and 68K. In addition, many third-party toolchains are available. The tool options are exposed to the user through various elements of the project facility GUI.

BSP

A board support package (BSP) consists primarily of the hardware-specific VxWorks code for a particular target board. A BSP includes facilities for hardware initialization, interrupt handling and generation, hardware clock and timer management, mapping of local and bus memory space, and so on.

The main components of the project facility GUI are:

• A project selection window, which allows you to begin creation of a new project, or open an existing project.

• An application wizard that guides you through creation of a new project.

• A workspace window, which provides you with a view of projects, and the files, VxWorks components, and build options that make them up. The workspace window also provides access to commands for adding and deleting project files, creating new projects, configuring VxWorks components, defining builds, downloading object files, and so on.

• A build toolbar, which provides access to all the major build commands.

As its name implies, the Workspace window provides the framework for the project facility. The window displays information about projects files, VxWorks components (if any), and build options in three tabbed views: Files, VxWorks, and Builds (Figure 4-1).

Figure 4-1:   Workspace Window Views: Files, VxWorks, and Builds

Figure 4-2:   Workspace Window Pop-up Menu

As you expand the tree structure in each workspace pane, the icons by each tree element tell you what it is or what it contains.

Table 4-1:   Workspace Icons

If your BSP was included with Tornado 2.2, you can create a bootable project from it directly. Use the project wizard for a bootable application to create a project based on your BSP or the pre-built project (bspName_vx.wpj) which is shipped with every Wind River-supplied BSP.

For information on migrating a Tornado 2.0-compliant BSP to Tornado 2.2, see the Tornado Migration Guide.

If your BSP came from a third party or from Tornado 1.0.1, see the Tornado Migration Guide or the Tornado 2.0 documentation.

You may wish to enable the Tornado 1.0.1 compatibility mode, which exposes menu items to execute BSP builds in a BSP directory. (See 12. Customization.) Once your BSP builds, you may proceed to create a bootable project from it immediately. See 5.7 Building Projects from a BSP.

If you need to create your own BSP, refer to the VxWorks BSP Developer's Guide (a separate product available from Wind River). If you wish to develop the BSP and the application code in parallel, you may wish to begin application development on the VxWorks simulator. See Using the Simulator BSP.

If you already have a custom BSP that is Tornado 2.0 compliant, see the Tornado Migration Guide for information on migrating from 2.0 to 2.2.

If you already have a custom BSP but it is not Tornado 2.0 compliant, you will need to modify it to conform to the guidelines outlined in the VxWorks BSP Developer's Guide in order to use it with the Tornado project facility. Once you have modified it, verify that it builds properly before creating a project for it.

	NOTE: If you do not make your BSP Tornado 2.0 compliant, Tornado will not be able to provide project-based support for customizing, configuring, or building it.

You may still use a non-compliant BSP by managing its customization and configuration manually. For information on using manual methods, see 5. Command Line Configuration and Build. You can still create downloadable projects to hold your application code and download them to a target booted with a non-compliant BSP.

If you are using the integrated simulator and do not need to customize it by adding or removing VxWorks functionality, you need not create a bootable project until you have your production BSP ready.

If you need additional VxWorks functionality, you will need to create a bootable project immediately. Use the project wizard for a bootable application. You will use a different base depending on what additional functionality you need.

• No networking: If you do not need networking to support your application, you can create a bootable project based on the integrated simulator, configure it, and build it.

• Networking: If you need network support, you will need the VxWorks full simulator (VxSim), which can be purchased from Wind River as an optional product.

The process for creating a project, and configuring it, is identical for both the integrated and full simulator.

Base this project on the simulator BSP (either the integrated simulator or the optional product), or the pre-built, default simulator project (simhost_vx.wpj. At this point, your project will build an image identical to the integrated simulator as you received it from Wind River. Now add any components you need using the VxWorks tab in the Workspace view (see 4.4.3 Configuring VxWorks Components).

If you already have a working application, or if your application is very large, you may want to use your own build system. You can use the project facility to link the output of an external build into VxWorks and even start external builds (see External Build System).

Alternatively, you may want to use the project facility to configure your VxWorks image and produce a makefile. You can build your application outside Tornado and call the project facility-generated makefile from your build to produce a final image.

Use this approach if your edit-compile-reboot cycle is relatively quick. Add the files to the bootable project using the Add File(s) to Project context menu available in the File tab of the Workspace view. Then edit the VxWorks initialization file, usrAppInit.c, adding calls to your application's initialization and startup routines. The VxWorks application initialization component is required, and is included by default. See 4.4 Creating a Custom VxWorks Image and 4.5 Creating a Bootable Application.

Use this method if rebooting your target is inconvenient, and if your code is modular enough that it can be added to the running target without interrupting execution or if you have the means to start and stop your application. Create a downloadable project using the Downloadable Project Wizard. Add application files with the Add File(s) to Project context menu. Build your downloadable project. Boot the target using the appropriate image described in 4.2.2 Creating a Bootable Project Based on a BSP. Download the partially linked and munched .out file produced by your project.² See 4.3 Creating a Downloadable Application.

• Create a Build Rule Specific to the Source File

This ensures that the custom rule will be invoked only to process the specified source file. For example, you may wish to add a custom rule to process a yacc file into a C source file. To create a custom rule, see 4.6 Working With Build Specifications.

	NOTE: If you migrate source files from one project to another, you will need to recreate the custom build rules for these files in the new project.

• Create a Custom Rule for the Build

A build-specific custom rule can invoke any command and reference any build dependencies. The rule can be selected as the current build rule to build the desired output explicitly or, if the Invoke this rule before building Project box is checked, it will be built implicitly prior to building any of the built-in rules (such as vxWorks, or project.a) for the project.

	NOTE: Custom build rules cannot be copied between projects. If you will use either form of custom build rules, and know that you will be migrating files between projects, you may wish to put files with similar build settings into separate projects. These projects can then be built and linked together. For more information, see the hierarchical sub-project model discussed in Sub-Projects.

You may migrate application source files between any two projects that coexist in the same workspace. Use the Add File(s) from Project context menu from the File tab. If you have defined custom build rules for any of your source files, you will have to replicate them in the destination project by hand.

	CAUTION: It is important that you only migrate application source files between projects. BSP-specific files, and those synthesized by Tornado for your project, cannot be migrated. Only Tornado's project wizards can be used to create or reference these files.

If you have a number of files that must be built with special build rules or flags, it may be easier to create a new project to build these particular files, and then build that project as a sub-project of your main project. For more information, see Structuring Your Projects.

Add all your application source code to one bootable project. This method is the simplest. All your source code is added to the bootable project, which already contains the BSP code and is linked to the VxWorks libraries.

The Tornado workspace is very convenient for configuring VxWorks, building small applications, or building, downloading, and debugging small parts of a large application. It is not designed to handle a complete build of a large, modular application, which often requires sub-projects (though this can be achieved using custom rules and macros). For this reason, you may want to use an external build system to build your application, then link it to VxWorks using the EXTRA_MODULES or LIBS macros. You can write a custom rule to invoke your external build process; see Sub-Projects. Alternatively, your build can kick off a VxWorks build and link your application code as the final step.

Sub-projects allow you to create as many projects as are needed to hierarchically organize and build your product. This approach accommodates existing hierarchically-organized source code. You will want to use this approach if:

• some source files need different build settings or custom rules.

• a split of your code is desirable for organizational or structural reasons.

Tornado has only limited support for managing and building these hierarchical sub-projects. You must use macros and custom rules to create the hierarchy and structure the builds manually. For directions on how to organize your application code into sub-projects, please refer to Example 1, below.

Example 1:   Using Sub-Projects

This example illustrates how a master project can be used to build several sub-projects. The master project builds the sub-projects as .pl (partially linked) modules. Then they are linked with the master project and munched (integrated with code to call C++ static constructors and destructors) in the final build step.

In this example, the master project is a bootable project, and there are two sub-projects that are downloadable projects. However, a downloadable project can also serve as a master project. You could use this approach if you wanted to build several downloadable sub-projects and link them into a single downloadable project. You could also use this approach to integrate an external application build into VxWorks. You need to modify the custom rules in the example to invoke your external build (for example, using make).

Assumptions:

• The bootable project is called Master and resides in a directory of the same name. It contains a build specification called default based on the simpc (Windows host simulator) BSP.

• The two downloadable projects are called Project1 and Project2, and they also reside in directories of the same name. Each contains a build specification called SIMNTgnu based on the PC simulator toolchain.

• Project1 contains a C source file called foo.c, containing a function called Test( ).

• Project2 contains a C source file goo.c, which in turn contains a function called Test2( ).

• Test( ), which calls Test2( ), is the main application entry point.

• Dependencies have been generated for each of the two downloadable projects, and they have been saved. This creates makefiles for them. Without the makefiles, the build fails.

Go first to the Build tab. Expand the project Master. Double-click on the build specification default to display the build property sheet. In the build property sheet, select the Rules page. Click New/Edit and add the new rules.

You enter a new rule by filling in the Target, Dependencies, and Commands fields of the Create or Edit Rule dialog box. For example, to add the clean rule, you type clean in the Target field, CleanProject1 CleanProject2 vxWorks in the Dependencies field, and nothing in the Commands field. For each rule, you must also uncheck the Invoke this rule before building project checkbox.

The required rules are listed below in makefile syntax. The first example shows the syntax. Fill in the appropriate boxes for each rule.

SYNTAX: 
    target : dependencies 
        commands

RULES: 
    ../../Project1/SIMNTgnu : 
        - mkdir $@

Master : ../../Project1/SIMNTgnu/Project1.pl ../../Project2/SIMNTgnu/Project2.pl VxWorks 
 
../../Project1/SIMNTgnu/Project1.pl : ../../Project1/SIMNTgnu 
wind_force_make 
    $(MAKE) -C ../../Project1/SIMNTgnu -f ../../Project1/Makefile 
BUILD_SPEC=SIMNTgnu Project1.pl 
 
../../Project2/SIMNTgnu : 
    - mkdir $@ 
 
../../Project2/SIMNTgnu/Project2.pl : ../../Project2/SIMNTgnu 
wind_force_make 
    $(MAKE) -C ../../Project2/SIMNTgnu -f ../../Project2/Makefile 
BUILD_SPEC=SIMNTgnu Project2.pl 
 
CleanProject1 : ../../Project1/SIMNTgnu 
    $(MAKE) -C ../../Project1/SIMNTgnu -f ../../Project1/Makefile 
BUILD_SPEC=SIMNTgnu clean 
 
CleanProject2 : ../../Project2/SIMNTgnu 
    $(MAKE) -C ../../Project2/SIMNTgnu -f ../../Project2/Makefile 
BUILD_SPEC=SIMNTgnu clean 
 
clean : CleanProject1 CleanProject2

	CAUTION: The clean rule must have the correct case, and it cannot include any commands. In this example, CleanProject1 and CleanProject2 are added as dependencies to the default clean rule for VxWorks. The clean rule ensures that the ReBuild All command rebuilds Project1, Project2, and VxWorks.

If you wish your rules to be portable between architectures, substitute $(CPU)$(TOOL) for SMNTgnu.

In the Rules pane, set the default build rule for project Master to be the rule Master. Next, in the Build pane, in the MACROS tab for project Master, append to the EXTRA_MODULES macro "../../Project1/SIMNTgnu/Project1.pl" and "../../Project2/SIMNTgnu/Project2.pl" and click the Add/Set button.

	NOTE: You can use PRJ_LIBS to link extra modules to downloadable projects, in the same way that EXTRA_MODULES is used for bootable projects.

Add to the source file usrAppInit.c, in project Master, a function prototype for, and a call to, the function Test( ):

void Test(void); 
 
void usrAppInit (void) 
    { 
    #ifdef  USER_FF 
    USER_APPL_INIT; /* for backwards compatibility */ 
    #endif 
 
    /* add application specific code here */ 
    Test(); 
    }

When you build Master, all three will be built, munched, and linked into one bootable image. (For information on munching, see the VxWorks Programmer's Guide: C++ Development.)

	NOTE: The sub-project objects in the example (Project1.pl and Project2.pl) need not have been generated by Tornado downloadable projects. They could also have been the result of an external build system.

To modify this example to integrate an external application build system, you could, for instance:

• Replace all instances of Project1.pl with the partial link product of your external application build.

• Replace the Project2.pl rule with a rule appropriate for starting your external application build.

Example 4-2:   Avoiding Absolute Paths

One problem that arises from using a version control system is that different users may extract projects and source files to different locations (for example, in Visual SourceSafe, or CVS), or map views to different drive letters (Clearcase on Windows). It helps greatly if projects do not have any absolute paths written into them.

If source files or subprojects are in a directory which is at the same directory level as the parent project directory or deeper, they are recorded in the parent project file with a path relative to the parent project directory. Organizing your source files and projects in this way is recommended to avoid absolute paths in project files and makefiles.

If you cannot organize your source files and projects in this way, we provide two environment variables to allow you to define the root of your source directory tree or your project directory tree: WIND_SOURCE_BASE and WIND_PROJ_BASE.

Below we give some examples showing how to avoid absolute paths to source files or to sub-projects.

1. Avoiding absolute paths to source files

Suppose your project is in directory t:\source_root\myproj and your source files are organized as follows:

t:\source_root\myproj\foo1.c 
t:\source_root\src\foo2.c 
t:\source_root\myproj\src\foo3.c

Your project will contain no absolute paths. Instead, the above files will be recorded in the project file as:

$(PRJ_DIR)/foo1.c 
$(PRJ_DIR)/../src/foo2.c 
$(PRJ_DIR)/src/foo3.c

Organizing your source files and projects in any of these ways is the recommended procedure for avoiding absolute paths in project files and makefiles.

If you cannot organize your source files and projects in one of these ways, the WIND_SOURCE_BASE environment variable allows you to define the root of your source directory tree. To illustrate the use of WIND_SOURCE_BASE, assume you wish to add the file:

t:\other_source_root\goo.c

If WIND_SOURCE_BASE is not defined, it appears in the project file with an absolute path (we do not support $(PRJ_DIR)/../../). However, before you add the file, you can use Tools->Options->Workspace to define:

WIND_SOURCE_BASE = t:\other_source_root

Then t:\other_source_roo\goo.c is recorded in the project file as:

$(WIND_SOURCE_BASE)/goo.c

The major drawback to the WIND_SOURCE_BASE variable is that all users of myproj must have WIND_SOURCE_BASE defined or the workspace cannot find goo.c.

1. Avoiding absolute paths to sub-projects

This example refers to a master project called master and various sub projects called sub1, sub2,... The master project could be a bootable project and the sub-projects could refer to external build systems or downloadable projects.

Assume the master project is in directory t:\prj_root\master and your sub-projects are organized as follows:

t:\prj_root\sub1 
t:\prj_root\master\sub2 
t:\prj_root\subprojects\sub3 
t:\prj_root\master\subprojects\sub4

In this case, your master project will contain no absolute paths. Instead, the above directories will be recorded in the master project file as:

$(PRJ_DIR)/../sub1 
$(PRJ_DIR)/sub2 
$(PRJ_DIR)/../subprojects/sub3 
$(PRJ_DIR)/subprojects/sub4

Organizing your projects in any of the above ways is the recommended procedure for avoiding absolute paths in project files and makefiles.

If you cannot organize your projects in any of these ways, we provide the WIND_PROJ_BASE environment variable to allow you to define the root of your project directory tree. To illustrate the use of WIND_PROJ_BASE, assume you wish to add the project:

t:\other_prj_root\sub5

If WIND_PROJ_BASE is not defined, then it appears in the master project file with an absolute path (we do not support $(PRJ_DIR)/../../). However, before you add the project you could use Tools->Options->Workspace to define:

WIND_PROJ_BASE=t:\other_prj_root

Now when you add t:\other_prj_root\sub5, this sub-project will be recorded in the master project file as:

$(WIND_PROJ_BASE)/sub5

The major drawback to the WIND_PROJ_BASE variable is that all users of the master project have to define WIND_PROJ_BASE, or the workspace is unable to find sub5.

	NOTE: WIND_SOURCE_BASE and WIND_PROJ_BASE must be set before a source file is added or the variable is not recorded in the file path. The property page always reflects the path from which a source file was originally loaded, not the current path calculated from WIND_SOURCE_BASE (if it has changed). The build always uses the correct value, but the source editor launches against the stale copy of the file. To avoid confusion, reload the workspace whenever you change WIND_SOURCE_BASE and WIND_PROJ_BASE.

Figure 4-3:   Create Downloadable Application

	NOTE: You may create your projects anywhere on your file system. However, it is preferable to create them outside of the Tornado directory tree to simplify the process of future Tornado upgrades.

You may also enter a description of the project, which will later appear in the property sheet for the project (Figure 4-4). Finally, identify the workspace in which the project should be created. Click Next to continue.

Figure 4-4:   Application Wizard: Step One for Downloadable Application

Figure 4-5:   Application Wizard: Step Two for Downloadable Application

Figure 4-6:   Application Wizard: Step Three for Downloadable Application

Figure 4-7:   Initial Workspace Window for a Downloadable Application

	NOTE: Pop-up menus provide access to all commands that can be used with the objects displayed in, and the pages that make up, the Workspace window (use the right mouse button).

Figure 4-8:   Workspace Files View

	WARNING: Use of the projectName.out file is essential for downloading C++ modules, which require munching for proper static constructor initialization. You should also use the projectName.out file for downloading C modules to avoid any potential link order issues related to dynamic loading and linking.

Figure 4-9:   New File Dialog Box

	CAUTION: Adding a file to a project or removing a file from a project does not affect its existence in the file system. The project facility does not copy, move, or delete user source files; merely the project facility's references to them. Removing a file from one workspace context does not affect references to it in any others, nor its existence on disk. However, if a file is included in more than one project or workspace, an edit made in one context will be reflected in all. (If this behavior is not desired, copy source files to another directory before adding them to a project.)

Figure 4-10:   Source File Property Sheet

	NOTE: All source files in a project are built using a single build specification (which includes a specific set of makefile, compiler, and linker options) at a time. If some of your source requires a different build specification from the rest, you can create a new project for it in the same workspace, and customize the build specification for those files. One project's build specification can then be modified to link in the output from the other project. See Sub-Projects.

	NOTE: The project facility allows you to create specifications for different types of builds, to modify the options for any one build, and to select the build specification you want to use at any given time easily. See 4.6 Working With Build Specifications.

	CAUTION: Different versions of C++ run-time support are provided for the GNU and Diab toolchains. For this reason, you cannot combine C++ objects compiled with GNU with C++ objects compiled with Diab. All C++ applications must be compiled with the same tool.

Figure 4-11:   Dependencies Dialog Box

Figure 4-12:   External Dependencies

Figure 4-13:   Dependency Calculation Option

The Rules page (Figure 4-14) allows you to select from the following build target options:

Figure 4-14:   Build specification Property Sheet

	NOTE: It is sometimes useful to build an application for the target simulator, and then to create a new build specification to build it for a real target.

The Macros tab contains pre-set build macros. Do not delete the pre-existing macros; while you can reenter them, the value will be lost. You can add and delete your own macros by typing in the Name window and then clicking the Add button.

Macros that are useful with bootable projects:

EXTRA_MODULES	Extra object modules to link into the VxWorks image.
LIBS	Libraries against which VxWorks is linked.
POST_BUILD_RULE	Shell commands to execute after the build has completed.
RAM_HIGH_ADRS	RAM address where the boot ROM data segment is loaded. It must be a high enough value to ensure loading VxWorks does not overwrite part of the ROM program.
RAM_LOW_ADRS	Beginning address to use for the VxWorks run-time in RAM.

	WARNING: RAM_HIGH_ADRS and RAM_LOW_ADRS are also defined in config.h; the two definitions must match!

Macros that are useful with downloadable projects:

PRJ_LIBS	Libraries or modules against which a downloadable application is linked.
POST_BUILD_RULE	Shell commands to execute after the build has completed.

If you are using the Diab tools, you must have two settings in place:

• Be sure that installDir\host\diab\WIN32\bin is in the system path.

• Be sure that the environment variable DIABLIB is set to installDir\host\diab.

There is a batch file called torVars.bat in installDir\host\x86-win32\bin that will set DIABLIB for you.

	WARNING: Tornado only calculates dependencies upon the first use of a file in a build. Once an initial set of dependencies has been calculated, Tornado does not attempt to detect changes in dependencies that may have resulted from modification of the file. If you have changed dependencies by adding or deleting #include preprocessor directives, you should regenerate dependencies.

The Build Output window displays build messages, including errors and warnings (Figure 4-15).

Figure 4-15:   Build Output

	WARNING: The default compiler options include debugging information. Using debugging information with the optimization set to anything but zero may produce unexpected results. See 4.6 Working With Build Specifications for information about modifying builds and creating new build specifications.

To force a rebuild of all project objects, select Rebuild All from the pop-up menu (which performs a make clean before the build).

The Build toolbar provides quick access to build commands. Display of the toolbar is controlled with the View>Toolbar>Build Toolbar menu option. The toolbar is shown free-floating in Figure 4-16, but is docked by default.

Figure 4-16:   Build Toolbar

Table 4-2:   Build Toolbar Buttons

	NOTE: When you remove a project, you only remove it from the workspace. The project directory and its associated files are not removed from disk.

Figure 4-17:   Create Bootable Application

	NOTE: You may create your projects anywhere on your file system. However, it is preferable to create them outside of the Tornado directory tree to simplify the process of future Tornado upgrades.

You may also enter a description of the project, which will later appear in the property sheet for the project. Finally, identify the workspace in which the project should be created. Click Next to continue.

Figure 4-18:   Application Wizard: Step One for Bootable Application

	NOTE: If you are creating a customized VxWorks image or a bootable application, the project will be generated faster if you base it on an existing project rather than on a BSP. This is because the project facility does not have to regenerate configuration information from BSP configuration files. All Tornado 2.x BSPs include both GNU and Diab project files for this purpose. Options for BSP projects are available in the drop-down list for existing projects. For example, the mbx860 BSP project files are:         installDir\target\proj\mbx860_gnu\mbx860_gnu.wpj         installDir\target\proj\mbx860_diab\mbx860_diab.wpj

Basing a project on an existing one means that the new project will reference the same source files as the one on which it was based, but it will start with copies of the original project's VxWorks configuration and build specifications. The build specifications and VxWorks configuration for the new project can be modified without affecting the original project, but changes to any shared source files will be reflected in both.

For example, to create a project for a module that will run on a mbx860 target, select An existing project and then select mbx860_gnu.wpj (or mbx860_diab.wpj if you have purchased the Diab tools) from the drop-down list (Figure 4-19). Click