Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!uw-beaver!tektronix!teklds!zeus!bobr
From: bobr@zeus.TEK.COM (Robert Reed)
Newsgroups: comp.sys.apollo
Subject: Re: DSEE Benefits / Converting to DSEE
Message-ID: <1907@zeus.TEK.COM>
Date: Mon, 22-Jun-87 22:34:53 EDT
Article-I.D.: zeus.1907
Posted: Mon Jun 22 22:34:53 1987
Date-Received: Wed, 24-Jun-87 05:53:00 EDT
References: <3596c60e.b0a1@apollo.uucp>
Reply-To: bobr@zeus.UUCP (Robert Reed)
Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
Lines: 90

In article <3596c60e.b0a1@apollo.uucp> nazgul@apollo.UUCP (Kee Hinckley) writes:

        DSEE manages binaries.  This means that if I'm working on one part of
    a system, and someone else is working on another, we can share binaries.
    DSEE keeps track of what binaries have been built using what compiler
    options.  The model description tells it which options are critical and
    which are not, so it knows whether or not you can use the result of
    someone elses build.  This is very nice on large projects when multiple
    people are working on different branches of a few files, but need to
    share the rest.  Furthermore you can tell DSEE whether or not the tools
    are critical, so if you get a new compiler, or translator or whatever
    tool you are using, DSEE will know whether it should recompile
    everything.

We could certainly reduce our disk requirements by sharing common binaries
and/or source files.  It's never been a problem for us, though.  Each of us
on the design team has a 1-2 MB directory containing private copies of all
the sources and objects, and our make dependency graph connects the sources
to a common RCS directory.  We have the option of including updated sources
for a particular make or not, which allows us to isolate ourselves from the
changes of others.  I would be concerned with a system that uses common
binaries which did not provide this isolation.  If a member of the team
releases a change which involves several binaries, one or more of which I am
also making changes to, is there some way to automatically prevent the
incorporation of the rest of the binaries involved in this change?  

For example, if a system consists of modules a, b and c, suppose someone
else has checked out b and c when I proceed to check out b.  I begin to make
and test changes to b, but suddenly a new version of b and c are released to
the world.  If these foreign changes to b and c are dependent on one
another, is DSEE flexible enough not to include the new object for c in my
subsequent builds of the system?  My guess is that since I have not checked
out c, I would get the common version, which may mean that my bind will fail
(if for example, my version of b had a vestigial external reference,
formerly resolved by c).

Management of binaries may be a very economic feature, but there are
pitfalls (which DSEE may handle adequately).  I know that private working
directories with Make/RCS can do the right thing.  I am curious whether DSEE
can do the same.  This is not meant as a challenge, just a plea for
information.

        DSEE can automatically perform actions when something happens (such as
    the replacement of an item).  So you can tell it to watch a file for you
    and tell you when it changes.

Change notification is certainly a useful service in a multi-person project.
We handle change notification by requiring a release note whenever any set
of files is returned to the common directory.  This gives an opportunity for
the developer to summarize the changes as well as give notice of them.  The
release note is mailed to each of the developers, to be examined at their
leasure.  I expect that DSEE uses a similar mechanism.  Though I rarely have
need for an explicit notice on the release of a particular file, I'll not
deny that it may have some use.  Providing a server for that purpose does
seem a bit of overkill (I am assuming that this function is handled by the
DSEE server), so I hope the server has more purpose than simple notification.

        DSEE supports threads.  These allow you to tell DSEE what versions of
    what files to use when you build, and what options to use on what files
    (either specifically or by wildcard).

    Threads allow you to do things like (as I just did now) tell DSEE that I
    want a different version of a header file and have it promptly know that
    as a result it has to recompile five other programs that depend on that
    file.

This appears to provide some features not available in Make.  I would have
to get a better description of them to acertain that.  I've felt for a long
time that the option selection features of Make are underpowered.  Regarding
the specific example, I would probably never use such a "thread."  We keep
two (actually more) versions of our program around, one with no debug and
one with debug in every module.  This avoids the hassle of chasing down a
bug, only to find that the path leads through a module which does not have
the debug symbol tables loaded.

        DSEE supports multiple builders.  For instance I have a version of
    the ICON programming language under DSEE.  It consists of 4 libraries
    (insert files, translator, linker, runtime) under control of a single
    dsee model.  There are about 80 files in all.  I'll start off a rebuild
    of everything right now and see how long it takes.  This will take a
    little longer than a normal build, since it purges the old builds in the
    process, but it should still give you and idea of the advantage.

I don't understand what you mean by "multiple builders."  Is it something
different from multiple Make targets?  You say that this should give us an
idea of the advantage.  I'm having trouble understanding what it is that
this gives an advantage over.  Are you comparing multiple builders versus a
single builder under DSEE?  Or, are you comparing features of DSEE and Make?
-- 
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK