TOC PREV NEXT



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:

Contents of a Project

Each SNiFF+ project contains the following:

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:

Project Type
Default
Can project files be shared among developers?
Project attributes refer to project related files and subprojects using
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:

6.3.4 Workspaces

Workspaces are the means by which SNiFF+ implements the solution for two important requirements:

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:

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:

For team-based development, Working Environments enable:

Single users can also benefit from using the Working Environments for the following reasons:

Types of Working Environment

There are four types of working environments:

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:

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 his PWE: foo.c. He has a read-only view to all other files. Jane Developer has checked out three files from the foo 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 modified foo.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:

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.


TOC PREV NEXT