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=0.6 required=5.0 tests=BAYES_05,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ucla-cs!ames!ucbcad!ucbvax!hutcs.UUCP!amn From: amn@hutcs.UUCP.UUCP Newsgroups: comp.lang.ada Subject: obsolete vs. removed from the library Message-ID: <8703130014.AA01241@hutcs.UUCP> Date: Sat, 14-Mar-87 11:03:51 EST Article-I.D.: hutcs.8703130014.AA01241 Posted: Sat Mar 14 11:03:51 1987 Date-Received: Sun, 15-Mar-87 03:54:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet List-Id: According to LRM 10.1:6 a subprogram body is treated as a secondary unit if the program library already contains a library unit (= a sub- program declaration) that is a subprogram with the same name. This means that to recompile a library subprogram the declaration or context clauses of which have been changed one has to compile a genuine subprogram specification without the corresponding body as a separate compilation unit. LRM 10.3:5 states that obsolete compilation units must be recompiled unless they are no longer needed. I think this means you cannot recompile a subprogram body if its specification is obsolete, as the recompilation needs the specification. I am not sure whether there is any need for having obsolete compilation units in the library. I think that 10.3:5 means that obsolete compilation units cannot be utilized. The only reason to have obsolete compilation units in a program library could be that the compilation library tools can decide which compilation units need to be recompiled after an 'obsoleting' compilation. Ari Mujunen Helsinki University of Technology (mcvax!penet!hut!amn, I suppose)