PowerAda Overview

From OC Systems Wiki!
Jump to: navigation, search

PowerAda works on a Project, which is a directory tree containing Ada source code (and possibly other files). The source code is assumed to be divided into directories. (It is permissible to have all the source in one directory, but this is not practical for any reasonable size project.) All the source code in a given directory is associated with an Ada sublibrary in the same directory. (A sublibrary is a subdirectory PowerAda uses to manage the compilation environment; in simple terms, it is where the object code output from compilations is stored.) In practise, it is not strictly necessary to organize the project in this way, but we recommend following this structure as it is the simplest to deal with.

The directory at the root of the project tree (called "adaproj" by default) contains "metadata" files that PowerAda uses to store information about the Project.

All configuration management (CM) toolsets also allow files to be organized into a directory tree. PowerAda assumes that the tree structure of files in CM corresponds exactly to the tree structure within the project. This has obvious advantages; for example, one might extract recently changed files from CM into the project directory (typically possible with a single command or simple shell script) and direct PowerAda to perform a minimal recompilation of the changed files and their dependents. In addition, when a CM command is to be issued under the control of PowerAda, the pathname of the file in CM can be trivially derived from its location in the project.

ClearCase is no different than other 'repository-based' CM toolsets in this regard. The Ada source code should be imported into ClearCase in a directory structure which reflects its logical organization, which will be adopted by PowerAda. Assume that the project is beginning with a collection of source code inherited from another organization.

Once the inherited code is imported into ClearCase, it will be accessible through a view. To begin with, someone will need to compile the code to provide a 'baseline' for other developers to compile against. This builder will compile the Ada source code into a project within a public view. Only the source code will be 'versioned objects' within the ClearCase Multi-Version FileSystem (MVFS). The sublibraries created by the compilation will not be under version control, neither will the 'metadata' in the project root directory. Once the compilation is completed, the builder will direct Powerada to convert the project into a read-only baseline. It is now ready for developers to begin making source code changes and building their own executables.

The CM menu in PowerAda includes entries to support the most common operations. This menu is simply a 'shortcut' which provides a PowerAda look-and-feel GUI which interfaces to the ClearCase command line utility. A major advantage of the PowerAda/ClearCase integration is that developers are insulated from the ClearCase command line syntax, although they will still need to be trained in the concepts surrounding the ClearCase environment.

The developer will need a view of the source code files; for simplicity, assume that only Ada source code is under version control, and that the developer's Config Spec (a description of the user's view of CM) selects the most recent versions of source files. The developer then directs PowerAda to initialize a project within his view of the source code, using the view-relative pathname to the already-compiled code as the baseline to compile against. His project then appears to contain all the source code and no sublibraries and needs no recompilations because the source files are older than the sublibraries corresponding to them. When he checks out a file and modifies it, it will be recompiled by PowerAda into a local sublibrary, and other files will be recompiled only as necessary.