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