DataMuseum.dk

Presents historical artifacts from the history of:

Rational R1000/400 Tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about Rational R1000/400 Tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - download
Index: ┃ T V

⟦e00c7043f⟧ TextFile

    Length: 19772 (0x4d3c)
    Types: TextFile
    Names: »V«

Derivation

└─⟦5829e5ed5⟧ Bits:30000534 8mm tape, Rational 1000, RCI 2_0_5
    └─ ⟦c9a165082⟧ »DATA« 
        └─⟦c3895f76e⟧ 
            └─⟦this⟧ 

TextFile

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;