users guide vxworks

4.1SNiFF+/SNiFF+ PROU S E R S G U I D E A N D R E F E R E N C E

Copyright 8/29/02 Wind River Systems, Inc.

ALL RIGHTS RESERVED. No part of this publication may be copied in any form, by photocopy, microfilm,retrieval system, or by any other means now known or hereafter invented without the prior written permission of WindRiver Systems, Inc.

AutoCode, Embedded Internet, ESp, FastJ, IxWorks, MATRIXX, pRISM, pRISM+, pSOS, RouterWare, Tornado,VxWorks, wind, WindNavigator, Wind River Systems, WinRouter, and Xmath are registered trademarks or servicemarks of Wind River Systems, Inc.

BetterState, Doctor Design, Embedded Desktop, Envoy, How Smart Things Think, HTMLWorks, MotorWorks,OSEKWorks, Personal JWorks, pSOS+, pSOSim, pSOSystem, SingleStep, SNiFF+, VxDCOM, VxFusion, VxMP,VxSim, VxVMI, Wind Foundation Classes, WindC++, WindNet, Wind River, WindSurf, and WindView aretrademarks or service marks of Wind River Systems, Inc. This is a partial list. For a complete list of Wind Rivertrademarks and service marks, see the following URL:

http://www.windriver.com/corporate/html/trademark.html

Use of the above marks without the express written permission of Wind River Systems, Inc. is prohibited. All othertrademarks mentioned herein are the property of their respective owners.

Corporate HeadquartersWind River Systems, Inc.500 Wind River WayAlameda, CA 94501-1153U.S.A.

toll free (U.S.): 800/545-WINDtelephone: 510/748-4100facsimile: 510/749-2010

For additional contact information, please visit the Wind River URL:

http://www.windriver.com

For information on how to contact Customer Support, please visit the following URL:

http://www.windriver.com/support

SNiFF+/SNiFF+ PRO Users Guide and Reference, 4.1August 29, 2002Part #: M000-5700-01

Par

ParContents

t I Documentation GuidelinesThis Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

The SNiFF+ Documentation SetGuidelines . . . . . . . . . . . . . . . . . 4Feedback and Useful Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Menu References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8A Note on Unix/Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Typography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

t II Projects and WorkspacesWhat is a Project? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

IntroductionProjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Some Advantages of Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14What Does a Project Know? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

What is a Workspace? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17IntroductionWorkspaces and Projects . . . . . . . . . . . . . . . . . . . . 18

What are Workspaces For? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Sharing or Layering Workspaces. . . . . . . . . . . . . . . . . . . . . . . . . . 20What is a Workspace?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Location of Root Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

SNiFF+/SNiFF+ PRO 4.1Users Guide and Reference

Part III Workspace ManagementWorkspace Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Workspace Organizational Systems . . . . . . . . . . . . . . . . . . . . . . . .30

Hierarchical vs. Flat Workspace System . . . . . . . . . . . . . . . . . . . . .31Reorganizing Workspaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33The Workspaces Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Stand-Alone Workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36What is a Stand-Alone Workspace? . . . . . . . . . . . . . . . . . . . . . . . .36Stand-Alone Workspace Plus Project . . . . . . . . . . . . . . . . . . . . . . .36Stand-Alone Workspace without Project . . . . . . . . . . . . . . . . . . . . .38Special Case: Stand-Alone Analysis Environment . . . . . . . . . . . . .39

Workspaces and User Autonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41Workspace Configuration Data . . . . . . . . . . . . . . . . . . . . . . . . . . . .42Autonomous Workspace Configuration . . . . . . . . . . . . . . . . . . . . . .42Site-Level Workspace Configuration . . . . . . . . . . . . . . . . . . . . . . . .44

Team Workspaces from Scratch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46PreparationSetting Up Team Projects . . . . . . . . . . . . . . . . . . . . .46The First Team Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48The Project Creation Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49The Build-Target Setup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . .52Post-Setup Project Tuning [Optional] . . . . . . . . . . . . . . . . . . . . . . .52First Check-In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53Behind the Scenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53Organization and Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

New Team Members (Flat Workspace System) . . . . . . . . . . . . . . . . . . . .57Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58What Do You See? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58Create a Repository Node? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59Create a New Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60First Check-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Open the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62More Workspaces for Yourself . . . . . . . . . . . . . . . . . . . . . . . . . . . .63More Team Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63

Contents

New Team Members (Hierarchical Workspace System) . . . . . . . . . . . . . 65Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66What Do You See? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Create a Repository Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Create a Node for the Shared Workspace. . . . . . . . . . . . . . . . . . . 67

ParCreate a Dependent Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . 68More Workspaces for Yourself . . . . . . . . . . . . . . . . . . . . . . . . . . . 69More Team Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Managing Workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Reorganizing Workspaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Workspace Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Modifying Workspace Build Properties . . . . . . . . . . . . . . . . . . . . . 74Version-Controlling Build Properties . . . . . . . . . . . . . . . . . . . . . . . 75

t IV Working with ProjectsProject Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82You Only Create a Project Once . . . . . . . . . . . . . . . . . . . . . . . . . . 82Wizard or Template? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Project and Workspace Creation in One . . . . . . . . . . . . . . . . . . . . 83Project Creation in Existing Workspaces. . . . . . . . . . . . . . . . . . . . 84Post-Setup Project Tuning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Project Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Absolute Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Working with Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Opening Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Open-Project Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Managing Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Modifying Project Structure and Content . . . . . . . . . . . . . . . . . . . . 97Using the Project Managers Other Files Tab . . . . . . . . . . . . . . . 99Modifying Project Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Working with File Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103What are File Types?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Managing File Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104PreferencesFile Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Creating New File Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106What are Derived File Types? . . . . . . . . . . . . . . . . . . . . . . . . . . . 107


Working with Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111Fixed and/or Free Form?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112Modifying Project Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113File Type Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115Using Different Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115

ParFortran Parser Command Line Arguments . . . . . . . . . . . . . . . . . .116Preprocessing Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117

Documenting Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120Generating C++ Documentation . . . . . . . . . . . . . . . . . . . . . . . . . .121Browsing Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121Documentation Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122

Synchronizing Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126Synchronizing Projects within SNiFF+ . . . . . . . . . . . . . . . . . . . . .127Synchronizing Projects Outside of SNiFF+ . . . . . . . . . . . . . . . . . .128Update Script Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131

t V SNiFF+ PRO Build/Debug: How ToC/C++ Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139

Build-Target Wizard or Project Properties? . . . . . . . . . . . . . . . . . .140C/C++ Build: Summary of Steps . . . . . . . . . . . . . . . . . . . . . . . . . .140Setting C/C++ Targets and the Debugger Adaptor . . . . . . . . . . . .141Setting Include Paths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143Verify Tool Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146

Java Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149Build-Target Wizard or Project Properties? . . . . . . . . . . . . . . . . . .150Java Build: Summary of Steps . . . . . . . . . . . . . . . . . . . . . . . . . . .150Identify Libraries for Browsing Only. . . . . . . . . . . . . . . . . . . . . . . .151Setting Java Application Targets and the Debugger Adaptor . . . .153Setting Java Build Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154Verify Compiler and Other Java Tool Settings . . . . . . . . . . . . . . .157Building Java Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159Remote Java Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160

Ada Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165What You Need (General) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166GNAT and Tornado/VxWorks Requirements . . . . . . . . . . . . . . . .166

Contents

Run the GNAT Integration Script . . . . . . . . . . . . . . . . . . . . . . . . . 170What the GNAT Integration Script Does . . . . . . . . . . . . . . . . . . . 171Check Workspace Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Setting Ada Targets and Debugger Adaptor . . . . . . . . . . . . . . . . 175Ada and C/C++ Mixed Language Projects . . . . . . . . . . . . . . . . . 176JAR, Java IDL, JNI, and RMI Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 181Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Set Project Targets and Build Tools . . . . . . . . . . . . . . . . . . . . . . 182Check Tool Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

IDL Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188IDL File Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Projects and Derived File Types . . . . . . . . . . . . . . . . . . . . . . . . . 189What to Do. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189How File Compilation Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Browsing IDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Custom Build Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Projects with Custom Build Systems . . . . . . . . . . . . . . . . . . . . . . 194Enable Menu Commands for Custom-Built Targets . . . . . . . . . . 195

Remote Build and Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Setting up Remote Build Hosts for Workspaces . . . . . . . . . . . . . 198Verify Project Platform Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 202Working on Remote Hosts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Modifying Build Tools and Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Where to Change the Tool Settings. . . . . . . . . . . . . . . . . . . . . . . 206

Running and Debugging Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211The Application Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Running Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Debugging Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213The Debugger Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . 213Debugger Views and Dialogues . . . . . . . . . . . . . . . . . . . . . . . . . 214Working With Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Variables View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Execution Context View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216


Memory View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217Registers View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217Multiple Simultaneous Debugger Sessions . . . . . . . . . . . . . . . . . .217

Part VI SNiFF+ PRO Build System Concepts

ParSNiFF+ PRO Build System: Introduction. . . . . . . . . . . . . . . . . . . . . . . . .221Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223Make Command and Redirection Directory. . . . . . . . . . . . . . . . . .224Build Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226Build Tool Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228

A Closer Look at Build Tools, Tool Settings and Platforms . . . . . . . . . . .231Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232How are Platforms and Build Tools Related? . . . . . . . . . . . . . . . .232What is a Build Tool Template?. . . . . . . . . . . . . . . . . . . . . . . . . . .233What is a Build Tool Template For? . . . . . . . . . . . . . . . . . . . . . . .235What is a Platform? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235Platforms, Build Tools and Settings. . . . . . . . . . . . . . . . . . . . . . . .236Build ToolsBits and Pieces . . . . . . . . . . . . . . . . . . . . . . . . . . . .237

Inheritance of Build Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241Cascading and Levelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242Preferences Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242Workspace Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243Project Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243File Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243

Building Project Structures and Compiling Files . . . . . . . . . . . . . . . . . . .245Project Structure and the Build System. . . . . . . . . . . . . . . . . . . . .246File Compilation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246

t VII Version Control and Configuration ManagementIntegration of Version Control Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . .251

Version Control Tools and SNiFF+ . . . . . . . . . . . . . . . . . . . . . . . .252Setting the Version Control Integration . . . . . . . . . . . . . . . . . . . . .253

CMVC: Basic Concepts and Terminology . . . . . . . . . . . . . . . . . . . . . . . .255Basic CMVC Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256What is a Configuration? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256

Contents

What is a Freeze-Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257What is a Change-Set? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257What is a Branch? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257What is HEAD? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258What is INIT? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Working with Branches: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Situations for Using SNiFF+s Branch Support . . . . . . . . . . . . . . 261Creating a Branch Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261Working on the Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Workspaces, Configurations, and Branches . . . . . . . . . . . . . . . . . . . . . 263How Does a Workspace Access the Repository? . . . . . . . . . . . . 264Workspaces, Branches and Default Configurations . . . . . . . . . . 264Example: Default Configurations and Branch-Work . . . . . . . . . . 265Default Configurations and Hierarchical Workspaces . . . . . . . . . 268

Integrating ClearCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270Integration Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270How to integrate SNiFF+ and ClearCase . . . . . . . . . . . . . . . . . . 271VOBs and Views in SNiFF+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271Creating SNiFF+ Projects for ClearCase-Controlled Code . . . . . 271Changing the config spec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Synchronizing SNiFF+ Projects with View Changes . . . . . . . . . . 273Using clearmake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Integrating SNiFF+ with CVS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278Tell SNiFF+ to use CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Import Code not yet under CVS Control . . . . . . . . . . . . . . . . . . . 279Import Code From a CVS Repository . . . . . . . . . . . . . . . . . . . . . 282Create Additional Workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . 284Initial Check Out in New Workspace . . . . . . . . . . . . . . . . . . . . . . 286CVS/SNiFF+ Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287Synchronizing SNiFF+ Projects with Changes on Disk . . . . . . . . 287Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Integrating SNiFF+ with PVCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Version and Compatibility information . . . . . . . . . . . . . . . . . . . . . 293


PVCS Version Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293The SNIFF+ PVCS Adaptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294Setting up Projects with SNiFF+ and PVCS . . . . . . . . . . . . . . . . .295PVCS and Adaptor Configuration Files . . . . . . . . . . . . . . . . . . . . .295

ParIntegrating SNiFF+ with Visual SourceSafe . . . . . . . . . . . . . . . . . . . . . .299Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .300Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .300Setting up a SNiFF+ Project with Visual SourceSafe . . . . . . . . . .301Checking In Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .302Integration Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303

t VIII Editor and Other IntegrationsEmacs Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307

Integration Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .308How the Emacs Integration Works . . . . . . . . . . . . . . . . . . . . . . . .308Integrating Emacs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309Working with Emacs and SNiFF+ . . . . . . . . . . . . . . . . . . . . . . . . .311Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .313

SlickEdit Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316Working with Visual SlickEdit and SNiFF+ . . . . . . . . . . . . . . . . . .316

Vim Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319Integration Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320How the Integration Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320Making the Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323Working with Vim and SNiFF+ . . . . . . . . . . . . . . . . . . . . . . . . . . .324Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325

Rational Rose Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .330Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .330Navigation from SNiFF+ to Rational Rose . . . . . . . . . . . . . . . . . .332Navigation from Rational Rose to SNiFF+ . . . . . . . . . . . . . . . . . .335File Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336Technical Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336

Contents

Part IX SniffAPISniffAPI - Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340Basic Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

ParOverall Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340Query Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342Scope Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345The ID Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

SniffAPIGetting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353What You Need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354Directory Structure of SniffAPI. . . . . . . . . . . . . . . . . . . . . . . . . . . 354Setting up JAR files for compilation of a SniffAPI client. . . . . . . . 354Compiling the Sample Program. . . . . . . . . . . . . . . . . . . . . . . . . . 356Running the Sample Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

t X Advanced ReferenceCustom Menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362The Custom Menu Configuration File . . . . . . . . . . . . . . . . . . . . . 363Custom Menu Configuration File: EBNF Specification . . . . . . . . 367

Sniffaccess. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371Introducing Sniffaccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372Preparing the Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372Invoking Sniffaccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Connection Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374Input and Output of Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381Sniffaccess Command Reference . . . . . . . . . . . . . . . . . . . . . . . . 391Appendix: What is Python? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

Configuring the C++ Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395General Format of the Parser Configuration File. . . . . . . . . . . . . 395Ignore-Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396Replace Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397Definition of Wordchars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397


Parser Filter Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398Context Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .401General Parser Configuration Options . . . . . . . . . . . . . . . . . . . . .406C++ Parser Specific Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . .406Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .408

ParCross-Reference Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .413Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .414Extracting Symbol Information. . . . . . . . . . . . . . . . . . . . . . . . . . . .414C/C++: Automatic Generation of Cross-Reference Information . .415Workspaces and Cross-Referencing. . . . . . . . . . . . . . . . . . . . . . .416Location and Repair of X-Ref Databases . . . . . . . . . . . . . . . . . . .419Synchronizing Workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .419

t XI AppendixRegular Expressions in SNiFF+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424Quick Reference - Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424Literals and Metacharacters . . . . . . . . . . . . . . . . . . . . . . . . . . . . .426Character Classes or Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .432Groups, Alternatives and Back References. . . . . . . . . . . . . . . . . .435

Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .439SNiFF+ System Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .440Version Control Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .443Build Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .447

Do

Pcumentation Guidelines This Manual Conventions

art I

SNiFF+/SNiFF+ PRO 4.1Users Guide and Reference2

1This Manual

Ov3erview The SNiFF+ Documentation SetGuidelines page 4

Beginners Guides page 4 Users Guide and Reference page 5 GUI and Menu Command Reference page 5 Getting Started for Tornado Teams page 5 Installation Guide, Release Notes, SNiFF+ Papers page 5

Feedback and Useful Links page 6


1.1 The SNiFF+ Documentation SetGuidelinesThis manual is part of the SNiFF+ documentation set, and this chapteroffers a few guidelines as to what you can expect to find where in thedocumentation.

1.1.14

Most SNiFF+ documentation is available online, under the Help menu.If you have installed the documentation package, print-formatted PDFsare located in the docs subdirectory of your SNiFF+ installation.

Beginners Guides

Two Beginners Guides, one for C/C++ Projects, and the other for JavaProjects, should help to get you going.Examples, tips, and hands-on how-to descriptions introduce you to manyaspects of using SNiFF+.The Beginners Guides are divided into four major sections.

Browsing TourCreate a Project to browse either your own source code, or sample codeprovided with SNiFF+. Get to know the SNiFF+ browsing tools and navi-gation features.

SNiFF+ PRO: Build and Debug TutorialUse sample code in a hands-on tutorial for setting up, building, anddebugging targets.

CMVCConfiguration Management and Version ControlCreate a version controlled Project and apply basic version controlcommands.

Working in TeamsAn outline of procedures for setting up a team work-organization.

This ManualThe SNiFF+ Documentation SetGuidelines

11.1.2 Users Guide and Reference

The Users Guide and Reference provides more in-depth informationthan the Beginners Guides. Topics covered include:

Fundamental SNiFF+ concepts: Projects and Workspaces

1.1.

1.1.

1.1.5

Workspace and Project management How-to guides to procedures Technical descriptions of various subsystems (e.g. Build System) Version Control and Configuration Management Integrations of version control tools, editors, and other tools Regular expression usage in SNiFF+

3 GUI and Menu Command Reference

This is a reference to functionality of graphical user interface elementsand menu commands. This is also accessed when you use the ContextHelp ().

4 Getting Started for Tornado Teams

This tutorial introduces creating, building and debugging a downloadableapplication module, as well as how to access various Tornado tools fromthe SNiFF+ PRO IDE.

5 Installation Guide, Release Notes, SNiFF+ Papers

The Installation Guide takes you through installation and licensing onUnix/WindowsRelease Notes include important, late-breaking information on the cur-rent release.SNiFF+ Papers provide additional information on topics not covered inthe standard documentation.


1.2 Feedback and Useful LinksFeedbackYour feedback is always very welcome.6

Please send feedback to one of our support e-mail addresses. Europe

[email protected] USA

[email protected]

Useful Links A number of useful links (Knowledge Base, FAQs, Users Mailing List ...)

are available under:http://www.windriver.com/sniff

2Conventions

Ov7erview Terminology page 8 Menu References page 8 A Note on Unix/Windows page 8 Typography page 9


2.1 TerminologyThe terminology described in this section is used throughout this guideand in all SNiFF+ documentation.

SNIFF_DIR4

2.2

2.38

This refers to your SNiFF+ installation directory. Symbol

Any programming language construct such as a class, method, etc.

Menu References Choose MenuName > MenuCommand.

Read this as: "From the menu named MenuName, choose the menucommand named MenuCommand."

Choose Right-click > MenuCommandRead this as: Choose a menu command from the context menu thatappears when you click the right mouse button.

A Note on Unix/Windows We use forward slashes ( / ) in path specifications. If you are on Win-

dows, read backslash ( \ ) instead. The screenshots in this manual are all done on Windows NT. If you are

working on Unix, what you see on your screen may look slightly different.

ConventionsTypography

2

2.4 Typography

Capitalized Words Names of tools, windows, dialogs and menus start9

with capital letters.Examples: Symbol List, Tools menu, File dialog.Also SNiFF+ specific meanings of concepts are capi-talized.Examples: Project, Workspace.

Italics Names of manuals, newly introduced terms, and em-phasized words are in italics.Examples: User's Guide, the Workspace concept, donot do something.

Boldface andBold italics

Menu, field and button names are printed in boldface.Place-holders for symbols, selections or other stringsin menus are in bold italics.Example: Browse > ClassName...

Monospace Code examples and symbol, file and directory names,as well as user entries are printed in monospace type.Examples: .login, PATH, class VObject.On the command line, enter abc.

Special keys are printed in monospace type with en-closing '< >'.Examples: , , .

Pr

Pojects and Workspaces What is a Project? What is a Workspace?

art II

3What is a Project?

Ov13erview IntroductionProjects page 14

Working with Projects page 14 Some Advantages of Projects page 14 What Does a Project Know? page 16


3.1 IntroductionProjectsA SNiFF+ Project is the main structuring element for grouping files onyour file system that logically belong together. In other words, elementsthat you want to handle (browse, build, or document) together can be

3.1.1

3.214

grouped (modularized) in Projects, without having to modify file-systemlocations.A software system will generally be structured as a hierarchical tree ofProjects (or trees of Projects), whereby the relative position of nodes inthe tree reflects logical (build-)dependency relationships. For example,building a top-level Project target will generally depend on a prior build ofits (recursive) Subprojects.

Working with ProjectsThis chapter merely serves as an introduction to the SNiFF+ Project as aconcept. The where-and-how of Project creation, maintenance etc. isdescribed under Working with Projects page 79.

Some Advantages of ProjectsFile-system directories can be, and generally are, used for grouping filesthat belong together in some way.However, over time (legacy!) the code base grows, interfaces blur, anddirectories are no longer the clearly delimited logical units they mightonce have been.But changing file system locations on any scale is generally expensivedue to potential problems with the build and version control systems(depending on the system used).This is where Projects come into the picture.What a Project knows is persistently stored in a Project Description File(PDF). The PDF is itself part of the Project and can therefore be conve-niently version controlled together with the source files.Files and Subprojects are quickly added to, or removed from, Projectswithout any changes being made to file-system locations. The PDF(s)can be checked in, and then used by all the members of a developmentteam via SNiFF+ Workspace mechanisms (see What is a Workspace? page 17).

What is a Project?Some Advantages of Projects

3

If you use SNiFF+ Build Support, the Project structure defines the tra-versal order of Projects during system Build; furthermore SNiFF+ can,based on the parsed source files, also generate per-Project dependencyinformation. This means that once targets and the structural organiza-tion of the tree have been defined, the build system is practically self-15

maintaining.


3.3 What Does a Project Know?Among other things, a Project knows:

The files that belong to the Project.16

These can include source code files, as well as any other files (e.g. docu-mentation) you define. The PDF itself will also always be listed, as wellas the PDF(s) of its immediate Subprojects.

The File Types that the Project recognizes.A SNiFF+ File Type is identified by a signature pattern, not only the file-name extension. File Types are categorized and associated withnumerous, configurable properties that tell SNiFF+ what to do with filesof a given type (which parser, compiler, template, etc. to use).

Project-specific Build properties.This includes data such as target type and name, etc.

The location of Project-related symbol, cross-reference, and Build Sup-port information.

4What is a Workspace?

Ov

The Generated Files Location page 23

ot17

Location of Root Directories page 24 Source Root Location page 24 Relative Project and Makefiles Location page 25 Exception: Generated Files (and Project and Makefiles) Locations N

Relative page 25erview IntroductionWorkspaces and Projects page 18 What are Workspaces For? page 18

Storage page 18 Different Tasks page 18 Working in Teams and Version Control page 19 Keeping up-to-date page 19 Default Configurations and Branch Development page 19 Building page 20 Flexibility page 20

Sharing or Layering Workspaces page 20 What is a Workspace? page 21

TerminologySource Root, Project and Makefiles Location, Gener-ated Files Location, and Repository page 21

The Source Root page 22 The Project and Makefiles Location page 23


4.1 IntroductionWorkspaces and ProjectsThe two fundamental SNiFF+ Concepts, Workspace and Project, interre-late. We therefore recommend that you first familiarize yourself with thechapter What is a Project? page 13 before going on to look at Work-

4.2

4.2.1

4.2.218

spaces.

What are Workspaces For?A Workspace is an environment used for writing, analyzing, version con-trolling, and building products from your source code. Over and abovethis, it is used for parallel work on (sharing) the same code base.Again, it is an environment, and not simply a file-system location. But,before going on to look at what a Workspace is, take a look at what it isfor.

Storage

One function of a Workspace is storage. When Projects are first openedin a Workspace, you can have SNiFF+ generate symbol, cross-refer-ence, and dependency information.This information is stored persistently in the Workspace, and only needsto be incrementally (if at all) updated when next you open Projects in theWorkspace.

Different Tasks

If you, as an individual, are working on different, unrelated software sys-tems, you may or may not use a different Workspace for each of these.This is a question of personal preference; different Projects already mod-ularize different systems.The real power of Workspaces is that you can use multiple Workspacesto work on one and the same software system, for example, to use forexperimental work, testing, and parallel work on different Configurationsof the system.

What is a Workspace?What are Workspaces For?

4.2.3 Working in Teams and Version Control

If you are a member of a development team, you, and every other mem-ber of the team, must be able to access a common code base, and yetalso be able to work in isolation, without interference.

4.2.

4.2.19

4This means that, while individuals might want to work on the same codein different environments, each member of a development team musthave at least one personal Workspace.To handle this, each Workspace knows two things. Firstly, where to checkfiles out from (a Repository, or your version control systems equivalent);all related Workspaces will access the same Repository. Secondly, aWorkspace must know where to check out files to (a root directory,known as the Workspaces Source Root); each Workspace has its own,unique Source Root.

4 Keeping up-to-date

By regularly (for example overnight) updating (or Synchronizing, as it iscalled in SNiFF+) Projects in a Workspace, you can be sure that allsource files, Projects, symbol, dependency and (optionally for C/C++Projects) cross-reference information are up-to-date, no matter whichsubset of Projects you open.

5 Default Configurations and Branch Development

You can set a default Configuration for a Workspace, or, if your versioncontrol system supports Branches, a default Branch.That is, for example, a part of your team works on forward-developmenton the main application Branch, another team is adapting a library, andyet another group is working on bugfixes for a released Configuration ofthe software system.Each of these groups can configure their Workspaces so that files areautomatically checked in/updated to the respective branches; check-outswill also automatically try Branch revisions first.When Projects are synchronized, this is automatically done with respectto the Branch/Configuration that is set for the Workspace.(See also Workspaces, Configurations, and Branches page 263.)


4.2.6 Building

A teams work may be distributed over different operating systems, andthe product may be targeted to run on multiple systems.On the one hand, this may mean that you are working on a Windows

4.2.7

4.320

machine but need to build and debug on a remote Unix machine. On theother, if you access your sources over a network file system, you canimprove Build performance by redirecting output to a directory on yourlocal machine.Workspace defaults can be set for the target operating system, whereand how you build (for example, with debug information or optimized),and you can switch between different options and target platforms withinone and the same Workspace.(See also SNiFF+ PRO Build/Debug: How To page 137.)

Flexibility

Development teams are dynamic, they can grow and shrink again. As ateam grows, new Workspaces that are consistent with existing ones arequickly created, and, conversely, simply removed when no longerneeded.

Sharing or Layering WorkspacesWorkspaces can be shared. This is done by layering Workspaces intrees.The most common tree is probably one Workspace (first layer) which isshared, or accessed, by a number of personal Workspaces (secondlayer).Layering Workspaces can have some advantages; however, there arealso a number of caveats. This is discussed under Workspace Organiza-tion page 29.

What is a Workspace?What is a Workspace?

4.4 What is a Workspace?Although the physical organization of a Workspace is more or less animplementation detail that you need not worry too much about, it is usefulto at least have an idea of how it looks, which is what Figure 4-1 A Work-

4.4.21

4spacePhysical Organization (Simplified) page 22 is about.A Workspace is a multi-bodied thing; an organized collection of sub-systems. These subsystems are maintained below three root locations,the Source Root, and the Project and Makefiles Location, and the Gener-ated Files Location. Each Workspace has these root locations.Furthermore, if you are working in a development team and/or versioncontrol your Projects, a Workspace must know, at least indirectly, whereyour version control system stores file revisions.

1 TerminologySource Root, Project and Makefiles Location, Generated FilesLocation, and Repository

Each Workspace points to its own Source Root, its own Project andMakefiles Location, and its own Generated Files Location, and may beassociated with a specific Repository.

The Source Root of a Workspace points to the root directory (some-where) below which all sources of a software system should lie (or will liewhen they are checked out/opened for the first time).

The Project and Makefiles Location is used for storing Project DescriptionFiles, Makefiles, and Build Support files. These can therefore kept in adirectory separate from the source files, but still be normally version con-trolled. Generally, a subdirectory below the Source Root is used.

The Generated Files Location of a Workspace is the root location forSNiFF+-generated files (symbol tables, etc.) relating to the sources belowthe Source Root.(There are some exceptions to this rule, however, these will be pointedout in the appropriate contexts.)

A Repository is a location used by your version control system to archivefile revisions.


Figure 4-1 A WorkspacePhysical Organization (Simplified)

4.4.2

Tresoudire

Workspace22

The Source Root

The only thing a Workspace knows about your source code files is thelocation of a root directory.All the source files that are, or can be, in a Workspace should be some-where below this root directory, known as the Source Root.Apart from this, a Workspace knows nothing about the source files them-selves, or how they are organized.Information about which files are, or can be, in a Workspace, and howthey are organized is maintained in SNiFF+ Projects.The important thing about the Source Root is that each Workspace musthave its own, unique Source Root.(See also Source Root Location page 24.)

e ofrce codectories

Copy ofdirectorystructureonly

Pointer to Source Root location and other global information

Project andMakefiles &Generated Files

Once sources are in Projects,file system locations are nolonger relevant.The copy of the originaldirectory structure is anorganizational artifact usedinternally by SNiFF+.

Workspace InfoProject InformationFile System Directory

What is a Workspace?What is a Workspace?

4.4.3 The Project and Makefiles LocationThe second root location that a Workspace knows is the Project andMakefiles Location.This is can be the same as the Source Root location, or, as is usually the

4.4.23

4case (unless you use ClearCase), the same as the Generated FilesLocation.If you use ClearCase for version controlling, this will normally be a subdi-rectory of the Source Root; however, the Generated Files Location will bea separate location (see below).

4 The Generated Files Location

The third root location that a Workspace knows is the Generated FilesLocation. Unless you are using ClearCase, this location is usually thesame as the Project and Makefiles Location (above). If you are usingClearCase, performance can be improved by specifying this location out-side the Source Root.SNiFF+ generates and maintains all the information it needs below thisroot directory. (See also Relative Project and Makefiles Location page25).Much of this information is specific to Projects. However, global informa-tion that applies to all Projects in (that use) the Workspace is also main-tained here.The data maintained under the Generated Files Location can be subdi-vided into the following sub-systems:

The Project SystemThis is discussed in more detail under What is a Project? page 13. Asystem of Project Description Files (PDFs) describes, among otherthings, which files can be opened in a Workspace, and how these filesare organized (this need not necessarily conform to the file-system orga-nization). These files may, however, especially under ClearCase, also bestored elsewhere.

Symbol and other informationThis includes parser-generated data about symbols (classes, methods,etc.), a database with cross-reference and (C/C++) dependency informa-tion, and indexes for string retrievals.

The Version Control SystemThe Workspace inherits this information from a Repository node and,under some version control systems, a Default Configuration node.These nodes know which version control system is used and where to


check files out from, for example, a Repository location for RCS, or theview extended path name for ClearCase and which revisions to checkout/in by default. File revisions are checked out from the version controlsystem to the locations below the Source Root.

The Build System

4.5

4.5.124

Using the SNiFF+ Build System is optional (licensed as SNiFF+ PRO). Ifyou use the SNiFF+ Build System, global Build macros, rules, andsettings are generated and maintained per Workspace. Many of thesesettings represent defaults that can be individually overridden at Projectand, if necessary, file level. These files may, however, especially underClearCase, also be stored elsewhere.(See also SNiFF+ PRO Build System Concepts page 219.)

Location of Root DirectoriesIn theory, the subsystems that make up a Workspace could be anywhere.That is, their respective root locations could be specified by different,unrelated absolute paths.Although this is not generally recommended, it can be useful under cer-tain circumstances.

Source Root Location

The Source Root location will always be different for each Workspace.When you create a Project for existing sources, the Source Root shouldbe the root directory that holds all sources belonging to the software sys-tem you are importing to SNiFF+. (You would, of course, excludeunwanted directories and file types from the Project.)Once the Project exists (Projects are only created once), you create newWorkspaces that each point to a different Source Root location (the userof the Workspace must have write permission to the new location).Then, you check out the existing root Project to the new Workspace.

What is a Workspace?Location of Root Directories

4.5.2 Relative Project and Makefiles LocationTo ensure consistency and portability, and to be able to properly buildand synchronize a teams work (also in multi-layered Workspaces), theProject and Makefiles Location name and relative position (below the

4.5.25

4Source Root) must be the same in all Workspaces.In other words, it is best (highly recommended) if the Source Root loca-tion can be used as the single common point of reference from whichboth the location of your sources and all the related SNiFF+ stuff can becalculated.For example, the SNiFF+ Project Creation Wizard always creates, bydefault, the Project and Makefiles Location immediately below theSource Root and gives it the name sniff_data (this name is a Prefer-ences setting). When you create a new Workspace, the same defaultlocation is offered. It is a good idea to follow, and stick to, this pattern.Note that, unless you use ClearCase, the Generated Files Location isnormally the same directory as the Project and Makefiles LOcation.Note also that, if you do not have write permission under the SourceRoot, you may have to point to somewhere else. This will mean thatsome restrictions apply; see below.

3 Exception: Generated Files (and Project and Makefiles) Locations Not Relative It may not always be possible, or even necessary, to create a Generated

Files directory below the Source Root.Assuming you do not have write permission below the Source Root of,for example, a library. But you want to browse this code.When you create the Project, point the Generated Files (as well as theProject and Makefiles Location) to an absolute location anywhere onyour file system where you do have write permission.This will allow you to browse, and even build the library (Build output isredirected to the Generated Files Location).However, you will not be able to version control the files (not an issue ifyou do not have write permissions) or share the Workspace.

If multi-layered Workspaces are and will not be used (for example, underClearCase this is not supported), you can also have the Generated FilesLocation outside the Source Root.However, for normal team development work and version controlling, youhave to make sure that SNiFF+ Project Description Files and Makefilesare properly version controlled. So you can store Project Description andMakefiles in a subdirectory of the Source Root, and other generated filesthat are entirely SNIFF+-maintained elsewhere. This is the recom-


mended procedure for ClearCase users. By keeping the other SNiFF+generated files (e.g. symbol information) outside the Source Root, andhence outside the VOB, performance is naturally better.26

WPorkspace Management Workspace Organization Stand-Alone Workspaces Workspaces and User Autonomy Team Workspaces from Scratch New Team Members (Flat Workspace System) New Team Members (Hierarchical Workspace System) Managing Workspaces

art III

5Workspace Organization

Ov29erview Introduction page 30 Workspace Organizational Systems page 30 Hierarchical vs. Flat Workspace System page 31

Do Not Use Layered Workspaces if... page 31 Disk Space page 32 Performance page 32 Other Issues page 32

Reorganizing Workspaces page 33 The Workspaces Administrator page 33


5.1 IntroductionWe assume that you are familiar with the SNiFF+ concepts, Project andWorkspace. If not, please refer to Projects and Workspaces page 11.

5.230

Workspace Organizational SystemsBy Workspace Organization we mean the way an individual Work-space relates to other Workspaces.In this sense, there are three different organizational systems, all ofwhich can exist in parallel.

No relationship (non-version-controlled)This, the trivial case, is where an individual Workspace has absolutelynothing to do with anythingneither with any other Workspace, nor witha version control Repository. It is completely isolated. Suitable forbrowsing and code comprehension, or for small-scale experimental workthat is not shared or version controlled.Creating this kind of Environment is described under Stand-Alone Work-spaces page 35.

Indirect (flat) relationshipHere, Workspaces are indirectly related in that they share a commonRepository (the place your version control tool stores file-revision infor-mation).This is the simplest, most generic, all-purpose organizational form andcan be recommended in most cases.(See also Hierarchical vs. Flat Workspace System page 31.)

Hierarchical relationshipWorkspaces are directly dependent on other Workspaces. More compli-cated, cannot be used in all cases (e.g. ClearCase, Java code...), doesnot generally make sense on Windows. The main advantage is disk-space savings (only on Unix, where symbolic links are supported).(See also Hierarchical vs. Flat Workspace System page 31.)

Workspace OrganizationHierarchical vs. Flat Workspace System

Figure 5-1 Different Workspace Organizational Systems

5.3

5.3.31

5

Hierarchical vs. Flat Workspace System The flat system can be recommended in most cases. If disk-space is an issue and you are on Unix, the hierarchical system

might be an option.

1 Do Not Use Layered Workspaces if...

Layered Workspaces do not work if You are working on Java Projects on Unix. The Java compiler cannot fol-

low symbolic links. You are using ClearCase.

Stand-alone (no Repository)

Flat (sharing across a Repository)

Hierarchically layered


5.3.2 Disk Space

On Unix, where symbolic links are supported, hierarchically layeredWorkspaces mean disk-space savings.In the lower-level Workspaces, symbolic links to source files, symbol,

5.3.3

5.3.432

cross-reference and dependency information, as well as objects, in thehigher-level Workspace, are created.

On Windows, where symbolic links are not supported, hierarchically lay-ered Workspaces require more disk-space.In the lower-level Workspaces, local copies of source files, symbol,cross-reference and dependency information, as well as objects in thehigher-level Workspace are created. This means one extra unneces-sary (but see also below) set of data per higher-level Environment.

Performance

In hierarchically layered systems (Unix and Windows), performanceimprovements can be expected under the following circumstances (onWindows, however, less so than on Unix because of the copying-timeoverhead):

When Projects are first opened in (newly created) lower-level Work-spaces. This is because the initial parsing of symbol, cross-reference andother information is not necessary.

The first Build in a new, lower-level Workspace will be faster, becauseexisting, up-to-date objects in higher Workspaces can be used (copied onWIndows).

If, for example, a globally included header has been modified, a full re-build is necessary. With layered Workspaces, this need be done onlyonce. In flat Workspace systems, a re-build has to be done for eachWorkspace.

Other Issues

If something goes wrong at a higher level, all lower-level, dependent,Workspaces are adversely affected.

Updates of Workspaces have to be done in two consecutive steps(assuming a two-layer tree), first the higher-level, then the lower level.Again, if something goes wrong in the first step, itll take a while beforeeveryone down below is up-to-date.

Workspace OrganizationReorganizing Workspaces

5.4 Reorganizing WorkspacesAs long as your Workspaces are consistent in terms of internal structure(see Location of Root Directories page 24), you can reorganize themat any time.

5.533

5

That is, you can, for example, start version controlling a non-version-con-trolled Workspace, or move from a hierarchical to flat system, and viceversa.

These, and other administrative issues are described under ManagingWorkspaces page 71.

The Workspaces AdministratorThe responsibility for overall Workspace co-ordination and maintenance(e.g. update cycles) is usually delegated to one member of the team; thisperson is referred to as the Workspace Administrator.

6Stand-Alone Workspaces

Ov35erview Assumptions page 36 What is a Stand-Alone Workspace? page 36 Stand-Alone Workspace Plus Project page 36

Workspace or Repository Selected? page 37 Create Project and Workspace page 37

Stand-Alone Workspace without Project page 38 Workspace or Repository Selected? page 37 Create the Workspace page 38

Special Case: Stand-Alone Analysis Environment page 39


6.1 AssumptionsWe assume that you are familiar with the SNiFF+ concepts, Project andWorkspace. If not, please refer to Projects and Workspaces page 11,or at least make sure you know what is meant by the terms Source Root,

6.2

6.336

Proect and Makefiles Loction, and Generated Files Location (see Termi-nologySource Root, Project and Makefiles Location, Generated FilesLocation, and Repository page 21 for a summary description).

What is a Stand-Alone Workspace?A Stand-Alone Workspace does not access a version control system.

If you do not need to do any serious development work on, for example, athird-party library, and only want to browse and analyze code, this kind ofstand-alone Workspace is perfectly adequate. This applies particularlyalso to read-only code, where version-controlling is not an issue. An inter-esting thing about this kind of Workspace is that it can be simultaneouslyused by multiple users (see Special Case: Stand-Alone Analysis Environ-ment page 39).

Or maybe you want to create a Workspace for code that does not yetexist. For example, an Environment for experimental work that may, ormay not, grow into something bigger. If the experiment does grow intosomething worth version controlling, you can easily change at any time.

Stand-Alone Workspace Plus ProjectThe easiest way to create a stand-alone Workspace is to use the ProjectCreation Wizard to create both a Project and a Workspace.The Wizard is equally suited for use both with existing code, and to cre-ate Environments where no code exists as yet.

Stand-Alone WorkspacesStand-Alone Workspace Plus Project

6.3.1 Workspace or Repository Selected?

Before creating a non-version controlled Workspace, make sure that nei-ther a Repository, nor a Workspace is selected in the Workspace Man-ager.

6.3.37

6

If a Workspace is selected, the Wizard will try to create a Project in thatEnvironment.If a Repository is selected, the Wizard will create a Workspace thataccesses the selected Repository.

To open the Workspace Manager, chooseTools > Workspace Manager

In the Workspace Manager, click into the Workspaces Tree (left pane),and press the key.Nothing should now be selected.

2 Create Project and Workspace Now choose

Project > New > With Wizard...

In the Project Creation Wizard(More extensive notes on using the Wizard are provided in the Begin-ners Guides.)

Specify that you do not want to use a version control tool for the Project. Specify the root directory that holds (or will hold) your sources.

Use the Exclude... button to select which directories to include/excludein/from the Project.Note that deselecting a directory also excludes all subdirectories.Although the subdirectories are still checkmarked, Projects will not becreated for them (a missing link).

The Wizard scans the specified directory tree for known File Types. If you are creating a Workspace/Project for an empty directory, obvi-

ously no File Types will be matched. So, simply click Next. If there are source files below the root directory you specified, accept

or modify the File Types as necessary. Enter the remaining information required by the Wizard.

When the Wizard is finished, the new Project is opened in the ProjectBrowser, and the new Workspace is shown in the Workspace Manager.


6.4 Stand-Alone Workspace without ProjectYou can also create an empty Workspace, and then later create Projectsthat use the Environment.To do so, open the Workspace Manager by choosing

6.4.1

6.4.238

Tools > Workspace Manager

Workspace or Repository Selected?

To create a stand-alone (non-version-controlled) Workspace, first makesure that nothing is selected. If a Repository or Workspace is highlighted,click into the left pane of the Tool and press the key.

Create the Workspace

Choose Workspace > New > Workspace... In the box that appears, enter a name for the Workspace, and the location

of the Source Root directory. SNiFF+ offers a default Project and Make-files Location, and a default Generated Files Location (specified in thePreferences).It is best to accept, and always use, these defaults. If you do not havewrite permission below the Source Root, you can specify locationsoutside the Source Root.

When you click Add, the new Workspace is shown in the WorkspaceManager.

In the Workspace Manager, you can save the new Workspace constella-tion by choosingWorkspace > Save All

Stand-Alone WorkspacesSpecial Case: Stand-Alone Analysis Environment

6.5 Special Case: Stand-Alone Analysis EnvironmentYou may have code that is not subject to modification, but that you wantto browse and analyze, for example, in a re-engineering scenario.In a case like this, you can specify that Projects in a given Workspace39

6

are, by default, opened with read-only access to symbol informationdatabases.This way, any number of users can open the same Projects in the sameWorkspace and have (read) access to all the information in a commondatabase.You can specify this default behavior in the Workspace Properties, Gen-eralAdvanced node.

7Workspaces and User

Ov#Autonomy

erview Workspace Configuration Data page 42 Autonomous Workspace Configuration page 42

Setting the Working Environments Configuration Directory page 43 Site-Level Workspace Configuration page 44

SNiFF+/SNiFF+ PRO 4.0.2Users Guide and Reference

7.1 Workspace Configuration DataWorkspace data are stored in a directory known as the Workspace Con-figuration Directory. The location of this directory is specified in the Pref-erences.

7.242

This can be maintained at site-level, or at user-level.However, because of its restrictiveness, any attempt at site-level mainte-nance will probably, sooner or later, lead to parallelization.

Autonomous Workspace ConfigurationEach team member has his/her own, user-level, Workspace Configura-tion Directory.This allows team members to create, modify, or remove Workspaces intheir own sand-boxes. This reduces administration overhead, and givesdevelopers freedom to move.It also means that team members see only the Workspaces/ Reposito-ries they actually use. Which is all anyone needs or wants to see.The team never-the-less needs to be coordinated. However, coordina-tion in this context means no more than telling team members

where common Repositories are located in flat Workspace systems, the name of a newly created team Project or, in hierarchically layered Workspace systems, the location of the

shared Workspace(s).The only other drawback is that each user has to re-create Repositoryand, if used, shared Workspace nodes (which is why you have to tellthem the things mentioned above). However, this is also a comparativelyminor, one-time task.

Workspaces and User AutonomyAutonomous Workspace Configuration

7.2.1 Setting the Working Environments Configuration Directory

To use your own, user-level Workspace Configuration Directory you haveto set the location in the Preferences.The Preferences can be opened either from the Project Browser, or the#

7

Workspace Manager. In the Project Browser, choose

Tools > Preferences Or, in the Workspace Manager, choose

Working Environment > Preferences

In the Preferences In the Preferences, select the User Level tab.

If this is the only tab you see, this is perfectly normal. It means that youdo not have write permissions to the site-level Preferences file (onlyexperienced administrators should be allowed to write to this file).

In the Workspaces node (under Tools), enter (navigate to) a directorywhere you have write permissions.Notice (Figure 7-1) that the double-head icon next to the WorkspaceConfig Directory field changes to a single-head. This indicates thatyou are no longer using the site-level location, but your own, personaldirectory.

Figure 7-1 Personalizing Workspace Data


7.3 Site-Level Workspace ConfigurationIf you use a common, site-level Workspace Configuration Directory for allteam-members, only one person (the Workspace Administrator) shouldhave write permissions to this directory.42

Giving everyone write permissions to this directory would defeat the pur-pose of centralized administration.This means, however, that team members do not have the freedom tocreate Workspaces for themselves when they need them; they have toask the Administrator to do this for them.A further drawback is that, in the Workspace Manager, everyone alwayssees all Workspaces used by all team members, which is needless clut-ter.

8Team Workspaces from

Ov

Behind the Scenes page 5345

Organization and Coordination page 54 Decision Time page 54Scratch

erview Introduction page 46 PreparationSetting Up Team Projects page 46

ClearCase Preparations page 47 Repository-Based Tools (RCS...) page 47 Write Permission page 48

The First Team Member page 48 Workspace Selected? page 49

The Project Creation Wizard page 49 In the Wizards Opening Page page 49 Where is the Repository? page 50 Select Project Type page 50 Create Project page 51

The Build-Target Setup Wizard page 52 Post-Setup Project Tuning [Optional] page 52 First Check-In page 53


8.1 IntroductionRegardless of how you want to organize your Workspaces (Flat or Hier-archical, see Workspace Organization page 29), there will always be afirst Workspace.

8.246

Once things work for one person, its a small step to let Workspaces takecare of the rest of the team-setup work for you.Theres no need to do everything at once. You can set up a team organi-zation without, for example, initially worrying about any of the more com-plicated build-related stuff. Your in-house Build expert can set up theBuild system at any time (in his/her Workspace), and the benefits canthen be transparently passed on, via Workspace mechanisms, to the restof the team.

PreparationSetting Up Team ProjectsFor team development, you have to use a version control tool.If you do not as yet use a version control tool, RCS is bundled withSNiFF+, so you can always use that.Depending on which tool you use, there are one or two things to makesure of.

Team Workspaces from ScratchPreparationSetting Up Team Projects

8.2.1 ClearCase Preparations

If you use ClearCase: Make sure that all the files for which you want to create the team Project

are under ClearCase control. In other words, the files should already be

8.2.47

8

elements of a VOB. Make sure that you have a ClearCase view that accesses the VOB. When you create a Project/Workspace for use with ClearCase you can

store Project Description FIles and Makefiles under a subdirectory(default name sniff_data).In this case, Project Description Files and Makefiles will still be underClearCase control, but not intermingled with the source code files.To improve performance, use an absolute path that points to a locationoutside the Source Root (and therefore outside ClearCase control) forthe Generated Files directory.

Please refer also to Integrating ClearCase page 269.

2 Repository-Based Tools (RCS...)If you use a Repository-based version control tool (for example RCS), theProject Creation Wizard lets you import code directly from an existingRepository, or you can import the source code from a normal directoryand use a new Repository.


8.2.3 Write Permission

You need write-permission in the Source Root directory so that SNiFF+can store relevant information there.In order to properly share Project and, optionally, Build information, this

8.348

must be stored below the Workspace Source Root. Other (for example,symbol) information can be stored elsewhere; this is however only reallyrelevant for version control tools that, like ClearCase, also control directo-ries.If the Source Root is writable, the Project Creation Wizard suggests asub-directory with the default name sniff_data (this default namecan be set in the Preferences). All necessary information is stored belowsniff_data; your source code remains otherwise untouched.We recommend that you accept the Wizards suggestion; when you cre-ate new Workspaces, the same default will be suggested.

The First Team MemberIf you think of every team as starting off with a first member, then the firststep is clearly to set up a first Workspace.Furthermore, an empty Workspace isnt much use, you will want to cre-ate a Project for the team to work on.The Project Creation Wizard does both these things at once.

The first team member creates the Project that will be used by theentire team.So, to set up the first team members Workspace, complete with Reposi-tory, ready-for-work source code, and Project information, use the ProjectCreation Wizard.

Team Workspaces from ScratchThe Project Creation Wizard

8.3.1 Workspace Selected?

Before using the Wizard, make sure no Workspace is selected in theWorkspace Manager.

If the Workspace Manager is not open, consider this step done.

8.4

8.4.49

8

If the Workspace Manager is open, either close it, or click into the Work-spaces Tree (left pane), and press the key.Nothing should now be selected.

Now choose Project > New > With Wizard...

The Project Creation Wizard In the opening page of the Wizard, make sure you specify that

you want to version control the Project you are about to set up. the correct version control tool is selected.

1 In the Wizards Opening Page

The first question you are asked is:Do you want to use a version control tool for this project?This is exactly what we want to do.

Click: Yes, and make sure the correct version control tool is selected.Here we will use RCS as an example for repository-based systems, andalso point out issues to be aware of if you are using ClearCase.

Click Next.


8.4.2 Where is the Repository?

This page does not appear for all version control tools.The page prompting for a Repository Location only appears for someversion control tools, for example, RCS. The Repository Location can

8.4.350

point to any directory where you have write permission.RCS will, for example, create a directory named RCS under the directoryyou point to, and store all file revisions in this subdirectory.If you are already using a Repository, obviously this is the directory youwill point to. Note that, in this case, you also have the option of checkingout the files directly from the Repository to the Source Root location youspecify on the following Wizard page.

Select Project Type Select the Project type that most closely approximates the software sys-

tem you will be working on. This generally relates to the standard FileTypes that will be recognized by the Project (whether such files alreadyexist or not), as well as, in some cases, to the standard default build-tar-gets that will be created (this applies specifically to VxWorks/TornadoProject types).

Location: This will be the first Workspaces Source Root. Be sure to pointto a root directory that holds (or will hold) all source code somewherebelow it.If unrelated directories exist below this root directory, use the Exclude...button to clear the checkboxes next to these directories. No Projects willbe created for directories that are not checkmarked; nor will Projects becreated for subdirectories of uncheckmarked directories (missing link)!If your source code is still in a Repository (this depends also on theversion control tool used, see Where is the Repository? page 50), theLocation here refers to the target directory where files will be checkedout to during the Project creation process.

A default Name for the Project is taken from the directory name; youmight want to change this.

Team Workspaces from ScratchThe Project Creation Wizard

The Scan for existing files check-box: Selecting the check-box means that SNiFF+ will scan directories and

check for file extensions that do not normally belong to the selectedProject type.

Clearing the checkbox means that SNiFF+ will not scan directories for

8.4.51

8

additional File Types over and above the ones it would normallyexpect to belong to the type of Project you selected above. This cansave time for large directory trees.

4 Create Project The Wizard offers default storage locations for Project and Makefiles as

well as for other Generated Files.Accepting these defaults is generally recommended, especially also toensure consistency in team development situations.Splitting these two types files is relevant mainly for version control toolslike ClearCase (that is, tools that also version control directories). ProjectDescription Files and build-related files are kept within (subdirectories of)version controlled directories (that is, for example, within a ClearCaseview). Symbol tables and databases, on the other hand, need not be ver-sion controlled because they are maintained entirely by SNiFF+. Storingthese generated files outside version controlled directories will thereforeimprove performance on such systems. In this case point the GeneratedFiles location to an absolute location outside the ClearCase view.

Select an appropriate default Platform.For more information about Platforms, please see Platforms page223.

Select an appropriate Build option. Use SNiFF+ Build Support

This option implies that you want to use full SNiFF+ Build Support,that is, the SNiFF+ Makefiles and (or at least) all the files included bythem. Selecting this option will automatically open the Build-TargetSetup Wizard once the Project has been created; this Wizard is dis-cussed in the Beginners Guides.

I want to manage builds myselfThis option implies you have your own, custom Makefiles and Make-support. In this case you can still enter build-target names so thatthese can be built and debugged from the SNiFF+ Build menu.Selecting this option will automatically open the Build-Target SetupWizard once the Project has been created; this Wizard is discussed inthe Beginners Guides.


No Build SupportThis option is for (sub-) Projects that you only want to browse, forexample, third party library code.

After the sources have been parsed and the necessary informationgenerated, the Project is opened in the Project Browser.

8.5

8.652

The Build-Target Setup WizardIf you selected one of the Build options (above), the Build-Target SetupWizard is immediately started. You can use this Wizard to set variousstandard build-targets. (The Wizard is introduced in the BeginnersGuides; please see there for more detailed information.)Basically, the Wizard hides many of the build-settings that you do notnormally need or want to see, making it easy to quickly set standardexecutable or library build-targets. To see and make use of all the moretweakable settings, you would use Project Properties; see SNiFF+ PROBuild/Debug: How To page 137 in this context.

Post-Setup Project Tuning [Optional]Because not everything can, or often even should, be generically set bythe Wizard(s), you may want/have to fine-tune your Projects once theyhave been created.For example, as mentioned above, you can only set standard targets inthe course of Project creation. More complicated build-related, Project-specific settings can be done later. Or, you may want to reorganizeProject structure and/or content. Remember, once the Project exists youare no longer tied to file-system constraints. Furthermore, you may atany time want to add or remove files or Subprojects. For informationabout this and other day-to-day maintenance tasks, please refer to Work-ing with Projects page 91.However, as mentioned earlier, you can do the Build setup and other tun-ing at any time, and then share modifications.

Team Workspaces from ScratchFirst Check-In

8.7 First Check-InThe next step is to check all files in to the Repository (or for ClearCaseusers, add them to ClearCase Source Control).To check files in, you use the Project Browsers File List.

8.853

8

To display the File List, click the Files tab at the bottom-left of the ProjectBrowser (the main MDI window).

In the File List Make sure that all Projects in the File Lists Project Tree are check-

marked. Click into the File List and choose Edit > Select All,

then Right-click > Check In.(ClearCase users choose File > Add to Source Control.)

In the box that appears, enter a Change-set name.Its a good habit to get into right from the start.Change-set labels are useful for recognizing and grouping files modifiedfor a particular purpose. (Even individual files should be checked in witha Change-set label, that says who did what and why.)Once the check-in process is complete, you will notice that the files in theFile List are no longer shown in bold typeface; this indicates that they areno longer writable in the current Workspace.

Behind the ScenesWhen you create a Project, the Wizard automatically creates a firstWorkspace and a Repository behind the scenes.To see this, open the Workspace Manager, by choosingTools > Workspace Manager

In the Workspace ManagerAt the left of the Workspace Manager, you see all existing Workspaces.Workspaces are represented by icons that look like desks.At least one of these desks (the one that you have just created with theWizard) should be attached to a Repository node.


Depending on the version control system you use, the Workspaces maybe attached to the Repository node indirectly. That is, they are attachedto a Configuration node, which is in turn attached to the Repository (formore information, please see Workspaces, Configurations, and Branches page 263).

8.9

8.9.154

Organization and CoordinationYou have now done everything that is needed for the first user, or, if youwant to use a Hierarchical Workspace system, for the top-level, sharedWorkspace.Each team member who is to work on the Project you have just created,needs to have their own Workspace to work in.If a site-level Workspace Configuration Directory is to be used by every-one (see Site-Level Workspace Configuration page 44), you, theWorkspace Administrator, will have to create their Workspaces for them(and then make sure they have write permission).However, if each team member has their own, user-level WorkspaceConfiguration Directory (as is recommended, see Autonomous Work-space Configuration page 42), they will not be able to see the Reposi-tory and the Workspace the Wizard created.In this case, your next step is to tell the team members one or two things,so that they can go ahead and create their Workspace(s). What theyneed to know depends on how Workspaces are to be organized.

Decision Time

Do you want to work in a Flat Workspace system, or in a Hierarchicalone?You can either simply follow our recommendation and use the Flatsystem, or, for more information, see Hierarchical vs. Flat WorkspaceSystem page 31.

Note to ClearCase Users

If you are using ClearCase, the Repository node has no Clear-Case-specific functionality. However, you (and SNiFF+) use thisnode as a point of reference for adding new Workspaces.

Team Workspaces from ScratchOrganization and Coordination

Whichever system (Flat or Hierarchical) you use, you will have to tell allteam members where on the file system the Repository (or the Clear-Case VOB) is located.Note that you will only have to tell people this (and the other thingsmentioned below) if they each use their own, user-level Workspace55

8

Configuration Directory.If a common, site-level location is used, you neednt tell them anything,you will have to do everything for them.

If you want to use the standard, Flat Workspace system Tell team members the name of the Project the Wizard has just cre-

ated for you. Continue with the chapter New Team Members (Flat Workspace Sys-

tem) page 57. If you want to use a hierarchically layered Workspace system:

Tell team members the file-system location of the root directory hold-ing your source code (the one you entered in the Wizard). This isknown as the Workspace Source Root, and will also be accessed byall other Workspace.

Continue as described under New Team Members (HierarchicalWorkspace System) page 65.

9New Team Members (Flat

Ov#Workspace System)

erview Introduction page 58 What Do You See? page 58 Create a Repository Node? page 59 Create a New Workspace page 60 First Check-Out page 61 Open the Project page 62 More Workspaces for Yourself page 63 More Team Members page 63


9.1 IntroductionIf you want to set up a Hierarchical Workspace system, youre in thewrong chapter; go to New Team Members (Hierarchical Workspace Sys-tem) page 65.

9.256

One person (The First Team Member page 48) imports code intoSNiFF+ by creating a Project, a Workspace, and a Repository. (Weassume that this has been done. If not, youre also in the wrong chapter;go to Team Workspaces from Scratch page 45.)In a Flat Workspace system, each related Workspace must access thesame Repository. (Related here means the Workspaces used by devel-opers working on the same software system.)

What Do You See?Open the Workspace Manager by choosingTools > Workspace ManagerWhat do you see?

If you are not The First Team Member page 48, and if you use yourown, user-level Workspace Configuration Directory (see AutonomousWorkspace Configuration page 42), you will not see the Repository orthe Workspace that has already been created.In this case, continue with Create a Repository Node? page 59.

If you are The First Team Memb

users guide vxworks

Documents

wind river url

wind river wayalameda

wind foundation classes

reorganizing workspaces

layering workspaces

sniff pro users

team projects

n d r e f e r e n c