|
DataMuseum.dkPresents historical artifacts from the history of: Rational R1000/400 Tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about Rational R1000/400 Tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T V
Length: 19772 (0x4d3c)
Types: TextFile
Names: »V«
└─⟦5829e5ed5⟧ Bits:30000534 8mm tape, Rational 1000, RCI 2_0_5
└─⟦c9a165082⟧ »DATA«
└─⟦c3895f76e⟧
└─⟦this⟧
with Cmvc;
with Compilation;
with System_Utilities;
package Rci_Cmvc is
-----------------------------------------------------------------------
-- All Rci_Cmvc commands raise Profile.Error if any error is detected
-- and Profile.Propagate or Profile.Raise_Error is true
------------------------------------------------------------------------
procedure Release (From_Working_View : String := "<CURSOR>";
Release_Name : String := "<AUTO_GENERATE>";
Remote_Machine : String := "";
Remote_Directory : String := "";
Level : Natural := 0;
Views_To_Import : String := "<INHERIT_IMPORTS>";
Create_Configuration_Only : Boolean := False;
Compile_The_View : Boolean := True;
Goal : Compilation.Unit_State := Compilation.Installed;
Comments : String := "";
Work_Order : String := "<DEFAULT>";
Volume : Natural := 0;
Response : String := "<PROFILE>");
-- Creates a release of an RCI view.
--
-- If Remote_Directory = "", only the host component (view) will be
-- released. If a non-null Remote_Directory is supplied, the remote
-- directory will be built as well.
-- If Release_Name is
-- "<AUTO_GENERATE>", the view will have the same name prefix as the
-- working view, with _n_m appended as appropriate given the level.
-- Otherwise Release_Name must be the simeple name of the new release.
-- Since the new view is a release, it is frozen. If From_Working_View
-- names multiple views, each named working view is released as
-- above, and the imports are adjusted so that the new releases
-- reference each other as appropriate instead of the working views.
-- Views_To_Import specifies, perhaps by indirection through an activity,
-- a set of views to be used as imports by the new view(s). This allows
-- changing imports during a release. Imports already adjusted during
-- the releasing of working views will be left alone, otherwise
-- subsystems currently imported will be reimported. In other words,
-- if this were an import command, Only_Change_Imports would be true.
-- If Compile_The_View is true, the compiler is run before the views
-- are frozen, trying to promote the units to the indicated Goal.
-- The views are frozen even if compilation fails.
-- This command creates a configuration object named release_name
-- and a state directory named release_name_state. Both
-- objects are created in SUBSYSTEM.state.configurations.
-- The objects can be used by the build command to reconstruct
-- a view from the released configuration.
-- A controlled text object (state.release_history) is used by this
-- command. Release enters the comments supplied with the command
-- into the notes for this object. Feel free to check out and modify
-- this object to further describe what is going on. This object is joined
-- across all of the releases and the working view of a subpath.
-- Furthermore, the object is checked out and in by the release command
-- in order to mark the time of the release.
-- **
procedure Copy (From_View : String := "<CURSOR>";
New_Working_View : String := ">>SUB/PATH NAME<<";
Remote_Machine : String := "";
Remote_Directory : String := "";
View_To_Modify : String := "";
View_To_Import : String := "<INHERIT_IMPORTS>";
Only_Change_Imports : Boolean := True;
Join_Views : Boolean := True;
Reservation_Token_Name : String := "<AUTO_GENERATE>";
Construct_Subpath_Name : Boolean := False;
Create_Spec_View : Boolean := False;
Create_Load_View : Boolean := False;
Create_Combined_View : Boolean := False;
Level_For_Spec_View : Natural := 0;
Model : String := "<INHERIT_MODEL>";
Remake_Demoted_Units : Boolean := True;
Goal : Compilation.Unit_State := Compilation.Coded;
Comments : String := "";
Work_Order : String := "<DEFAULT>";
Volume : Natural := 0;
Response : String := "<PROFILE>");
-- Create a new working view. Working views are named Mumble_Working,
-- where mumble is supplied as New_Working_View. If Join_Views is
-- true, the two views share reservations of the all of the controlled
-- objects in the two views. If false, reservations aren't shared
-- across the views for any objects. If From_View names multiple views, a
-- copy is made for each of those views and, if the originals
-- import each other (computed using the subsystem, not the view),
-- the copies will (try) to import the new views of those subsystems.
-- If Join_Views is false, new reservation tokens are created for all
-- of the controlled objects. The default is to use the name supplied
-- as the >>SUBPATH_NAME<<.
-- View_To_Import supplies a set of views to be processed according to
-- the value of Only_Change_Imports. If Only_Change_Imports is true,
-- a copied view always inherits the source view's imports. After the
-- copy, the imports specified by View_To_Import are applied against the
-- new view, replacing any inherited import if needed.
-- If Only_Change_Imports is false, then either the imports are inherited
-- from the source, or the complete set of imports specified by
-- by View_To_Import is imported into the copy.
-- View_To_Modify specifies the set of working views that are to have
-- their imports changed to refer to the new copy(s). The
-- View_To_Modify views are also changed to refer to the views specified
-- by View_To_Import. For this import operation, Only_Change_Imports
-- is forced to true.
-- Construct_Subpath_Name cause Copy to contruct the target view name
-- by appending New_Working_View to the prefix of the source view name
-- up to the first '_' (See paths and subpaths below).
-- Remake demoted units, if true, indicates that ada units that were
-- demoted during the copy process are to be recompiled. They are
-- compiled to the level indicated by Goal.
-- Goal further indicates the desired state of all of the units after
-- copy. No unit will be in a state higher than specified by goal, but
-- might be in a lower state. For example, a source unit that is copied
-- will remain source, regardless of Goal, but a Coded unit will be
-- demoted if Goal is installed or less.
-- The order of the copy and import operations is:
--
-- 1. Create the new view.
-- 2. If Inherit_Imports, bring along the old imports
-- 3. Import the new views into the new views, forcing
-- Only_Change_Imports => True
-- 4. If not Inherit_Imports, import the specified views
-- into the new views.
-- 5. Import the new views + View_To_Import into Views_To_Modify,
-- forcing Only_Change_Imports => true
-- Spec views are created by copying the units if the source is a load
-- view, otherwise using Relocation. Spec views are created with all
-- objects uncontrolled. If level_for_spec_view = natural'last, the
-- spec view is given the name supplied as new_working_view, otherwise
-- a name is generated as 'New_Working_View & Release_Numbers & "_spec"'
-- In a spec_load subsystem, combined views can be created by setting
-- the create_combined_view parameter. Combined views are useful in
-- spec_load subsystems when spec and load views are compiled for the
-- R1000 target and combined views must be compiled for a different
-- target that does not support subsystem look-through.
-- Note that if create_spec_view, create_load_view, and create_combined_view
-- are all false, then the new view has the same type as from_view.
-- It is an error to set more that one of these parameters to be true.
-- It is recognized that this is a complicated command. Using the
-- procedures below (which are effectively renames) might make more
-- sense if the methodolody in use permits it (Path, Subpath, etc).
------------------------------------------------------------------------
-- PATHS AND SUBPATHS --
------------------------------------------------------------------------
-- The following procedures support the notion of paths and subpaths.
-- A Path is a logically connected series of releases in which all
-- controlled objects are joined together. In other words, there is
-- no branching within a path. A Subpath is an extension of the
-- path, allowing multiple developers to make changes and test
-- without getting in each others way. However, controlled objects
-- in the subpaths are joined with the path; people in two subpaths
-- cannot independently change the same object. In addition, a path
-- and its subpaths share the same model, which means they share
-- the same Target_Key and initial links.
-- In Delta, paths and subpaths are identified by string name conventions.
-- The name of the path is the view name up to the first '_'. The
-- subpath extension is the name from this '_' to the '_Working'. Thus
-- Rev9_Cbh_Working has a path name of Rev9 and subpath extension of
-- Cbh.
-- Multiple paths are used when multiple targets are involved, or when
-- objects are to be changed independently. For example, assume that
-- a version of a product has been shipped, and is in maintenance, and
-- that development is progessing on a new version. It is likely that
-- the old and new versions would be separate paths, since the objects
-- would have to be independently changed (these paths would not be
-- 'joined').
-- In the multiple target case, the paths might be created joined.
-- Using the above scenario, assume that the release that has been shipped
-- works on two targets, but most or all of the code is target
-- independent. Then the two paths, one for each target, would be
-- created joined together, then have the objects that are not common
-- 'Sever'ed.
-- **
procedure Make_Path (From_Path : String := "<CURSOR>";
New_Path_Name : String := ">>PATH NAME<<";
Remote_Machine : String := "";
Remote_Directory : String := "";
View_To_Modify : String := "";
View_To_Import : String := "<INHERIT_IMPORTS>";
Only_Change_Imports : Boolean := True;
Model : String := "<INHERIT_MODEL>";
Join_Paths : Boolean := True;
Remake_Demoted_Units : Boolean := True;
Goal : Compilation.Unit_State := Compilation.Installed;
Comments : String := "";
Work_Order : String := "<DEFAULT>";
Volume : Natural := 0;
Response : String := "<PROFILE>");
-- Refer to Make_Subpath comments.
procedure Make_Subpath
(From_Path : String := "<CURSOR>";
New_Subpath_Extension : String := ">>SUBPATH<<";
Remote_Machine : String := "";
Remote_Directory : String := "";
View_To_Modify : String := "";
View_To_Import : String := "<INHERIT_IMPORTS>";
Only_Change_Imports : Boolean := True;
Remake_Demoted_Units : Boolean := True;
Goal : Compilation.Unit_State := Compilation.Installed;
Comments : String := "";
Work_Order : String := "<DEFAULT>";
Volume : Natural := 0;
Response : String := "<PROFILE>");
-- Builds a path (Combined_View) from an existing R1000 or RCI view. In
-- addition to building a new path, the RCI state will be initialized.
--
-- A new Remote_Directory must be specified when a new path is built. This
-- is to prevent two views in a subsystem from overwriting the same target
-- directory. In fact, these routines will check that the specified
-- Remote_Directory is not used by any of the other views within the
-- subsystem of the new path. If this parameter is defaulted, units in the
-- new path may only be promoted to the Installed State.
--
-- If the new path is being built from an R1000 view, a new model world and
-- new imports must be specified.
--
-- Imports must be from other combined views with the same Target_Key as
-- the new path.
--
-- By default, units are only promoted to the Installed State.
-- The Subpath_Extension is appended to the path name of the source
-- view (From_Path). From_Path can actually name the path or any
-- subpath of the path. The '_' between the path and subpath extension
-- is automatically provided.
-- **
------------------------------------------------------------------------
-- SYSTEM OBJECTS --
------------------------------------------------------------------------
type System_Object_Enum is (Spec_Load_Subsystem,
Combined_Subsystem, System);
-- System objects may be either subsystems or systems. A subsystem
-- may be either a spec_load_subsystem or a combined_subsystem.
-- The type of subsystem controls the kinds of views which
-- the system object may contain. The subsystem type also controls
-- whether importing into the subsystem must be hierarchical or
-- may be non-hierarchical.
-- Spec_Load subsystems may contain spec views, load views, or
-- combined views. All views in spec_load subsystems are
-- restricted to have only hierarchical imports. A views imports
-- are hierarchical if the import closure of the view does not
-- contain itself.
-- Combined subsystems may only contain combined views. The views
-- in a combined subsystem need not have hierarchical imports.
-- A view in a combined subsystem may include itself in its
-- import closure.
-- Systems contain system views. Systems are used by Cmvc_Hierarchy
-- to coordinate the construction of multi-subsystem systems.
-- Mechanisms are available to extend
-- these routines to remote library components. Refer to the RCI
-- user's manual for more information.
-- **
procedure Initial (Subsystem : String := "<IMAGE>";
Working_View_Base_Name : String := "Rev1";
Remote_Machine : String := "";
Remote_Directory : String := "";
Subsystem_Type : Cmvc.System_Object_Enum :=
Cmvc.Spec_Load_Subsystem;
View_To_Import : String := "";
Model : String := ">>RCI MODEL<<";
Comments : String := "";
Work_Order : String := "<DEFAULT>";
Volume : Natural := 0;
Response : String := "<PROFILE>");
-- Builds a new combined view in an existing subsystem, or builds a new
-- subsystem and combined view. In addition to creating a new view, this
-- routine will initialize its RCI state.
--
-- Remote_Machine specifies the machine where the remote directory and
-- remote program library will be located. The value specified is assigned
-- to the Ftp.Remote_Machine switch in the Compiler_Switches file. If
-- defaulted, it will not be possible to bring units to the Coded state in
-- the combined view (and in the remote directory).
--
-- Remote_Directory specifies the directory on the Remote_Machine to which
-- units will be transferred. The value specified is assigned to the
-- Ftp.Remote_Directory switch in the Compiler_Switches file. If it is
-- defaulted, it will not be possible to bring units to the Coded state in
-- the combined view (and in the target program library).
--
-- The Model must specify a model world with an RCI Target_Key.
-- **
------------------------------------------------------------------------
procedure Build (Configuration : String := ">>CONFIGURATION NAME<<";
Remote_Machine : String := "";
Remote_Directory : String := "";
View_To_Import : String := "<INHERIT_IMPORTS>";
Model : String := "<INHERIT_MODEL>";
Goal : Compilation.Unit_State := Compilation.Installed;
Limit : String := "<WORLDS>";
Comments : String := "";
Work_Order : String := "<DEFAULT>";
Volume : Natural := 0;
Response : String := "<PROFILE>");
-- Rebuild the host view from history. If Configuration_Object_Name refers to
-- a text file, that file is assumed to contain a list of configuration
-- object names to be built.
-- If the Remote_Machine and Remote_Directory parameters are nonempty,
-- a target library will be constructed.
-- If View_To_Import = "<INHERIT_IMPORTS>", and if a directory with
-- the name "same as configuration_object" & "_STATE" exists, that
-- directory contains state that is used to rebuild the imports.
-- Note that the state directory is created by the release command
-- when a configuration-only release is created.
-- The Unit_State for the Goal parameter is limited to
-- Compilation.Installed, since only the host view is rebuilt.
procedure Make_Spec_View
(From_Path : String := "<CURSOR>";
Spec_View_Prefix : String := ">>PREFIX<<";
Level : Natural := 0;
Remote_Machine : String := "";
Remote_Directory : String := "";
View_To_Modify : String := "";
View_To_Import : String := "<INHERIT_IMPORTS>";
Only_Change_Imports : Boolean := True;
Remake_Demoted_Units : Boolean := True;
Goal : Compilation.Unit_State := Compilation.Coded;
Comments : String := "";
Work_Order : String := "<DEFAULT>";
Volume : Natural := 0;
Response : String := "<PROFILE>");
-- Make a spec view for a path. Spec_View_Prefix is the string that
-- replaces the path and subpath name. For example, if creating a
-- spec view from a subpath named rev9_cbh_working, with
-- Spec_View_Prefix => Env9, the result will be Env9_n_Spec, assuming
-- level => 0 and two levels are specified by the model. N is a
-- number automatically generated from the current release number for
-- the path/subpath. If level = natural'last, the name supplied as
-- Spec_View_Prefix is used for the name of the view, with no suffixes
pragma Module_Name (4, 4147);
pragma Bias_Key (32);
end Rci_Cmvc;