From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a7e399a115a66840 X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-93" Subject: Re: new programmer wondering what to learn Date: 1997/05/30 Message-ID: <97053010032445@psavax.pwfl.com>#1/1 X-Deja-AN: 244990833 Sender: Ada programming language Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU X-Vms-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" Newsgroups: comp.lang.ada X-Vms-Cc: CONDIC Date: 1997-05-30T00:00:00+00:00 List-Id: Undetermined origin c/o LISTSERV administrator writes: > >The definition of CM is having control over your baseline, >including three particular aspects of the baseline: the parts >themselves, the changes to those parts, and the change requests >that induced those changes. Ada is a standard for generating code >in accordance with a time controlled configuration management >scheme that prevents mismatches in the changed parts, using a >particular method of packaging those parts which is superior >to the packaging in most other computer languages. Thus it >contributes to the first two aspects of CM control: control of the >parts themselves and the changes to those parts. It does not >contribute much to control over change requests. In addition, > Sounds a little more like what we call "Change Control" - which certainly dovetails with CM, but is not quite the same thing. (See my earlier post - I think we're just talking problems of definition.) Around here, we use one or two different "Librarian" systems (home-grown) in which a developer has to check out/check in source code in connection with a change request. (Mostly to lock out inadvertent race conditions between developers, but also for tracking the changes, etc.) Certainly, Ada adds assistance if some developer wants to push the compile button and make a build for some informal test purpose. "CM" comes into play when you push the compile button "for real" and make something you need to be able to reproduce. >code and actual object code. Finally, in a totally source code >system there will be no requirement to store the object code >files at all, reducing the number of configured files by about >half. Prior to the gnat age (PTTGA), Ada had a very great > Beg to differ. There is a real nightmare issue for CM in this day of modern compiler and OS technology which makes it even more important to put the image itself under CM. (Our CM weenie is right about now plugging her ears and yelling "I can't hear you, Marin! Ya! Ya! Ya!..." They *hate* hearing about this problem!) It works like this: You can take the exact, same source code file and the exact, same version of the compiler and put the two together on the same computer on two different days and get a different set of bits out the back end. You can argue all day long that they may be semantically equivalent sets of bits, but it won't get you anywhere. You can't *prove* that the new set of bits didn't introduce an error - which means re-running the verification tests. Hence, we still do configuration manage images from a formal build process and will probably continue to do so for a long time to come. >half. Prior to the gnat age (PTTGA), Ada had a very great >contribution toconfiguration management which gnat eliminated, >which was a built-in method of delivering an entire system in >a single text file, in the correct compilation order, ready to >compile and link. With gnat, we must use and external tool to >configure the parts list, which takes more tool money and labor >money. Luckilly, tools which work most of the time are included > Never had a problem maintaining separate module files. As a matter of fact, I've never worked on a job where the final "Configuration Managed" product was a single source file containing all the Ada (or Fortran, or C, or ____) code. Typically, you may have all the final source files locked up under a single directory - or use some tool like DEC CMS to manage the source files, but I've never seen it done where you take the separate source files and combine them into a single one for the final build process. I can't think of a good reason to do so since you can accomplish the same thing while maintaining separate files. For developmental reasons, you want them in separate files - probably with some kind of command procedure or shell script or whatever to accomplish the compilation in the proper order. when you reach a stopping point, you just park all the artifacts into someplace where they can't be modified and call the job done. Why would you want to do all the work of sucking up all the sources into a single file (in compilation order) just for CM? MDC Marin David Condic, Senior Computer Engineer ATT: 561.796.8997 Pratt & Whitney, GESP Fax: 561.796.4669 West Palm Beach, FL Internet: CONDICMA@PWFL.COM =============================================================================== "The chief problem of lower-income farmers is poverty." -- Nelson Rockefeller ===============================================================================