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,6a9844368dd0a842
X-Google-Attributes: gid103376,public
From: "Mike Card (x3022)" <card@epi.syr.lmco.com>
Subject: Re: seperate keyword and seperate compilation with Gnat?
Date: 1996/07/03
Message-ID: <31DA7327.6CE2@epi.syr.lmco.com>#1/1
X-Deja-AN: 163496920
references: <31D95D93.28D8D15B@jinx.sckans.edu>
cc: card@epi.syr.lmco.com
content-type: text/plain; charset=us-ascii
organization: Lockheed Martin Corporation Syracuse NY
mime-version: 1.0
newsgroups: comp.lang.ada
x-mailer: Mozilla 2.02 (X11; I; SunOS 5.4 sun4m)
Date: 1996-07-03T00:00:00+00:00
List-Id: <comp.lang.ada>


David Morton wrote:
> 
> I've been working with John Herro's AdaTutor
> program on Linux, and gnat.
> 
> He uses the keyword seperate a lot, to make the assignment
> procedure in a seperate file, ie,
> 

<snip>

> He argues that the file foo.adb should be able to be compiled,
> seperately, since the specification is there, even though the actual
> procedure body has not been written.  I'm inclined to believe that he's right,
> but gnat refuses to cleanly compile unless the file foo-bar.adb exists.
> 

<snip>

> 
> Could anyone explain why gnat does not allow this?
> 
> --
> David Morton
>  mailto:dmorton@jinx.sckans.edu    // If you use Netscape 2.0,
>  205 College, Winfield, KS 67156   // you can click on the mailto: part to reply!
>                                    (HINT, HINT)  :)

I have been waiting for Mr. Dewar or someone else from ACT to reply to
your question. We have been using GNAT since version 2.06 and it has
always treated subunits this way. (A "subunit" is a procedure, function,
or package body that is separate from its enclosing package body. A
subunit body is preceded by a "separate(package_name)" clause.)

It appears that what GNAT in effect does is a #include of all subunit
bodies. If you try to compile a subunit by itself, GNAT will compile it
but not generate any object code for it. Likewise, if you compile a
package body which has within it subunit declarations (i.e. "function X
return Boolean is separate;") GNAT will only generate object code *if*
it can compile all of the subunits. 

Now, I suppose that GNAT's "#include" approach could be defended
by an argument like "GNAT *compiles* the subunits and their enclosing
bodies in accordance with the LRM, it just doesn't generate object code
for them unless ..."  I think that GNAT could thus be said to obey the 
*letter* of the LRM, but "#include'ing" subunits does not, IMHO, obey
its *spirit*.

I have worked on projects where a significant piece of a system's 
functionality was encapsulated within one Ada package. Some of these
packages had over 100 functions and procedures in them, and we made each
of these a subunit. Why? So that making changes to one of these
would not require recompilation of the entire package body and all 100+ 
subunits. The design of GNAT removes this important benefit. If you
can't change a subunit and the re-link and re-run your program without
having to recompile the enclosing package and all of the other subunits
as well, why bother to have subunits at all? With GNAT, you might as
well not use subunits unless (as in our case) you are planning to later
port your code to environment that provides *true* separate compilation
(i.e. Rational/VADS).

Regards,

Mike