Using the Software Release Structure

This section will describe the overall procedures needed to develop in an SRT environment. In short, a user wants to develop a certain package. He needs to define a context, or base release, in which this package will be compiled and linked. He must then define a "test" release in some working area, then copy the package to be modified into this working area, and finally set symbolic links for header files and libraries to the other packages in the base release - see Figure  4.

The user is afforded many options to globally describe his development environment. One of which is a super test release. Look at Figure  4. The default SRT behavior is to define the path for header files to include both directories in the test release as well as the base release. If a user deleted a header file from package B in the test release, the make files would still find it in the base release. This can lead to some confusion. SRT supports the concept of a super test release which will only look for include files in the test release. It does this by creating a directory called "super" in the test release and putting links to each pacagke's header files therein.

The SoftRelTools commands themselves are defined in more detail in Section  4. Once again, you should refer to your code librarian's instructions for the naming conventions and practices unique to your specific configuration.

Basically the steps are:

• select a base release with the srt_setup command, necessary before any SRT commands can be executed. Section 3.1

• construct a test release using newrel for development. Section 3.2

• populate a test release using addpkg. and lnkpkg. Section 3.3

• compile and test packages. Section 3.4

• make the new package version official using newver. Section 3.5 Section 3.7 describes making a new production release, including the new package version, using newrel.