The information contained in this document is subject to change without
notice.
Hewlett-Packard makes no warranty of any kind with regard to this
manual, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. Hewlett-Packard
shall not be liable for errors contained herein or direct, indirect, special,
incidental or consequential damages in connection with the furnishing,
performance, or use of this material.
rights are reserved. Reproduction, adaptation, or translation without
prior written permission is prohibited, except as allowed under the
copyright laws.
Corporate Offices:
Hewlett-Packard Co.
3000 Hanover St.
Palo Alto, CA 94304
Use, duplication or disclosure by the U.S. Government Department of
Defense is subject to restrictions as set forth in paragraph (b)(3)(ii) of the
Rights in Technical Data and Software clause in FAR 52.227-7013.
Rights for non-DOD U.S. Government Departments and Agencies are as
set forth in FAR 52.227-19(c)(1,2).
Use of this manual and flexible disc(s), compact disc(s), or tape
cartridge(s) supplied for this pack is restricted to this product only.
Additional copies of the programs may be made for security and back-up
purposes only. Resale of the programs in their present form or with
alterations, is expressly prohibited.
A copy of the specific warranty terms applicable to your Hewlett-Packard
product and replacement parts can be obtained from your local Sales and
Service Office.
California. This software is based in part on the Fourth Berkeley
Software Distribution under license from the Regents of the University
of California.
New editions of this manual incorporate all material updated since the
previous edition.
The manual printing date and part number indicate its current edition.
The printing date changes when a new edition is printed. Minor
corrections and updates incorporated at reprint do not cause this date to
change. The manual part number changes when extensive technical
changes are incorporated.
August 1992Edition 1 (B2600-90010)
August 1994Edition 1 (B2600-90031)
January 1996Edition 1 (B5072-90002)
August 1996Edition 1 (B5072-90017)
February 1998Edition 1 (B6454-90002)
September 1999 Edition 1 (B6454-93003)
4
Table 1
Typeface Conventions
ConventionDescription
italic font
typewriter fontComputer commands or other information that
boldface fontA term that may need further clarification or
[…]Optional parameters in syntax examples are
KeyCapRepresents a key on your keyboard that you
Information you supply, either in syntax
examples or in text descriptions. Forexample,if
told to type:
name like sample. Italics are also used for
emphasis, and for Titles of Books.
must be typed exactly as shown. For example, if
told to type: sample, you type exactly the word
in typewriter font, sample. Menu selections are
in typewriter font separated by colons. See
"Menu Conventions" in this chapter.
definition, especially a familiar word (such as
menu) used with a computer-specific meaning.
These terms are clarified in the glossary.
enclosed in brackets.
must press, or an on-screen button that you
must select, as part of the operation. For
example, Return is the "Carriage Return" key,
which completes a command input. This key
may be labelled "RETURN", "Return", or "Enter".
filename
, you supply an actual file
Key1-Key2A hyphen between keys indicates that two or
more keys must be pressed at the same time.
For example, "Control-C" means to press and
hold the Control key while pressing and
releasing the C key. The Control key may be
labelled "CTRL", "Ctrl", or "Control".
SoftBench facilitates the development of reliable software, an especially
difficult and time-consuming process when you work on large and
complicated projects. SoftBench provides an integrated, consistent
windowed interface to the tools you need the most.
Chapter 119
Maximizing Your Results with SoftBench
SoftBench Task Flow
SoftBench Task Flow
The tools pass information and control from one tool to the next, helping
you move smoothly through the software development and maintenance
tasks shown in Figure 1-1.
Figure 1-1Major Software Development Tasks Supported by SoftBench
SoftBench tools and the data on which they operate can be distributed
across a network and accessed transparently by individuals or teams.
SoftBench provides an open, customizable environment, allowing users
to add their own tools or purchase products integrated by third party
software vendors. Additionally, SoftBench provides online help and an
online tutorial to simplify learning.
SoftBench provides a dynamic build environment. As you develop your
project, SoftBench learns about your source files and how to transform
them into your build targets. Based on build information contained in
build configurations, SoftBench can maintain the Makefile
instructions for you. SoftBench automatically shares this knowledge
about files and targets in your project with other SoftBench tools.
SoftBench project management allows you:
• ease of navigation through project code and files that may be spread
across file system directories
• automatic maintenance of simple to complex target dependencies
• definition of the project once, so that all tools benefit from the
knowledge rather than maintaining multiple lists of files throughout
your toolset
Chapter 120
Maximizing Your Results with SoftBench
Understanding Projects
Understanding Projects
Projects are the fundamental work unit in SoftBench. Projects consist
of a named set of files that produce a set of related targets using one or
more sets of build instructions and dependencies.
Figure 1-2SoftBench Tools Interacting with Project and Files
The critical parts of a project definition are:
Project NameThe logical name for the project.
Local Workspace Root The root directory of the file system hierarchy
under which all your source files are found, and where
editing and building take place. The project does not
have to include all the files under the hierarchy, and
files in the hierarchy can be used in different projects if
desired.
Chapter 121
Maximizing Your Results with SoftBench
Understanding Projects
Project file setThe source, documentation and test files you wish to
associate with the project.
Project targetsThe executables, libraries, message catalogs, and other
files that are the product of one or more builds.
Build Configurations Instructions for how to transform your source files
into your target files.
Project names contain regular characters. Control characters, spaces,
and punctuation characters special to the shell are not allowed in project
names.Thefiles and targets that comprise your project are located under
your local workspace root. SoftBench's project description data contains
lists of these files and their relationships.
When you change file and target information in SoftBench, you change
only SoftBench internal descriptions of their relationships. For example,
deleting a file from a project only changes your project description data.
It has no impact on your files in the file system.
Subprojects are projects with a defined dependent relationship to a
parent project. A subproject relationship implies a build order
dependency. A project is always an entity to itself; that is, it does not
dynamically inherit options or build information from any other project.
Examples of subprojects include:
• a project to build a library that is linked into a parent project target
• a project to build an executable that is used to generate files or
targets in the parent project
Building Targets
Source files are files you create and edit directly. A target is a project file
that is the end product of a build. Examples of targets include linked
executables, shared libraries, archive libraries, and message catalogs.
Chapter 122
Maximizing Your Results with SoftBench
Understanding Projects
Figure 1-3Building Sources into Targets Using Project's Build Instructions
Targets that SoftBench builds:
• are project-specific. They are not shared between projects, though
projects may have targets of the same name
• are user defined
• are created from a build within a project
• are built in no specified order unless a specific dependency has been
created between them
• each have a physical file system location specified when you define
the target
• are distinguished from intermediate files (.o's or .C's built from lex or
SQL files)
Not every target is an executable file and not every executable file in a
project is a target. Targets are created from a build within the project
and are only those things a user has defined as such.
Understanding Build Configurations and Packages
A build configuration provides the complete set of build instructions to
produce a target of a particular type, such as a C++ executable, a C
shared library, or an Oracle C executable. Build configurations specify
libraries, include directories, compiler options, defines, and other
information required to transform source files into a target. When you
use project build, you can use one of the many default build
Chapter 123
Maximizing Your Results with SoftBench
Understanding Projects
configurations provided by SoftBench.
Build configurations are independent of projects and targets. SoftBench
ships with a basic set of build configurations. You can create new user
build configurations based on the shipped build configurations, adding
build instructions that are unique to your environment. To have your
administrator save these as shared customizations available to other
users, see "Sharing Build Configurations with Your Team" in SoftBench
Online Help.
Once you decide on build configurations (system or customized) that
work for your environment, you can use the same build configuration for
many targets, and you can further customize a build configuration for a
specific target.
A build package is a collection of build instructions that makes it easy
to use third-party libraries, utilities, or compiler directives in many build
configurations. Packages also make it easy to specify the compiler to use
for the target. Packages are similar to build configurations because they
include library and include directories, compiler options, defines, and
other information needed for using the library or utility. First, choose a
system or customized package; then include the package in all
appropriate build configurations. If the package's build instructions need
to change, you modify the package, and all build configurations which
use the package update automatically.
For example, SoftBench provides packages for Motif, X11R6, SoftBench
Encapsulator, RogueWave, and Oracle. If the requirements for building
the library change, you can modify customized packages. All build
configurations that include the package automatically update to use the
modified package.
A transform is a set of operations that run a program or shell utility
that converts a file from one form to another. Forexample, the C compiler
transforms a source file into an object file. SQL preprocessors transform
a source file with embedded SQL into a generated source file with all the
SQL statements expanded. The gencat utility transforms a file of
message strings into a message catalog. For more information about
these concepts, refer to the "SoftBench Key Concepts" topics on "Build
Configurations", "Build Packages", and "Transforms" available through
"Help: Overview".
Transforms are the building blocks of build packages and build
configurations. A build package contains zero or more transforms plus
modifiers that influence how transforms operate. An example of a
Chapter 124
Maximizing Your Results with SoftBench
Understanding Projects
package with no transform, just modifiers, would be the X11 library to be
linked into an executable. A build configuration contains one or more
transforms and zero or more packages (which may include transforms
and/or other packages). A very simplified version of the actual build
configuration to create an executable target from C source containing
embedded SQL is shown in Figure 1-4.
Figure 1-4Simplified Build Configuration, Package, and Transform Series
Choosing Between Project Build and External Build
Models
SoftBench supports two build models, allowing you two ways to specify
your build instructions:
• With project build, you supply the necessary information to
SoftBench, and SoftBench converts the build configuration and
dependency information into build commands.
Chapter 125
Maximizing Your Results with SoftBench
Understanding Projects
Project build lets SoftBench manage your build instructions. You can
specify source-to-target dependencies and build order dependencies,
choose convenient system or customized build configurations and
build packages, and automatically generate Makefiles or do without
Makefiles altogether if you prefer.
• SoftBench provides an external build model as an alternative to
project build for people who already have a highly-tuned build
environment. With external build, you edit and maintain the
Makefile or build script. SoftBench provides an "External BuildCommand" dialog box for you to initiate your builds.
External build lets you use your own make utilities, such as imake,
make,ornmake files or scripts. External build is the opposite of project
build, where SoftBench handles building without the need for a
Makefile. SoftBench does not read or parse your Makefile. By using
external build you lose some of the conveniences that project build
provides, such as access to the target graph and automatic generation
of a Makefile. You can also add secondary source locations to
SoftBench's search lists through alternate source roots.
The "External Build Command" dialog box can be utilized during
project build to build software which is not in a project, or to execute a
shell command and view the output in the output browser.
Recommendation: Use project build for your projects whenever
possible. You may choose to use external build and maintain the make
process yourself when:
• You have one source that becomes many types of objects.
• Your process cannot use file suffixes to tell what file types are in use.
• Your build process uses the VPATH environment variable for make(1).
• You have a working build process and are perfectly happy with it.
Chapter 126
Maximizing Your Results with SoftBench
Sharing Projects with a Team
Sharing Projects with a Team
SoftBench projects provide the flexibility to have your development
environment reflect your team interactions.
Sharing a project description has all the benefits and difficulties
associated with sharing any source file. A centralized project description
means that everyone is working from the same project files, but there
can be collisions when more than one person wants to make changes. You
may "break up" your file into several subprojects so that people can
work independently and let SoftBench handle the complexities and
relationships of the build.
There are several scenarios for partitioning a project:
• One Project, One Author
• One Project, Many Authors
• One Project with Subprojects, Many Authors
One Project, One Author
When your project has only one author, you may want to set up a single
project definition.
Alternatively, you can choose to use subprojects to organize your work
hierarchically, if that is more convenient. For example, if the subproject
is a library, you can modify the build configuration of targets in the
parent project to use the library. If you work on both the library and its
parent project, using the subproject relationship provides the flexibility
to either build the subproject or use it in its current state. If you never
want to build the subproject alone, setting up the subproject relationship
may not be the best way to structure the project. You can just leave all
your targets in one project and use build-order dependencies.
One Project, Many Authors
As your project grows past what one author can accomplish, you face the
issues of sharing the work across the team.
The preferred way to work at this level is to designate one person as the
owner of the project definition file and have the rest of the team clone
Chapter 127
Maximizing Your Results with SoftBench
Sharing Projects with a Team
from that definition for their local working copies. Anyone who discovers
the need for a change in the project definition communicates that to the
owner, who makes the update, and then all of the team members re-clone
their project definitions.
Figure 1-5Team Members Cloning the Project Definition
The least usable method is to share the project definition files. Choose
"Options: Set Default Project Root…" to specify the location of the
shared project definition. Sharing a project definition has several
limitations, primarily that only one person can open the project at a
time.
Chapter 128
Maximizing Your Results with SoftBench
Sharing Projects with a Team
Figure 1-6Team Members Sharing the Project Definition
One Project with Subprojects, Many Authors
Finally, your team can choose to divide up the project along the same
lines as they divide up the work, especially if the project is large enough
that multiple teams are cooperating on a single system release.
Figure 1-7Team Members Using Subprojects
Each person's module of work may be designated as a subproject of the
team's project. Team members then open the parent project for short
periods of time, as necessary, but work primarily in the subprojects.Each
team member's project is a subproject of the larger project, then the
whole team's project is actually a subproject of the overall system
delivery. Using SoftBench to manage this level of hierarchical complexity
saves tremendous time and confusion when system builds are needed.
Chapter 129
Maximizing Your Results with SoftBench
Sharing Projects with a Team
Chapter 130
Loading...
+ 375 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.