Re: new programmer wondering what to learn

["Marin David Condic, 561.796.8997, M/S 731-93" <condicma@PWFL.COM>]

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,
><snip>

    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
><snip>

    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
===============================================================================