Mon, 20 Nov 2000 13:09:16 -0800
> -----Original Message-----
> From: Team Ada: Ada Advocacy Issues (83 & 95)
> [mailto:[log in to unmask]]On Behalf Of Jeff Creem
> Sent: Monday, November 20, 2000 3:51 AM
> To: [log in to unmask]
> Subject: Re: "use" statements... (But really Ada library model musings)
> > So what is the difference between "registering files" and "importing
> > subsystems/views" from an Ada source code perspective? Very little it
> > seems. I haven't used Apex, but how does it handle multi-compilation unit
> > Does it have the same restrictions as GNAT (i.e. one compilation unit per
> > If this is true, then I would guess that the Apex mechanism is not that
> > different to the ada-mode mechanisms for Projects using Emacs and GNAT.
> > John
> Importing subsystems/views is closer to having a default set of -I lines
> to gnatmake (include path) on a per directory basis (this is a
> simplification of
> the power of subsystems/views but it is the best analogy).
> Apex requires one compilation unit per file and also requires that files
> follow a
> specific naming convention. The big difference between the models is that
> Apex holds onto
> ASIS and/or other tree data after the compile so that it can be used later
> by other
> tools (or during other compiles). This lets them avoid having to re-parse
> all the with'd
> specs of a file. As to whether or not this is faster than the GNAT
> model......Not even close up
> to version 3.0.0b (I have heard that the 3.2 series is faster).
Comparing compilation speeds is always tricky. Is Apex a fast compiler?
Not by GNAT standards on a small amount of source code. Is Apex
a fast re-compiler? Yes, on any significant source code bases. Particularly when
the fine-grained dependency model of Apex is able to ignore large sections of
code that would otherwise need re-compiling. Because Apex knows exactly
what changed, and therefore exactly which units could be impacted by that
change, it avoids recompiling a unit just because a specification somewhere
in the dependency hierachy had a declaration/comment/constant change that
this unit didn't actually make use of.