Package dependencies are a convenient way to provide a way for the end user to check his/her deployment without having to deal with extensive system tests and/or obscure runtime errors. However encoding these depedencies requires some forethought. To aid with this GPT comes with a set of typed dependencies. These dependency types make it easier for developers to define package relationships. The dependencies are detailed as part of the source code of the package. GPT automatically translates these dependencies and transfers them to the resulting binary packages. The types are as follows
Table 10.2. Source Dependency Types
| Dependency Type | XML Element or Attribute | Description |
|---|---|---|
| Compile | compile | This is when the package requires a header, precompile definitions or other compilation information from another package. |
| Library Link | lib_link | This is when a package contains a library that has libraries from another package that it depends on. Only direct dependencies are needed since GPT builds the entire dependency tree when doing its check. |
| Program Link | pgm_link | This is when a package contains a program that links with libraries from another package. Only direct dependencies are needed since GPT builds the entire dependency tree when doing its check. |
| Runtime | data_runtime, doc_runtime, pgm_runtime, or lib_runtime | Package needs something from another package in order to work in a runtime environment. The dependency needs to be expressed as a binary to binary package dependency. Can be anything from an executable to a hyperlinked document. Library dependencies should not be included here since they are already handled by dependency types mentioned above. |
| Setup | Source_Setup_Dependency | This is when a package needs configuration files or scripts from another package. This dependency is used to seperate applications from configuration data so that these don't have to be re-configured every time the application packages are upgraded. |
GPT manages these dependencies by setting up various deployment environments such as Build and Runtime to determine which dependencies should be checked. The following sections provide more detail into these environments and the dependencies they honor.
A typical GPT dependency has three common components. Setup and Runtime dependencies have two additional components. The components are as follows:
This component dictates to GPT what deployment environment is valid for the dependency and also determines some rules when the dependency is converted from source to binary.
This is the name of the dependent package. It is used by all of the dependency types except setup.
This expresses the version compatiblity requirements of the dependent package. This is used by all of the dependency types.
This allows the dependency to be more specific about a dependent package by specifying the package type. This component is only used by runtime and setup dependencies. The other dependency types have standard package types that are automatically encoded by GPT.
This is an alternative name used by setup dependencies.
The build dependencies are in affect when packages are being used to compile and link other software. This situation does not only occur during package building. Many packages are software development kits that allow end users to build software using packages. In this situation build dependencies are also applicable.
The compile dependency and the two linking dependencies make up the build dependency set. These dependencies are checked when building the package using gpt-build. They are also also transferred to the binary packages packages that are create from this package. The transfer is described by the following tables. This table shows how the dependency types are converted. This table shows what package types the binary dependencies are pointing and transferred to. Regeneration dependencies currently do not show up in any binary packages.
Table 10.3. Build Dependency Types
| Source Build Dependency Type | Resulting Binary Dependency Type | |
|---|---|---|
| With Dynamic Linking | With Static Linking | |
| compile | Compile | Compile |
| lib_link | Runtime_Link and Build_Link | Regeneration and Build_Link |
| pgm_link | Runtime_Link and Build_Link | Regeneration and Build_Link |
Table 10.4. Binary Dependency Types and Their Package Types
| Binary Dependency Type | Binary Package Type That Gets The Dependency | Binary Package Type Which The Dependency Points To | ||
|---|---|---|---|---|
| With Dynamic Linking | With Static Linking | With Dynamic Linking | With Static Linking | |
| Compile | dev | dev | dev | dev |
| Build_Link | dev | dev | dev | dev |
| Runtime_Link for Libraries | rtl | NONE | rtl | NONE |
| Runtime_Link for Programs | pgm | NONE | rtl | NONE |
Runtime dependencies are also expressed as source dependencies but in reality the dependencies are relationships between specific binary packages. For this reason the dependency has two pkgtype components as well as the package name and version requirements. The first package type specification is embedded in the dependency type. This package type indicates which to binary package the dependency is transfered to. The second package type further specifies the dependent package.
Setup dependencies are used to to relate software packages to their dependent setup packages. This is a one-to-many relationship in that GPT allows for the possiblity to have multiple setup packages fulfill the same setup dependency. A setup dependency use the Setup_Name and Setup_Version to identify the dependent package rather than Package_Name and Version. Different setup packages (each with a different Package_Name and Version) can have the same Setup_Name and Version
Here are some examples that show how GPT dependencies are implemented
Table 10.5. Dependency Examples
| Dependency Description | Dependency Components | XML Expression |
|---|---|---|
| Package FOO uses headers from package FEE version 3 |
|
<Source_Dependencies Type="compile" >
<Dependency Name="FEE" >
<Version >
<Simple_Version Major="3" />
</Version>
</Dependency>
</Source_Dependencies>
|
| A library in package FOO depends on symbols from a library in package FEE version 3 |
|
<Source_Dependencies Type="lib_link" >
<Dependency Name="FEE" >
<Version >
<Simple_Version Major="3" />
</Version>
</Dependency>
</Source_Dependencies>
|
| Library in package FOO executes scripts from package FEE version 3 |
|
<Source_Dependencies Type="lib_runtime" >
<Dependency Name="FEE" Package="pgm">
<Version >
<Simple_Version Major="3" />
</Version>
</Dependency>
</Source_Dependencies>
|
| Documents in package FOO hyperlink to documents in package FEE version 3 |
|
<Source_Dependencies Type="doc_runtime" >
<Dependency Name="FEE" Package="doc">
<Version >
<Simple_Version Major="3" />
</Version>
</Dependency>
</Source_Dependencies>
|
| Programs in package FOO read configuration files created by setup package with a setup name and version FOO_Setup version 3 |
|
<Source_Setup_Dependency PkgType="pgm">
<Setup_Dependency Name="FOO_Setup">
<Version>
<Simple_Version Major="3"/>
</Version>
</Setup_Dependency>
</Source_Setup_Dependency>
|