Re: GNAT and subunits

[dewar@cs.nyu.edu (Robert Dewar)]

First of all, it is perfectly possible to compile a parent without 
having the subunits around if all you want to do is check its semantic
consistency. Use the -gnatc switch as you would do when compiling a
package spec on its own. No code is generated of course. Similarly you
can compile subunits on their own with the -gnatc to check their semantic
consistency.

Actual code generation requires the entire subunit tree to be present. We do
this because in its current configuration, GCC does not support separate
compilation of nested procedures (which is essentially what a subunit is).
It is not particularly intended as a GOOD THING, just as a pragmatic
priority ordering. Some day we may try to implement separate compilation
of nested procedures in GCC, but right now it is certainly NOT on the to-do
list. 

I guess the one GOOD THING is that we can of course generate much more efficient
code for subunits, since we know what is in a subunit (in a conventional
model of subunit compilation, you have to make worst case assumptions about
what might be in the subunit, which gets worse in Ada 95 (for isntance you
have to assume that finalizable entities MIGHT be present). Also if you are
compiling  the parent anyway (which would normally require recompilation of
the subunits anyway), then this approach is faster. It is of course slower
if you just change one subunit.

Anyway, the point is that the only compilation that generates code is the
compilation of the parent unit, and of course in this case, all the subunits
must be present.

Now as to the second effect Phil noticed, this is really pilot error. Here
is the scoop. When you compile in -gnatc mode (or you goof and try to compile
something which can't generate code and get the error message "no code
generated") then you have not affected the object files in any way AT ALL.

Now there are three options in the binder. Phil was apparently using the
first, which is the default, and is what is used by gnatbl if you let
gnatbl do the bind. I suspect that Phil wants to use the second or third.

Option 1 (default). Use object files only (and ALI files). The binder 
in this mode COMPLETELY IGNORES source files. So of course when Phil
updated his subunit, and did a compilation to check its correctness which
had no effect on the object files, then the binder did not notice and used
the old objects without complaint. In this mode the binder merely checks
that the objects it sees are self consistent version-wide, but it does not
check that they are compatible with the source versions.

Option 2 (-a) All source file mode. In this mode, the binder requires that
(a) all sourrce files are present for all object files in the bind.
(b) the source file versions are consistent with the versions referenced
	in the object files.

Option 3 (-s) Sources if available. In this mode, the binder will find sources
for whatever source files it can locate, and for this subset of sources, it
will ensure consistency with the object files.

Note: to use gnatbl with these switches, do the gnatbind step separately, 
and then run gnatbl with the -linkonly switch.

Phil, if you want the binder to reject the program in the situation you
describe, where you have updated one of the subunit files, then you should
use option 2 or option 3. Clearly from your description of the behavior,
you used option 1.

I don't particularly feel the need to convince anyone that this is a legal
implementation, of course it is! Phil if you have some reason to think it
is not, I think it is your devious ACVC trained mind showing, and by all
means quote chapter and vese :-) :-)

In practice, when gnatmake is available, these kind of issues largely
disappear, because gnatmake will ensure that all necessary sources are
compiled automatically.

Is this GNAT treatment of subunits a GOOD THING, not particularly, and it
will particularly creak with giant subunit trees. On the other hand, with
Ada 95, I think subunits will be used less, since private child units can
be used for the same purposes in many situations and are preferable. Time
will tell whether it is worth doing the (considerable) amount of work to
add the necessary features to GCC to support "true" separate compilation
of subunits.

P.S. Phil, in trying to prove this is an invalid approach from the RM, 
remember that it is perfectly valid to COMPLETELY defer all code genration
to the bind step!

P.P.S. In discussing these issues earlier today, we contemplated two
features that might reduce the surrprise factor for people who don't
read the documentation carefully:

   1. If a parent unit is compiled with subunits missing, then revert
	automatically to -gnatc mode, complaining that "no code is
	generated because subunits are missing" or somesuch.

   2. Change the default of the binder to -s mode, we have been considering
	this for a while.

I would particularly be interested in people's reactions to suggestion 2.

P.P.P.S. Another note to Phil: remember also that it is perfectly fine to
automatically recompile things that need recompiling if the system detects
that such recompilations are required!