[Top] [Prev] [Next] [Bottom]
A creation of a product release includes several steps:
This chapter describes the support that SDE provides for these steps.
A product release is a subset of one or several system configurations. Not all files from the system configurations belong to a product. For this reason it is necessary to describe which files belong to a product, or more precisely to a product release.
Files that belong to a product release should be described in Product Definition Files (PD files).
A PD file contains the following information:
The format of the PD file is as follows:
/* comment */
PD files are processed by the cpp preprocessor which means that it is possible to use statements like
#define name definition
or conditional statements.
The item src denotes a file specification of the component(s) to be copied. Any legal filename specification can be used (including the characters *,%,). It is also possible to define several files. Normally, only a filename should be specified, which denotes that the file(s) should be placed in the current directory or in the belonging RCS library. If the file is not placed in the current directory, then a complete path may be specified. Normally, a path relative to the current directory should be specified.
The item dest denotes the directory where the files should be copied to. The first part of the directory (root) should be specified by the environment variable PRODUCT_ROOT. This variable denotes the root of a product version.
Both src and dest items may include environment variables for a dynamic definition of items. For example, the environment variable PLATFORM decides which variant of the file will be copied to the corresponding destination directory:
$PLATFORM/file $PRODUCT_ROOT/$PLATFORM/bin; chmod 755 $FILE
After the first semicolon, commands that are applied on each component after its copying, may be specified. In these commands, the environment variable FILE denotes the component that has been copied.
The last part of the line begins with the "!" character which is followed by a file description.
A PD file may be created by any editor.
PD files should be stored in systems in the same way as other files. Particular versions of PD files describe the particular product releases.
One of the features of the PD file is the include statement, which makes it possible to have several PD files describing the components of a product release. For an easy maintenance, it is recommended that every subsystem containing files to be copied to a product, includes a PD file describing the files from the subsystem. The top level PD file (configuration level) should refer to PD files from the subsystem by using the include statement.
The name of a PD file should correspond to the product name, and the default file type is .pd. For example, PD files for SDE product are called sde.pd.
If several products are produced from a system, then several sets of PD files may be used. For different variants of a product release, conditional statements may be used.
If several systems make a product, then one system (called the product system) contains the main PD file.
The following examples show two PD files - one on the top level, and one on a subsystem.
#include "Navigator/sde.pd" ! VerWork command
crdef $PRODUCT_ROOT/lib ; chmod 755 $FILE ! CR dir definition file
The files are copied from a system (or from several systems) to a product release by the command
In general the pcopy program copies files from one directory structure to another directory structure. The command can also be used for creation of a temporary product structure, i.e. files from a project's directory structure can be copied to a test directory structure.
When creating a new product release, then the files from a system configuration will be copied to a product release structure.
The program pcopy goes trough the PD file(s) and reads which components should be copied. By default all the components are taken. Using the option -g or -m it is possible to select which files will be copied. A specific file or directory (subsystem) or a specific file suffix may be specified.
If the same components already exist in the destination directory, then only the components that are newer than those in the destination directory are taken. Optionally, no date is tested.
The environment variable SDE_PD defines the PD file name.
PD files define the root destination directory by the environment variable PRODUCT_ROOT. When pcopy is executed this variable must be defined.
Optionally the pcopy command creates the destination directories.
The command pcopy may be invoked as a line command, or from the application
SDE-System Manager, the function
Copy to product.
It may happen that a programmer or system manager copies a file directly to a product release, and forgets to specify it in a PD file. To check if there are some files present in a product release, but not found in PD files, the command
may be used. This command also checks that there are not several definitions of the same files in the PD files.
compares the files in two directory trees and this command can be used for getting information about the differences between two product releases.
Both commands are integrated in the SDE System Manager.
SDE does not support directly the product delivery, but only the local installation. The standard HP-UX support can be used.
Figure 8-1 shows the process of integration and distribution of a product release.
Fig 8.1 Processing a product release
A local product structure is created by using pcopy command.
When a product version is created it is important that the whole product is built in a consistent way. All external and internal components used for the building must be of the same version. If some parts of a product are built using one version of an external product, and other parts using another version, there is a risk that two parts come into conflict. For this reason it is important to do the following:
These two steps are supported by SDE in the following way:
When building a system, some definition files are used by Makefiles. One of them is a file called imports.mkf. It contains definitions of SDE product versions, external products and other software components which are used for the build procedure.
To check that the components referred to from the imports.mkf file have used the same version of the common products, the command imports must be run, or invoked from the SDE System Manager.
To include information in the generated product, about the used external components, the same file should be taken as a part of the released product version. By convenience, the file is saved as product_root/info/imports.mkf file. Having this definition file in all the product components, the command imports may be used for the products in the same way as for the systems. This command may be invoked from SDE Product Manager.