![]() |
![]() |
![]() |
6.6 pRISM+ Make Support
The pRISM+ Application Development Framework offers comprehensive make support which is pSOSystem-centric yet flexible enough to be extended to your environment. You can use the supplied pSOSystem makefiles or use SNiFF+ makefile generation feature to automatically generate makefiles for your code base.
pRISM+ make support is also scalable, designed to address the need of single developers as well as team developers. This section describes the make support provided by the pRISM+ Application Development Framework.
6.6.1 pRISM+ Make Options at a Glance
pRISM+ offers many make options ranging from simple to very advanced. These make options are summarized below. Extensive details will be offered in subsequent sections.
- Build your application using pSOSystem makefiles
- Build your application using SNiFF+ Make Support
- Build your application using a combination of pSOSystem makefiles and SNiFF+ Make Support - the Hybrid Make Model
- Using your own make and makefile
- Building from the command line
6.6.2 pSOSystem Application Make Structure
This section describes pSOSystem makefiles structure. pSOSystem is supplied with makefiles for building sample applications, BSP libraries, OS libraries and other libraries that come in source form with pSOSystem. These makefiles can be used with or without SNiFF+. When used with SNiFF+, pSOSystem makefiles provide overriding of SNiFF+ Workspaces.
NOTE: This document briefly explains SNiFF+ workspaces and general concepts. For detailed information refer to the SNiFF+ User's Guide.
This section is a reference for anybody modifying, using, and writing makefiles for pSOSystem. pSOSystem makefiles can be divided into three categories:
- Sample application makefiles.
- BSP makefiles.
- Makefiles to build system libraries and other libraries.
Sample Application Makefiles
Every sample application comes with a makefile to build the application targets. This makefile ties the application to the rest of pSOSystem. It serves as a definition of files that are needed for pSOSystem to build a target executable. If you want to expand pSOSystem makefiles for your project, you should begin with this makefile.
Each sample application makefile or application makefile imports common definitions and rules from the
config.mk
file in$PSS_ROOT/configs/std
directory. This makefile is included by every application makefile. Each sample application makefile also includes thebsp.mk
file from the BSP directory. Each sample application makefile might also include one or moredrivers/<drv_name>/rules.mk
file if the application uses driverdrv_name
.If the application is built in the SNiFF+ environment, a sample application makefile also includes the file
configs/std/$(SNIFF_MAKE_CMD).mk
. This file is kept for compatibility reasons. The inclusion of this file has no effect.
In the integration of SNiFF+ 3.0.2 in pRISM+ 2.0 it implemented workspace overriding for pSOSystem applications in case of SNiFF+.
NOTE: SNIFF_MAKE_CMD
is defined tosnf_gnu
.
The following sections are brief summaries of the makefiles included by the sample application makefile.
$PSS_ROOT/configs/std/config.mk
This makefile contains common compiler defines and options, rules for making configuration file objects (
psoscfg.o
,pnacfg.o
etc.). It also includes rules for all the common application targets such asram.elf
,ram.hex
etc. This makefile is included by every sample application makefile.$PSS_ROOT/bsps/<bsp_name>/bsp.mk
This makefile contains board specific defines and targets (for example, DFP=H). This is included by every application makefile. It is also included by the BSP makefile.
$PSS_ROOT/drivers/<drv_name>/rules.mk
This makefile contains rules for making <drv_name> driver (for example, PPP). It is included by an application makefile if the application needs the <drv_name> driver.
BSP Makefiles
Every Board Support Package comes with a makefile to build an object library. This makefile normally resides in
$PSS_ROOT/bsps/<bsp_name>/src
directory. Each BSP makefile provides a definition of all other files that are needed from pSOSystem in order to build a BSP library. To expand the pSOSystem BSP makefile for your custom board support package, you should begin with this makefile.Each BSP makefile includes
$PSS_ROOT/bsps/<bsp_name>/bsp.mk
file to get the BSP specific defines.It also includes
$PSS_ROOT/drivers/rules.mk
,$PSS_ROOT/bsps/devices/rules.mk
and$PSS_ROOT/bsps/devices/$CPU_FAMILY/rules.mk
. Theserules.mk
files contain rules for making objects from the source files in the respective directories.This makefile also includes the
$(SNIFF_MAKE_CMD).mk
file. This is for compatibility reasons. (See also above)The following are brief summaries of the makefiles included by BSP makefiles.
$PSS_ROOT/drivers/rules.mk
Contains rules to make the high level drivers from the
drivers
directory. It is included by BSP makefiles using drivers from this directory.$PSS_ROOT/bsps/devices/rules.mk
Contains rules for making low level device drivers which come from
$PSS_ROOT/bsps/devices/<device_name>
directory. It is included by every BSP makefile.$PSS_ROOT/bsps/devices/$CPU_FAMILY/rules.mk
Contains rules for making CPU_FAMILY-specific files from the
$PSS_ROOT/bsps/devices/$CPU_FAMILY
directory. It is included in every BSP directory.Makefiles to Build System Libraries and Other Libraries
$PSS_ROOT/sys/os
directory contains makefiles to build the system librarieslibsys.a
.Putting It All Together
To generate a target executable, execute the make command on the project makefile in the sample application directory. This makefile calls
config.mk
,bsp.mk
andrules.mk
to compile the operating systems configuration code, BSP configuration code, and any high-level driver code this application needs.The object files generated are then linked with a BSP library (determined by the environment variable
$PSS_BSP
) and the OS library to generate a target executable, such asram.elf
.The OS libraries are built during the installation. By default, they are not recompiled with each application build. These libraries need to be recompiled only if you have made modifications to files in any of the
$PSS_ROOT/bsps
directories or the$PSS_ROOT/sys
directory$CPU_FAMILY like applying a Service Pack or adding new pSOSystem components as pHILE+, SNMp, etc..6.6.3 Make Attributes of pSOSystem Source Projects
In the previous section the pSOSystem make structure was described. This section examines how pSOSystem make is integrated with SNiFF+. This will be done by examining the make attributes of pSOSystem projects. Using the
pdemo
sample application, you will examine the various aspects of Make Attributes. Double-clicking on a project name in the PE window displays the project's attribute sheets. Use the SNiFF+ Reference Guide for descriptions of all make attributes. This section only explains parameters relevant to pSOSystem integration.Build Options
Figure 6-14 on page 6-40 shows the Build Options category in the Attributes dialog box for
pdemo.shared.
- Use SNiFF+ Make Support: This box is not checked because we use the pSOSystem makefiles.
- Make Command: psosmake: This is the actual make command used on the command line. psosmake supports team development when called from within the SNiFF+ environment.
If you follow the procedures in Section 6.7, Using the pRISM+ Application Development Framework with SNiFF+ on page 6-50, the pRISMSpace Wizard ensures that you use the correct make command based on your starting mode. You do not need to modify project make attributes when you follow the procedures given in Section 6.7.
FIGURE 6-14 Build Options Category in Attributes Dialog BoxProject Targets
Figure 6-15 on page 6-41 shows the Build Options >Project Targets category in the Attributes dialog box for
pdemo.shared.
- Executable: Here you can see that, for the project
pdemo.shared
, the default target isram.elf
.- Other: This field shows all the other targets that can be made from this project.
FIGURE 6-15 Build Options -> Project Targets Category in the Attributes Dialog Box6.6.4 Making a pSOSystem Target Executable
Using the
pdemo.shared
example, to make theram.elf
target, select Target >Make >ram.elf in the PE window.6.6.5 Using pSOSystem Makefiles
pSOSystem makefiles are the default makefiles used by pRISM+ and integrated into the SNiFF+ Make Support structure.
pSOSystem makefiles represent the way pSOSystem is built and tested. All the tests done on pSOSystem are based on builds done with these makefiles. For these reasons you should not fundamentally alter the structure of these makefiles or attempt to regenerate these makefiles with SNiFF+.
pSOSystem makefiles have been extended for the integration with SNiFF+. Although pSOSystem makefiles implement workspace overriding when used with SNiFF+ Working Environments, these makefiles themselves do not have SNiFF+ awareness. For example, when you start your development based on a pSOSystem sample application, by default you will start with a pSOSystem makefile. When a new file is added to this project, the pSOSystem makefile is not automatically updated with the new file information. The makefile should be updated for the change to take effect.
pSOSystem was not compiled using SNiFF+ generated makefiles for many reasons. Each pSOSystem application defines multiple targets, for execution in RAM, in ROM, in
.elf
format or.hex
format, etc. Each of these targets is built using a different set of files out of the same pSOSystem source tree. pSOSystem makefiles provide the mapping for what is needed for each target. These targets require specific ordering of object files at link time. Many of the pSOSystem files require specific compiler flags on a per-file basis. These special make requirements makes it impractical to use SNiFF+ generated makefiles to compile pSOSystem code because too many projects would have to be made, i.e., one separate for every target. This is also the reason why Integrated Systems discourages you from regenerating makefiles with SNiFF+ to compile pSOSystem sample applications.6.6.6 Using the SNiFF+ Makefile-Generation Feature
SNiFF+ provides automatic make support for multi-platform development that can be configured to work with any compiler, linker, archiver, and other build tools of your choice. Once a project source tree is constructed using the SNiFF+ Project Editor, makefiles can be automatically generated for this project. When additional files are added to the project source tree, the generated makefiles are automatically updated to reflect the changes. The SNiFF+ automatic makefile generation feature is tightly integrated with the project management aspects of SNiFF+, namely the Workspace and Working Environment concepts. Together they allow a team of engineers to share and compile against a common code base between them.
pRISM+ supports and extends this SNiFF+ feature with some additional pSOSystem specific make support files as well as a mechanism to allow SNiFF+ "made" modules to be incorporated back into a pSOSystem build in order to produce a target executable. Together with modification to pSOSystem makefiles, pRISM+ offers a powerful solution for team-based development projects based on pSOSystem.
Refer to the SNiFF+ User's Guide for detailed information about the SNiFF+ Make Support system. This section documents only the integration of SNiFF+ with pSOSystem.
SNiFF+'s Makefiles and Make Support Files
Refer to the SNiFF+ User's Guide for information about SNiFF+'s makefiles and Make Support files.
pRISM+ Specific Makefiles
In addition to the standard SNiFF+ Makefiles and Make Support Files, there are several additional files to support the use of the automatic makefile generation feature for pSOSystem-based applications. They are as follows:
$(COMP_TOOL)_$(CPU_FAMILY)_$(HOST).mk
: (Located in$SNIFF_DIR/make_support
directory) This is an additional pRISM+ platform makefile which integrates SNiFF+'s Make Support with the pRISM+ embedded platform.$(COMP_TOOL) is
diab
for DiabSDS Compilerarm
for ARM SDK Compilercadul
for CAD-UL Compiler$(CPU_FAMILY) is
68k
for Motorola 68K Familyarm
for ARM Processor Familymips
for MIPS Processor Familyppc
for Motorola / IBM PowerPC Familyx86
for i386 compatible Processor Family$(HOST) is
win32
for WinNT4.0solaris
for Sun Solarishpux
for HP-Unixgeneral.mib.mk
: (Located in$SNIFF_DIR/make_support
directory) This is an additional language makefile to support the mib file type.
pRISM+ Platform Makefile
In addition to SNiFF+ Makefile and Make Support files, also located in
$SNIFF_DIR/make_support
is a platform makefile that supports the use of the SNiFF+ automatic makefile generation feature for pSOSystem-based applications. Each platform makefile is unique for a pRISM+ for a specific processor family.An example of the platform makefile for pRISM+ for PowerPC using the Diab Data compiler on Windows NT is a file named
diabppc_win32.mk
.(These platform makefiles are compatible for use with SNiFF+ 3.0.2 and 3.2 as well.)
This platform makefile is included by the SNiFF+ general makefile
general.mk
. All the pRISM+ specific make options are specified in this file. These options include compiler, assembler, linker, and archiver invocation commands and options.Per-File Compile Options
SNiFF+'s Make Support uses all compile options on a per-platform basis. This means that the compiler options in the pRISM+ platform makefiles are used for every file for this platform. However, in embedded development it's common to compile files with per-file options. To support this, an additional macro,
COPT_PER_FILE
is defined ingeneral.c.mk
to allow you to specify compile options on a per-file basis.If a file with the
.cop
extension exists, the content of it is passed to the compiler when compiling the corresponding.c
,.cc
,.cxx
, and.s
files. For example, if you want to set the Diab compiler option-Xrtc
for the source filedemo.c
in order to use RTA Suite to perform run-time error checking on this file, you need to make a file nameddemo.cop
to include-Xrtc
. This.cop
file should be kept in your private workspace.6.6.7 Generating Makefiles for Your Project
When to Use This Feature
pRISM+ provides integration to support use of the SNiFF+ makefile generation feature because it is a very powerful paradigm for building large applications and for managing a team build environment. It is not recommended that you remove pSOSystem makefiles and regenerate them using this makefile generation feature for the following reasons:
- Possible exposure of complexity of pSOSystem make structure to users
- Certain functionality limitations in SNiFF+ Make Support system.
- Possible difficulties for Integrated Systems support staff to recreate your environment in order to track down a problem.
Use SNiFF+ to generate makefiles for your code base only. pRISM+ provides mechanisms for you to integrate your modules that are compiled with SNiFF+ generated makefiles in to a pSOSystem based build. This is the base of the Hybrid Make Model which is recommended by Integrated Systems to users who want to use the automatic makefile generation feature.
How to Use This Feature
In order to use the makefile generation feature, you must create a source project for your code base. The SNiFF+ Shared Sourec Working Environment
SSWE:pSOSystem-
$CPU_FAMILY-User
is specifically designed to hold your code.To make this SSWE contain your code, edit the
$PSS_USER_SSWE
environment variable in the start-up script in your pRISM+ installation directory; define$PSS_USER_SSWE
to point to a directory, where your code is in a subdirectory.
- On Windows hosts: Modify the
env$CPU_FAMILY.ksh
file.- On UNIX hosts: Modify the
envv$CPU_FAMILY.sh
orenvv$CPU_FAMILY.csh
file.After editing the start-up script file, you need to restart SNiFF+ for the new setting to take effect. For further information refer to Appendix E.7
Now you are ready to make a source project under the
SSWE:pSOSystem-$CPU_FAMILY-User
which will enable sharing of the new project.
FIGURE 6-17 SNiFF+ Working Environments WindowOnce such a project is made, you can compile by selecting Target >Make >Update Makefile followed by Target >Make ><your target> in the PE window. Refer to Section 6.7, Using the pRISM+ Application Development Framework with SNiFF+ on page 6-50, for additional step-by-step instructions.
6.6.8 Hybrid Make Model
The Hybrid Make Model is the method you use to combine the SNiFF+ automatic makefile generation with the pSOSystem make system in order to produce a pSOSystem-based target executable. This make model offers the best of both worlds:
- Use of Integrated Systems-supplied pSOSystem makefiles for OS specific compilation requirements.
- Use of the SNiFF+ powerful automatic makefile generation feature for your code base.
The Hybrid Make Model combines control with flexibility. Integrated Systems strongly recommends that pRISM+ users avoid regenerating pSOSystem makefiles with SNiFF+. The Hybrid Make Model is the recommended method if you want to use the SNiFF+ Make Support system with pRISM+.
This section explains the benefits of this make model and integration that exists in the pRISM+ Application Development Framework to support this model.
Who Should Use the Hybrid Make Model?
The Hybrid Make Model is designed for the following users:
- Users with an existing code base and who would like to use SNiFF+ to generate and manage makefiles.
- Users who are starting a new project and would like to automate the makefile generation and management process.
- Users who are using SNiFF+ support for team development.
How Does Hybrid Make Model Work?
The Hybrid Make Model works as follows:
- After you pointed pRISM+ to an existing code base a project for the existing code base is created in the Shared Source Working environment for the user. In the simplest case, this "existing code base" can be an empty directory to be populated by a new project. This is performed with the help of the pRISMSpace Wizard.
- pRISM+ automatically enabled the makefile generation option.
- pRISM+ also automatically starts the integration of your code with pSOSyste
(In SNiFF+ 3.0.2 you needed to run the Convert to pSOSystem app proj script by hand.)
- It adds a pSOSystem superproject name
pss_main.shared
to your source project. Your source project then becomes a subproject topss_main.shared
.
pss_main.shared
contains a template pSOSystem makefile with rules for pSOSystem-based target executables such asram.elf
. This template makefile also contains a macro which is to hold the name of your relinkable object in order to include it in the final build.- It enters the name of your relinkable object into the template pSOSystem makefile in
pss_main.shared
so when you invoke the pSOSystem make, your object module is linked into the target executable.- It also appends most of the common pSOSystem subprojects to
pss_main.shared
, which can be browsed with your code.- You complete the final build by invoking make on the top-level pSOSystem makefile to generate a pSOSystem-based target executable.
pss_main.shared Project
pss_main.shared
is the top-most pSOSystem super project which integrates your code base with pSOSystem code.pss_main.shared
contains a set of four files that are essential to every pSOSystem application:sys_conf.h
,drv_conf.c
,readme.txt
and a pSOSystemmakefile
.The
sys_conf.h
anddrv_conf.c
files used inpss_main.shared
are generic template files. They are sufficient for a simple application such as thepdemo
sample application but they might not reflect the needs of your application entirely.Compare the
sys_conf.h
anddrv_conf.c
files in a pSOSystem sample application (one that closely resembles the type of application you are developing) with the template files. If there are differences, you can either import the needed changes, or simply copy thesys_conf.h
anddrv_conf.c
from the pSOSystem sample application that closely resembles the type of application you are developing.If your application code already contains
sys_conf.h
anddrv_conf.c
, your working version should replace the template version.The
pss_main.shared
makefile is a slightly modified pSOSystem application makefile. The structure and function is similar to all the pSOSystem makefiles that can be found in any pSOSystem sample application in$PSS_ROOT/apps
directory. This makefile, however, differs slightly from other pSOSystem sample application makefiles in the following aspects:
- The
PSS_APPOBJS
macro contains the name of your custom module. This module is then linked when any targets are made.- Unlike sample application makefiles that also contain all the specific libraries those applications need, the template makefile of the
pss_main.shared
does not contain the name of any other libraries. You need to enter any other libraries that your application requires into the makefile.6.6.9 Doing Team-Based Builds
SNiFF+'s make system is integrated tightly with the concepts of workspace and overriding of workspaces.
To support this team-build concept consistently, for files that are compiled with SNiFF+ generated makefiles as well as those made by pSOSystem makefiles, pSOSystem makefiles have been written to support the concept of workspace as well. These extensions in pSOSystem makefiles assist the team of developers in sharing a common pSOSystem.
This section describes the sharing of pSOSystem code in a team build environment.
SNiFF+ and Overriding of Workspaces
A workspace is a directory tree in the file system in which complete SNiFF+ projects or parts of projects reside. SNiFF+ distinguishes between workspaces that are owned by only one developer (Private Workspaces or PWSs) and workspaces that are shared by a team (Shared Workspaces or SWSs).
A workspace can share files that it does not have, but contained in another workspace. For example, private workspace can share files with the shared workspace. A practical application of Private Workspace and Shared Workspace file sharing allows individual team members to build against a common code base without having to maintain local copies of the common files.
A workspace can override another workspace. Files in one workspace can hide files that have the same name and relative position in another workspace. For example, suppose both PWS and SWS contain files
apps/pdemo/demo.c
. Theapps/pdemo/demo.c
file in PWS hides the same file in SWS.A practical application of file overriding between workspaces allows a team member to check out a copy of a shared file into his Private Workspace. After some modifications, this modified version of the file will be used in his next build, overriding the original shared version of the file with the same name in the Shared Workspace.
Both sharing and overriding of files in workspaces are collectively referred as overriding in this document.
Sharing of pSOSystem Code
In the pSOSystem context,
$PSS_ROOT
serves as the root of the SSWE. A PWE is used for every developer in the team in his own$PSS_USER_PWE
directory which defaults to the$HOME/psos$CPU_FAMILY_pwe
directory. When a shared project is opened in a developer's PWE, the pSOSystem application and the BSP is located in the PWE.
NOTE: On Windows a local copy, on UNIX a symbolic link is used to refer to the files in the SSWE. For detailed information refer to the SNiFF+ User's Guide.
The common projects of pSOSystem as
include.shared
,config_std.shared
andsys_os.shared
are distributed as frozen project descriptions and read-only file attributes to avoid accidental modification. They are located in the shared area and not copied or linked to the PWE. pSOSystem makefiles understand SNiFF+ workspaces and they implement sharing and overriding. Because of this feature, users on the same development team can effectively share on common pSOSystem tree.6.6.10 Building from the Command Line
Use the command
psosmake <target_name>
to build from the command line.
![]() |
![]() |
![]() |