PowerAda Setting Up PowerAda Baselines and Working Projects in ClearCase

Chapter 5

• Notice
• Chapter 1. Overview
• Chapter 2. Getting Started
• Chapter 3. Basic PowerAda Concepts
• Chapter 4. The PowerAda Development Environment
• Chapter 5. Project Management with PowerAda
• Chapter 6. The PowerAda Debugger: adbg
• Chapter 7. Interface to Other Languages
• Chapter 8. Implementation Details
• Chapter 9. Optimization
• APPENDIX A - Glossary
• APPENDIX B - Support Packages
• APPENDIX C - Implementation Characteristics
• APPENDIX D - Demos and Tutorials
• APPENDIX E - Tools Reference
• APPENDIX F - Debugger Command Reference
• Index

Contents |  Installation Guide | Release Notes

First | Prev | Next | Last

We will illustrate with an example the preferred method of setting up a PowerAda development environment in ClearCase.

Three ClearCase views will be created with the following view tags: baseline_view, delta_view and working_view. These views will correspond to a Full Baseline, a Delta Baseline, and a developer's working project.

The Full Baseline

The build team will define a view for the full baseline (baseline_view) which consists of some consistent view of the source. A build script will then be executed within this view to compile the code and bind executables. The working directory for this build will be within a view-relative path, for this example: /view/baseline_view/vobs/ada_test. The build process will result in sublibraries, object files and executables being created under this directory, exactly as if it had been extracted from repository-based CM system. The project will then be baselined as usual with the aprojbaseline command.

Note that object files, sublibraries and executables in the project will not be version-controlled. They will exist as ordinary files within the VOB.

The Delta Baseline

Next, a delta view will be defined, for example with a code cutoff date one day later than for the full baseline described above. Again, we work within the view-relative pathname to access this delta baseline directory tree: /view/delta_view/vobs/ada_test. Although this is a delta baseline in the sense that it differs incrementally from the full baseline, it will contain a full set of files. In fact, the files in this delta baseline which do not differ from the full baseline will be the same files as in the full baseline: not only their contents will be identical, but their inode numbers and modification times as well.

The delta baseline is created by running aprojinit, and indicating the full baseline as parent by supplying its view-relative pathname as parameter to the -B option:

aprojinit -k -B /view/baseline_view/vobs/ada_test/adaproj adaproj

At this point, the delta view contains only files under version control and the .adaproj signature file created by the aprojinit command. The sublibraries, object files and executables created when the full baseline was compiled appear only within the full baseline view. The project under '/view/delta_view/vobs/ada_test' looks much like a directory tree into which a full extract was performed at a later date than the full baseline.

Since the build process will use the aprojbuild command to perform a minimal recompilation (taking changes between the delta and full views into account) only changed files will be recompiled. Once again, the delta view is baselined as usual.

The Working Project

The above two views and projects were intended to become baselines. We now want to create a view appropriate to a developer's environment. Recall that the views which were to support baselines were intended to be 'static', and need only be self-consistent (in the sense that the Ada source code they contained should all compile). The config spec for the developer's view is more tightly constrained. The requirements are:

1. When initially created, the view of source code should be identical to that of the baseline the developer will be indicating as his working project's parent. (This suggests that some tool might be useful to help enforce this requirement; no such tool currently exists.) If this is not the case, then PowerAda will attempt to recompile any files in the working project which differ from the baseline, which is probably not desirable.
2. Files the user has checked out should be visible locally.

Once so defined, the working project is initialized with the aprojinit command, specifying the parent baseline as above. For example, to designate the delta baseline as parent, we would use:

aprojinit -k -B /view/baseline/delta_view/vobs/ada_test/adaproj adaproj

It is worth reiterating here that the config spec used to define the working project view should be the same as that used to define the baseline which the user has specified as his project's parent, except for files the user has checked out. If this is not the case, any files in the initial working project view which differ from those in the parent baseline will be treated as new by Powerada and will be recompiled. This will probably not produce desirable results.

Having said this, we note that there may be times when it will be useful to define a working project view that differs from the one described above. A user may wish to include in his view files checked out by another developer who is working on the same task. He might want to include files which have been checked into ClearCase since the creation of his parent baseline in order to get early access to some bug fix. It is left to the developer and the CM administrator to decide whether such configurations are advisable.