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: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: seperate keyword and seperate compilation with Gnat? Date: 1996/07/08 Message-ID: #1/1 X-Deja-AN: 167723776 references: <31D95D93.28D8D15B@jinx.sckans.edu> <31DA7327.6CE2@epi.syr.lmco.com> <4rrdn0$10mk@info4.rus.uni-stuttgart.de> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-08T00:00:00+00:00 List-Id: Michael said "So, you don't consider me a customer anymore? :-) We talked about precisely this issue at the GNAT workshop in Frankfurt last year. The fact that GNAT does not compile subunits into separate object files caused us some problems when we switched from Verdix to GNAT. We have now restructured our code so this is not a big issue anymore, but in order to save compilation time during developement it would still be helpfull to have this feature. All of our examples are of type 2 and if a separate code generation could be achieved easily it would be nice to have but there are certainly more important problems to be solved (e.g. a more efficent handling of unconstrained arrays)." Right, I know you mentioned this, but you also said that you could restructure your code without any big problem (which I guess was true :-) However, what is really interesting, and what we did not discuss back in Frankfurt was the distinction between type 1 and type 2. It is VERY easy to allow separate compilation of type 2 subunits (those nested inside packages), and in fact it is almost just a matter of removing a restriction (well not quite a bit of binding trickery is required), but it is really easy. What I mean when I said no one had commented on it was that no one had declared that this was a really hot issue, and that surprised me. I thought we would run into at least some customers for whom this would be a blocking problem. Interestingly, I just talked with another customer, inspired to think about the future by my post, who might be in exactly that category, but there too, they are all type 2 (inside package) cases and not the much more deadly type 1 (inside subprogram) cases. So the conclusion is that it definitely seems worth providing an option to compile type 2 subunits separate (it can be an option, so nothing will be lost if you want to do it the old way, which is more efficient in compilation time if you are recompiling the whole subtree). Something to look into, probably not for the vesion immediately coming out, but certainly for the vesion after that. P.S. Having a close look at unconstrained arrays is getting near the top of the priority list, so I think something will happen there soon too (this is actually very target dependent, on some targets, unconstrained arrays are handled fine, on others not. This results from treating fat pointers as records.