Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!mit-eddie!apollo!mishkin
From: mishkin@apollo.uucp (Nathaniel Mishkin)
Newsgroups: comp.sys.apollo
Subject: Re: DSEE Benefits / Converting to DSEE (long)
Message-ID: <35b36fa0.c366@apollo.uucp>
Date: Fri, 26-Jun-87 09:20:00 EDT
Article-I.D.: apollo.35b36fa0.c366
Posted: Fri Jun 26 09:20:00 1987
Date-Received: Sat, 27-Jun-87 09:13:39 EDT
References: <3596c60e.b0a1@apollo.uucp> <1907@zeus.TEK.COM> <35afc9e0.b0a1@apollo.uucp>
Reply-To: mishkin@apollo.UUCP (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 46

I think Kee's message did a fine job of explaining the subtleties of
DSEE.  One important point about sources and binaries is getting lost
in the noise though:  DSEE users always deal with sources and source
specifications, not binaries.  DSEE completely manages binaries (and
assuming the user hasn't lied about the relationships among the pieces
of his system, DSEE doesn't ever get confused about what binaries
correspond to what sources and options.)  The DSEE user does not say
"use these binaries", s/he says "I want the thing that results from using
such-and-such versions of sources".  "such-and-such versions of sources"
is a function of the "thread" (described in Kee's message) and the "system
model", a block-structured description of the relationships among sources
and results of compilations.  A sample model fragment:

    aggregate ls =
        depends_result
            element ls.c =
                depends_source
                    sort.h;
                end;
        
            element sort.c =
                depends_source
                    sort.h;
                end;
        end;

This says that there's an aggregate (read "program") "ls", the building
of which depends on the result of building "ls.c" and "sort.c", and that
both "ls.c" and "sort.c" depend on the source (i.e. textually) of "sort.h".
(Note: there more to the model than I've shown.) The model says nothing
about particular versions or binaries.

When a user asks to build "ls", the model plus the user's current thread
yields a tree-structured description (analogous to the model tree
structure, with the addition of particular version numbers for every
source element) of what the user wants.  DSEE then searches its "binary
pool" (a directory that the user never looks at where DSEE keeps binaries;
binaries are tagged with the tree-structured description that describes what
source versions were used to build the binaries).  If it finds matching
entries in the pool, it just uses them; if it doesn't, it creates them
(by running the correct "translate" rule from the model).
-- 
                    -- Nat Mishkin
                       Apollo Computer Inc.
                       Chelmsford, MA
                       {wanginst,yale,mit-eddie}!apollo!mishkin