Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!masscomp!ulowell!apollo!joelm
From: joelm@apollo.UUCP
Newsgroups: comp.sys.apollo
Subject: Re: DSEE Benefits / Converting to DSEE (long)
Message-ID: <35eb268f.86ca@apollo.uucp>
Date: Tue, 7-Jul-87 11:13:00 EDT
Article-I.D.: apollo.35eb268f.86ca
Posted: Tue Jul  7 11:13:00 1987
Date-Received: Thu, 9-Jul-87 02:19:37 EDT
References: <3596c60e.b0a1@apollo.uucp> <1907@zeus.TEK.COM> <35afc9e0.b0a1@apollo.uucp> <35b36fa0.c366@apollo.uucp> <1745@zaphod.UUCP>
Reply-To: joelm@apollo.UUCP (Joel Margolese)
Organization: Apollo Computer, Chelmsford, MA
Lines: 104

In article <1745@zaphod.UUCP> billj@zaphod.UUCP (Bill Jones) writes:
>
>- is there support for maintaining, as Bob Reed mentioned, parallel
>  systems of derived objects, say one with debugging turned on and one
>  not?  Or will most of the binaries have to be recreated on each build
>  as the pool cache capacity is reached?

The whole point of the caching scheme is to maintain prallel systems of
derived objects.  Remember, DSEE views the world from the source point of
view.  It decides (forgive me some anthropomorphisms) what sources and
translator options are necessary and then tries to find a build in the
pools that matches the requested versions and options.  You can specify
some options as "critical" to the build, i.e. debugging information,
or as "non-critical" i.e. produce a map file.  If the pools are not
configured with enough depth (i.e. number of builds of each object)
then you can of course thrash, but that is a problem that is easily
solved and one that we almost never encounter.  The pool can be reconfigured
at any time.


>- in the above environment, what support is there for variant
>  implementations of the same module?  Must the elements be named
>  differently, and the system model preprocessed, to avoid conflict, or
>  can they be distinguished automatically in the directory structure?

There is only one "element".  In fact, it is an extensible streams
object.  (From the Open Systems Toolkit.)  So that the directory structure
appears to be consistant, that is to say the elements and all the
varients (branches) appear to exist.  The reality is that they are created
on the fly by the streams manager when they are requested.  This operation
is surprisingly quick.  One of my favorite demos is to open random versions
of case-history objects and show that it is about as fast as opening
plain ascii.  For example the library "src" contains element "pgm.c".
"pgm.c"  pgm.c could have several lines-of-descent (variations) going on
at once.  Each could be refered to by its branch name.  I.e. pgm.c/bug_fix
pgm.c/risky_changes, pgm.c/add_debug_statments.  Note that no special
version is necessary to compile it with debug information.  That is an
option that is specified at build time.
  
>
>- can a bug-fix or feature branch to several elements be treated
>  (e.g. named or merged) globally, or must the operations be repeated
>  for each element affected?

Each element must be merged independently.  I don't think that I would
trust any merge system that did the merging w/o my supervision.  Most
of the merge work is automatic, so very little intervention is required,
provided your changes on the branch do not conflict with changes on
the main-line of descent.  All elements (branches or main_line) can be
named globally.  Nameing is pretty flexible, you can name specific
versions or just say: name all versions used in this build.

>
>- can a system be composed of subsystems each maintained in its own
>  directory structure, or must there be a single system model (with
>  absolute pathnames) for the whole?
>
The directory structure is independent of the models.  All "elements"
(progams, modules, insert files etc...) live in libraries.  Any system
model can refer to any library, and more then one system model can
refer to the same library.  Generally, you would group your sources
logically in similar libraries, i.e. src modules, insert files etc...
and then create a model to build what you need.  You can use smaller
models to build subcomponents, and then include them (literally with
a %include statement) in a larger model that incorporates many
smaller models.  Most of the time though, it is simpler just to make
one large model.  You can at build time specify which subcomponents
to build.  i.e. build foo.pas, build foo.system (which includes foo.pas)
or just "build" which builds everything in the model.  (Or finds 
appropriate builds in the pools.)

>- the extracts quoted from system models indicate that include
>  dependencies must be specified manually.  I understand that there is
>  a make_model program to determine these automatically when the model
>  is first written, but has there been any support added to generate
>  them dynamically at build time?

There is *sigh* no such support.  Though, you will get a warning if
your program reads a DSEE library element that was not declared.  In
general it is not a great idea to include non-DSEE elements.  It works
just fine, but you lose all of the history information.  Make_model
still needs a bit of work.

>
>- if the structure of the system is changed at some point in a way
>  which significantly affects the system model, will subsequent
>  modifications to earlier configurations see the new or old model?

Part of specifying which versions go into a build is specifying
a version of the model to use.  (Models are generally DSEE library
elements themselves.)  So, if you want to build an older version of
your modules, you would use and older version of the model.


>Bill Jones, Develcon Electronics, 856 51 St E, Saskatoon S7K 5C7 Canada
>uucp:  ...ihnp4!sask!zaphod!billj               phone:  +1 306 931 1504
 
                                             Joel


-- 
Joel Margolese          UUCP:      ...{attunix,uw-beaver,decvax!wanginst}!apollo!joelm
Apollo Computer         ARPA:     apollo!joelm@eddie.mit.edu
                        INTERNET: joelm@apollo.com