Makefiles for VxWorks applications are easy to create by exploiting the makefiles and make include files shipped with VxWorks BSPs. This section discusses how the VxWorks BSP makefiles are structured. An example of how to utilize this structure for application makefiles is in 8.8.2 Using Makefile Include Files for Application Modules.

In Tornado, a set of supporting files in installDir/target/h/make makes it possible for each BSP or application Makefile to be terse, specifying only the essential parameters that are unique to the object being built.

Example 8-1 shows the makefile from the installDir/target/config/mv147 directory; the makefile for any other BSP is similar. Two variables are defined at the start of the makefile: CPU, to specify the target architecture, and TOOL to identify what compilation tools to use. Based on the values of these variables and on the environment variables defined as part of your Tornado configuration, the makefile selects the appropriate set of definitions from installDir/target/h/make. After the standard definitions, several variables define properties specific to this BSP. Finally, the standard rules for building a BSP on your host are included.

Example 8-1:  Makefile for MVME147

# Makefile - makefile for target/config/mv147 
# 
# Copyright 1984-1995 Wind River Systems, Inc. 
# 
# DESCRIPTION 
# This file contains rules for building VxWorks for the 
# Motorola MVME147. 
#*/ 
 
CPU              = MC68020 
TOOL             = gnu 
 
include $(WIND_BASE)/target/h/make/defs.bsp 
include $(WIND_BASE)/target/h/make/make.$(CPU)$(TOOL) 
include $(WIND_BASE)/target/h/make/defs.$(WIND_HOST_TYPE) 
 
## Only redefine make definitions below this point, or your definitions  
## will be overwritten by the makefile stubs above. 
 
 
TARGET_DIR       = mv147 
VENDOR           = Motorola 
BOARD            = MVME147, MVME147S-1 
 
# 
# The constants ROM_TEXT_ADRS, ROM_SIZE, and RAM_HIGH_ADRS are  
# defined in config.h as well as in this Makefile. 
# Both definitions of these constants must be identical. 
# 
 
ROM_TEXT_ADRS    = ff800008 # ROM entry address 
ROM_SIZE         = 00020000 # number of bytes of ROM space 
 
RAM_LOW_ADRS     = 00001000 # RAM text/data address 
RAM_HIGH_ADRS    = 00090000 # RAM text/data address 
 
HEX_FLAGS        = -v -p $(ROM_TEXT_ADRS) -a 8 
 
MACH_EXTRA       =   
 
## Only redefine make definitions above this point, or the expansion of  
## makefile target dependencies may be incorrect. 
 
include $(WIND_BASE)/target/h/make/rules.bsp 
include $(WIND_BASE)/target/h/make/rules.$(WIND_HOST_TYPE)

There are two kinds of include files in installDir/target/h/make (as reflected by the two blocks of include statements in Example 8-1): variable definitions, and rule definitions. Just as for #include statements in the C preprocessor, include statements in makefiles accept the slash (/) character between directory segments of a file name. This feature of GNU make helps to write portable makefiles.

The following make include files define variables. These files are useful for application-module makefiles, as well as for BSP makefiles.

defs.bsp

Standard variable definitions for a VxWorks run-time system.

make.$(CPU)$(TOOL)

Files named using this pattern (such as make.MC68060gnu) provide definitions for a particular target architecture and a particular set of compilation tools, such as architecture-specific tool names and option flags.

defs.$(WIND_HOST_TYPE)

Files named using this pattern (such as make.x86-win32) provide definitions that depend on the host system: names of tools that are independent of the target architecture, and pathnames for the Tornado installation on your host.

The following include files define make targets, and the rules to build them. These files are usually not required for building application modules in separate directories, because most of the rules they define are specific to the VxWorks run-time system and boot programs.

rules.bsp

Rules defining all the standard targets for building a VxWorks run-time system (described in 8.7 Building a VxWorks System Image and 8.9 Creating Bootable Applications). The rules for building object code from C, C++, or assembly language are also spelled out here.

rules.$(WIND_HOST_TYPE)

Files named using this pattern (such as make.x86-win32) specify targets that depend only on the host system (dependency lists).

The variables defined in the make include files provide convenient defaults for most situations, and allow individual makefiles to specify only the definitions that are unique to each. This section describes the make variables most often used to specify properties of BSPs or applications. The following lists are not intended to be comprehensive; see the make include files for the complete set.

	NOTE: Certain make variables are intended specifically for customization; see Variables for Customizing the Run-Time. Do not override other variables in BSP makefiles. They are described in the following sections for expository purposes.

The variables grouped in this section are useful for either BSP makefiles or application-module makefiles. They specify aspects of how to invoke the compiler.

CFLAGS

The complete set of option flags for any invocation of the C compiler. This variable gathers the options specified in CC_COMPILER, CC_WARNINGS, CC_OPTIM, CC_INCLUDE, CC_DEFINES, and ADDED_CFLAGS. To add your own option flags, define them as ADDED_CFLAGS.

C++FLAGS

The complete set of option flags for any invocation of the C++ compiler. This variable gathers together the options specified in C++_COMPILER, C++_WARNINGS, CC_OPTIM, CC_INCLUDE, CC_DEFINES, and ADDED_C++FLAGS. To add your own option flags, use ADDED_C++FLAGS.

CC_COMPILER

Option flags specific to compiling the C language. Default: -ansi -nostdinc.

C++_COMPILER

Option flags specific to compiling the C++ language. Default: -ansi -nostdinc.

CC_WARNINGS

Option flags to select the level of warning messages from the compiler, when compiling C programs. Two predefined sets of warnings are available: CC_WARNINGS_ALL (the compiler's most comprehensive collection of warnings) and CC_WARNINGS_NONE (no warning flags). Default: CC_WARNINGS_ALL.

C++_WARNINGS

Option flags to select the level of warning messages from the compiler, when compiling C++ programs. The same two sets of flags are available as for C programs. Default: CC_WARNINGS_NONE.

CC_OPTIM

Optimization flags. Three sets of flags are predefined for each architecture: CC_OPTIM_DRIVER (optimization level appropriate to a device driver), CC_OPTIM_TARGET (optimization level for BSPs), and CC_OPTIM_NORMAL (optimization level for application modules). Default: CC_OPTIM_TARGET.

CC_INCLUDE

Standard set of header-file directories. To add application-specific header-file paths, specify them in EXTRA_INCLUDE.

CC_DEFINES

Definitions of preprocessor constants. This variable is predefined to propagate the makefile variable CPU to the preprocessor, to include any constants required for particular target architectures, and to include the value of the makefile variable EXTRA_DEFINE. To add application-specific constants, specify them in EXTRA_DEFINE.

The variables included in this section specify properties of a particular BSP, and are thus recorded in each BSP makefile. They are not normally used in application-module makefiles.

TARGET_DIR

Name of the BSP (used for dependency lists and name of documentation reference entry). The value matches the bspname directory name.

ROM_TEXT_ADRS

Address of the ROM entry point. Also defined in config.h; the two definitions must match.

ROM_SIZE

Number of bytes available in the ROM. Also defined in config.h; the two definitions must match.

RAM_HIGH_ADRS

RAM address where the boot ROM data segment is loaded. Must be a high enough value to ensure loading VxWorks does not overwrite part of the ROM program. Also defined in config.h; the two definitions must match. See 8.9 Creating Bootable Applications for more discussion.

RAM_LOW_ADRS

Beginning address to use for the VxWorks run-time in RAM.

HEX_FLAGS

Option flags for the program (such as hex, coffHex, or elfHex) that converts a boot program into S-records or the equivalent.

LDFLAGS

Linker options for the static link of VxWorks and boot ROMs.

ROM_LDFLAGS

Additional static-link option flags specific to boot ROM images.

The variables listed in this section make it easy to control what facilities are statically linked into your run-time system. You can specify values for these variables either from the make command line, or from your own makefiles (when you take advantage of the predefined VxWorks make include files).

CONFIG_ALL

Location of a directory containing the architecture-independent BSP configuration files. Set this variable if you maintain several versions of these files for different purposes. Default: installDir/target/config/all.

LIB_EXTRA

Linker options to include additional archive libraries (you must specify the complete option, including the -L for each library). These libraries appear in the link command before the standard VxWorks libraries.

MACH_EXTRA

Names of application modules to include in the static link to produce a VxWorks run-time. See 8.9 Creating Bootable Applications.

ADDED_MODULES

Do not define a value for this variable in makefiles. This variable is reserved for adding modules to a static link from the make command line. Its value is used in the same way as MACH_EXTRA, to include additional modules in the link. Reserving a separate variable for use from the command line avoids the danger of overriding any object modules that are already listed in MACH_EXTRA.

EXTRA_INCLUDE

Preprocessor options to define any additional header-file directories required for your application (you must specify the complete option, including the -I).

EXTRA_DEFINE

Definitions for application-specific preprocessor constants (you must specify the complete option, including the -D).

ADDED_CFLAGS

Application-specific compiler options for C programs.

ADDED_C++FLAGS

Application-specific compiler options for C++ programs.

You can exploit the VxWorks makefile structure to put together your own application makefiles quickly and tersely. If you build your application directly in a BSP directory (or in a copy of one), you can use the Makefile in that BSP, by specifying variable definitions (Variables for Customizing the Run-Time) that include the components of your application.

You can also take advantage of the Tornado makefile structure if you develop application modules in separate directories. Example 8-2 illustrates the general scheme: include the makefile headers that specify variables, and list the object modules you want built as dependencies of a target. This simple scheme is usually sufficient, because the Tornado makefile variables are carefully designed to fit into the default rules that make knows about.¹

	NOTE: The target name exe is the Tornado convention for a default make target. You may either use that target name (as in Example 8-2), or define a different default rule in your makefiles. However, there must always be an exe target in makefiles based on the Tornado makefile headers (even if the associated rules do nothing).

Example 8-2:  Skeleton Makefile for Application Modules

# Makefile - makefile for ... 
# 
# Copyright ... 
# 
# DESCRIPTION 
# This file specifies how to build ... 
# 
 
## It is often convenient to override the following with "make CPU=..." 
CPU              = cputype  
TOOL             = gnu 
 
include $(WIND_BASE)/target/h/make/defs.bsp 
include $(WIND_BASE)/target/h/make/make.$(CPU)$(TOOL) 
include $(WIND_BASE)/target/h/make/defs.$(WIND_HOST_TYPE) 
 
## Only redefine make definitions below this point, or your definitions 
## will be overwritten by the makefile stubs above. 
 
exe : myApp.o

The directory installDir/target/src/drv/sio/ contains source and templates for serial drivers that support both polled and asynchronous communications. The makefile for drivers in this directory is named Makefile.sio. Because this is not one of the names make can find automatically, you must specify the makefile with the -f option when you build a driver in this directory.

For example, to build the driver cd2400Sio.c and install it in the VxWorks archives, execute the following commands in this directory:

Windows

C:\tornado\target\src\drv\sio> make -f Makefile.sio CPU=cputype cd2400Sio.o C:\tornado\target\src\drv\sio> make -f Makefile.sio CPU=cputype default

UNIX

% make -f Makefile.sio CPU=cputype cd2400Sio.o default 

1:  However, if you are working with C++, it may be also convenient to copy the .cpp.out rule from installDir/target/h/make/rules.bsp into your application's Makefile.