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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cc4a1f5e11494cc9 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: GNAT and subunits Date: 1995/03/28 Message-ID: <3la3fj$d7m@gnat.cs.nyu.edu> X-Deja-AN: 100540695 references: <3l6j48$82t@ns1.sw-eng.falls-church.va.us> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1995-03-28T00:00:00+00:00 List-Id: 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!