![]() |
![]() |
![]() |
6.3 Key SNiFF+ Concepts
To understand the integration of SNiFF+ with pSOSystem, you need to become familiar with some basic SNiFF+ concepts. This section offers a list of relevant concepts for the pSOSystem integration, together with brief descriptions of how these concepts are used in the integration.
Refer to the SNiFF+ documentation set for complete reference information on the SNiFF+ concepts discussed in this section.
6.3.1 Code Comprehension and Browsing
SNiFF+ provides the most advanced browsing and cross referencing capabilities to help you understand more code, more efficiently. Powerful filtering and visualization techniques work even with the biggest projects with many thousands of files, tens of thousands of symbols and millions of lines of code. No compilation is necessary to extract the symbol information. With SNiFF+, you can browse code that has not yet been compiled.
6.3.2 Source Code Parsing
SNiFF+ uses an efficient C/C++ parser which analyzes C++, ANSI C, or Kernighan & Ritchie C source code. No compilation is necessary in order to extract symbol information. The parser is highly configurable and can optionally preprocess the source code. The symbol information is kept continually on disk, so that parsing is done only once for each file and then parsed again only after a change.
If the source code of a project is edited, the symbol information is updated immediately. Saved files are re-parsed and all browsing tools are updated. Therefore, you are always working with the newest symbol information that correctly mirrors the source code. Also, cross reference information is instantly updated.
6.3.3 Projects
In this section you will learn about a very important concept - the SNiFF+ project. A project is the main structuring element in SNiFF+ for grouping together files and directories that logically belong together in your file system. Once projects are created, you can then use SNiFF+ browsers to browse and understand the source code.
Project Directories and SNiFF+ Generated Files
Generally, you create a project from existing source files. When you create the project, you must specify the directory that will contain these source files. The directory you specify is the project directory. Each project in SNiFF+ corresponds to a project directory in your file system.
During project creation, SNiFF+ generates the following files and directories in a project directory:
- Makefile: This is the project makefile, generated when you choose to build your targets using SNiFF+'s Make Support.
- Project Description File (PDF): Each SNiFF+ project is described by a Project Description File (PDF) that stores the structure, the list of files, and the attributes of the project. SNiFF+ maintains a project's PDF for you.
- Project Generate Directory: This directory contains a number of files generated for the project and maintained by SNiFF+. Its default name is
.sniffdir
.Contents of a Project
Each SNiFF+ project contains the following:
- Your source files: You can include any type and number of source files in a project. For example, a typical SNiFF+ project might have C++ implementation and header files, yacc sources, documentation files, and files of a third-party documentation tools like FrameMaker.
- A Makefile: This is either your own makefile or SNiFF+'s makefile, depending on whether or not you use SNiFF+'s Make Support.
- The Project Description File (PDF): When you open a project, you are really telling SNiFF+ to load the project's PDF. When you modify a project's structure in any way (for example, by adding or removing files to the project), its PDF will be changed accordingly.
Subproject Structures
You can include other projects to create a hierarchical project structure. In SNiFF+, the process of including one project in another project is referred to as adding a subproject. The included project is known as a subproject.
Project Attributes
Each SNiFF+ project is described by a project description file (PDF). The PDF stores information such as the structure, the list of files, and the attributes of the project. A project's attributes would include file types added in the project, make parameters, parser options, and your choice of version control tools. These attributes can be modifed by the user. Refer to the SNiFF+ User's Guide for a complete list of project attributes.
Project Types
SNiFF+ distinguishes between two different project types: shared and absolute. The following table outlines the differences between these two project types:
Shared
*.shared
Yes
a path relative to a root directory
Absolute
*.proj
No
absolute path names
Shared Projects
Shared projects are for team development. Each team member has access to a shared project and can make changes to its files and structure. Shared projects are always used in conjunction with a configuration management and version control (CMVC) tool of your choice.
Shared projects offer a great deal of flexibility. Since all references to files and subprojects are relative to a root directory, you can easily move a shared project to another location on a file system.
It is recommended that you work with shared projects even if you do not initially work in a team development environment, since most single-user development work is eventually incorporated into a team development environment sometime during a project's life. With shared projects, the transition from a single-user to a team environment is much smoother than with absolute projects.
Absolute Projects
Absolute projects are most suitable for browsing code. Setting up an absolute project is easy. If you need to get your source code into SNiFF+ for browsing only, it makes sense to use SNiFF+'s absolute project type. For development, however, it is recommend that you use shared projects.
Organizing Project Structures
Project structures in SNiFF+ do not need to map directly to file system structures. Figure 6-1 on page 6-8 illustrates this idea, using a pSOSystem example.
In Figure 6-1 and Figure 6-2, you can see that although these directories are not subdirectories of
$PSS_ROOT/bsps/mbx8xx/src
:these projects are subprojects of
bsps_src.shared
:Tracking Dependencies in a Project
If you use SNiFF+'s Make Support, SNiFF+ tracks dependencies among source files. As a result, you can add files to a project or remove files from a project without having to worry about which files need to be recompiled. Only source files that need recompiling are recompiled. Before each build, just tell SNiFF+ to update a project's dependency information to reflect your changes.
If you do not use SNiFF+'s Make Support, you must update your own makefiles to reflect any changes in dependencies.
How to Create a SNiFF+ Project
Section 6.4, Using the pRISM+ Application Development Framework on page 6-18 shows how pRISM+ can help you to create source projects and integrate your source project with pSOSystem.
You can also refer to the SNiFF+ User's Guide for a detailed description of how to use the SNiFF+ Project Setup Wizard to create source projects.
Choosing Which Project to Open
To work on a source project, you first must open it. Suppose you have a project structure similar to that shown in Figure 6-2 on page 6-9. You have the following options:
- If you plan to modify and rebuild a single project -- for example, any subproject of
pdemo.shared
-- you can open only that project.- If you plan to modify and then rebuild the entire application
pdemo.shared
, SNiFF+ will automatically open all of its subprojects. You can then work onpdemo.shared
and all of its subprojects.- If you plan to modify and then rebuild the Board Support Package (
bsp_src.shared
) SNiFF+ will automatically open all its subprojects. You can then work onbsp_src.shared
and all the subprojects it includes.6.3.4 Workspaces
Workspaces are the means by which SNiFF+ implements the solution for two important requirements:
- De-coupling the changes of a single developer from those of other team members.
- Sharing as much information as possible.
A workspace is a directory tree where complete projects or parts of complete projects reside. Workspaces can override each other; SNiFF+ provides a merged view of these workspaces.
SNiFF+ distinguishes between private workspaces and shared workspaces. A private workspace is the directory that belongs to only one user and is modified only by that user. Every user has a private workspace and all the modifications to a project are done in the private workspace. A shared workspace is a directory that is accessible to any number of team members. There can be any number of shared workspace(s).
All private workspaces must have the same directory structure as the shared workspaces. Thus a private user makes a copy of a shared file or checks out a version of a shared file from the shared workspace. This private copy is stored in the private workspace which mimics the shared space in structure. While the file is checked in, SNiFF+ will use the private copy to override the shared version of the file to reflect any changes made to the file.
For repository-based version tools, SNiFF+ also treats the repository as a workspace. Extensive discussion on workspaces is provided in the SNiFF+ User's Guide.
6.3.5 Working Environments
Working environments are physical directories on your file system in which SNiFF+ shared projects reside. In SNiFF+, you open shared projects by first specifying in which working environment you work in.
When workspaces are associated with a default version control configuration, they are referred to as Working Environments (WE). In this document, however, the terms workspace and working environment are used interchangeably.
You must use Working Environments if:
- You are a member of a development team that works on the same set of files, and you do not use a third-party configuration management tool that furnishes a workspace model of its own, such as ClearCase.
- You develop software for multiple platforms (as a member of a development team or alone).
- You work alone on projects and plan to share them in the future.
NOTE: pRISM+ uses the Working Environments concept to enable team- development out of the box. The following concepts are relevant only if you are using SNiFF+ outside of the pRISM+ Application Development Framework.
You need not use Working Environments if:
- You work alone on a project and do not need to share your project with others now or in the future.
- You already use a third-party configuration management tool such as ClearCase.
- You use SNiFF+ to browse source code only.
For team-based development, Working Environments enable:
- shared access to your team data Repository.
- shared and transparent access to team source code.
- shared access to platform-specific object code.
- individual team members to work in isolation from the rest of the team.
- individual team members to work on selected configurations of a team project.
Single users can also benefit from using the Working Environments for the following reasons:
- Working Environments are easily movable.
- Working Environments enable you to always know which projects you are working on.
- A Repository Working Environment allows you to maintain one directory for your data Repository and another for your workspace.
- A Working Environment can be used by single users for single-platform or multi-platform development.
Types of Working Environment
There are four types of working environments:
- Repository Working Environment (RWE).
- Shared Source Working Environment (SSWE).
- Shared Object Working Environment. (Not supported by pRISM+ Development Environment)
- Private Working Environment (PWE).
Make Support and Working Environments
SNiFF+'s Make Support maintains information about dependencies and
include
directives across working environment boundaries, by supplying this information to your make utility and compiler. Although this information can be maintained in your own makefiles, it is recommended that you use SNiFF+ Make Support when you are doing team-based development within SNiFF+.Working Environment and Teams
Working Environments are designed to be used by teams. This section explains how Working Environments support team development. It also summarizes each working environment type and how the four types interact with each other.
Shared Access to Your Team Repository
Team members access and modify shared files using commands provided by your configuration management and version control (CMVC) tool. SNiFF+ provides an interface to your CMVC tools. This interface needs to know the location of your Repository.
You provide this information by defining a Repository Working Environment (RWE), which specifies the root directory of your Repository.
Shared and Transparent Access to Team Source Code
SNiFF+ requires you to specify the root directory of your team's shared source code. Once you have such a root directory, you must tell SNiFF+ where it is located. This is done by defining a Shared Source Working Environment (SSWE).
All team members can view or share the latest version of your software system as reflected by the source files in the SSWE. When browsing the source files, this view is read-only. When editing source files, team members work on private copies of the shared source files they want to modify. Team members never directly modify the shared source files in the SSWE. The view to all other source files (those not being modified) remains read-only.
Directories for Platform-Specific Object Code
The SNiFF+ Shared Object Working Environment is not used by pRISM+. Refer to the SNiFF+ User's Guide for a complete description of this type of working environment.
Isolating Individual Work from the Team
Developers must be able to work in isolation from other team members. They need their own workspaces to edit, compile and debug projects without interfering with the work of their team members. They also continually need to have access to their software system's most current source code and object code base.
SNiFF+ supports this type of working environment by allowing each team member to work in a private workspace. In SNiFF+, a Private Working Environment (PWE) is defined in order to specify the root directory of each team member's private workspace.
When working in your PWE, you have a read-only view of the shared source files located in your team's SSWE. When you need to modify shared source files, you check out the necessary files from your team's Repository. When you are satisfied that your changes are error free, you can check the modified files back into your team's Repository.
The next time your team's SSWE is updated, these changes are incorporated, and the shared source files in the SSWE once again reflect the most current state of your software system.
6.3.6 How File Sharing Works
SNiFF+ supports file sharing among Working Environments by requiring that all affected Working Environments have the same project directory structure. This is the easiest way for file sharing to work.
A SNiFF+ project's PDF stores structural information about the project such as the names of project files, their location relative to the project directory, and the names and locations of any subprojects. When all Working Environments that share files have the same project directory structure, SNiFF+ can easily find any project files or subprojects.
The project directory structure of the Shared Source Working Environment (SSWE) is the basis for all other working environment project directory structures. SNiFF+ automatically copies the SSWE's project directory structure into your private working environments when you open any shared projects from your private Working Environment. SNiFF+ copies only the SSWE directory structure, not the directory contents. Figure 6-3 on page 6-15 illustrates the idea of equivalent project directory structures.
The PWEs have the same project directory structure as the SSWE. The two team members working in PWE1 and PWE2, respectively, share the source files in the SSWE. When browsing source files, their view to the files is read-only. When editing source files, they work on local, writable copies of the source files they have checked out from the Repository. When compiling in their PWEs, object code is created locally from both shared (read-only) source files and local (writable) sources files.
A Closer Look at File Sharing
Let's look more closely at the SSWE, PWE1 and PWE2. For example, the
foo
project directory in the SSWE contains the following:
- The Project Description File
foo.shared.
- The Project Makefile.
- The following source files:
foo.c
,foo.h
,bar.c
, andbar.h.
Figure 6-4 shows the contents of the
foo
project directory in the SSWE, PWE1 and PWE2. In this example, two developers (Joe Developer and Jane Developer) own the PWEs. Joe Developer owns and works in PWE1; Jane Developer owns and works in PWE2. Both Joe Developer and Jane Developer share common source files located in the SSWE.As Figure 6-4 shows, Joe Developer has checked out only one file from the
foo
project directory in hisPWE: foo.c
. He has a read-only view to all other files. Jane Developer has checked out three files from thefoo
project directory into her PWE:bar.c
,bar.h
, and the Project Description File,foo.shared
.
NOTE: To make structural changes to a SNiFF+ project, you must check out the project's Project Description File. Examples of structural changes include adding and removing project files and subprojects, and changing project attributes, such as the name of project targets.
Figure 6-4 shows that Joe Developer has a read-only view to files checked out by Jane Developer, and Jane Developer has a read-only view to files checked out by Joe Developer. While Joe Developer is making changes to his local copy of
foo.c
in his PWE, Jane Developer can only browse the original copy of the file located in the SSWE.This is an example of the exclusive file locking; when one team member has checked out a file in his PWE, all other team members can only browse this file. SNiFF+ configuration management and version control (CMVC) interface can provide other file-locking mechanisms as well. Your CMVC tool determines which mechanisms are available for use.
When Joe Developer builds
foo.o
from his private area. SNiFF+ ensures that his build will use the local copy of modifiedfoo.c
. SNiFF+ does this by having the local copy override the same file in the shared area for Joe Developer. SNiFF+ allows Joe Developer to use all other files in the shared area in order to complete his build.Changes made to
foo.c
are local to Joe Developer and are not visible to Jane Developer. Similarly, Jane Developer can derive from the shared area her own copy of any of the files and make her modifications, eventually overriding the shared versions of the same files.
NOTE: File overriding is realized on
- UNIX hosts by symbolic links to the respective files.
- Windows hosts by copying of the respective files.
6.3.7 SNiFF+ Build and Make Support
SNiFF+ Make Support offers the following features:
- It comes with its own makefiles.
- It is based on standard UNIX Make Tools.
- It is fully integrated with Working Environments to build targets across multiple shared Working Environments.
- It automatically generates make support files that contain data about include paths, dependencies lists and object files lists for shared projects.
- It automatically provides make rules for recursively building a project's target.
- It provides automatic support for multi-platform development and works with compilers, linkers, archivers, and other build tools of your choice.
- It maintains your build system by automatically updating make support files.
6.3.8 Building Targets When Using Team Working Environments
If you use SNiFF+ Working Environments for your team software development projects, you must use SNiFF+'s Make Support in its entirety (including makefiles and make support files) for building your object files and targets.
SNiFF+'s Make Support allows you to take full advantage of Working Environments by providing a mechanism for automatically sharing source and object files between members of a team. As a result, it is not possible to use your own makefiles with shared Working Environment.
One major exception is the pSOSystem makefiles which have been extended to support team environments. This allows you to use the hybrid make model in a team development environment. The hybrid make model is described in Section 6.6.8, Hybrid Make Model on page 6-46. For details about pSOSystem makefile extensions for team support, refer to Appendix E.
![]() |
![]() |
![]() |