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,a02ecdd4cb0f0996 X-Google-Attributes: gid103376,public From: "Samuel T. Harris" Subject: Re: Pragma Inline and its Effects of Compilation Dependencies. Date: 2000/03/21 Message-ID: <38D7CD74.59C3C5BD@Raytheon.com>#1/1 X-Deja-AN: 600524725 Content-Transfer-Encoding: 7bit References: <8b64ul$jov$1@inputplus.demon.co.uk> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Raytheon Aerospace Engineering Services Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-03-21T00:00:00+00:00 List-Id: Ralph Corderoy wrote: > > Hi, > > I was recently asked to look into an Ada compilation problem that > centred around the use of pragma inline. The result was a realisation > that the pragmas weren't accurately reflected in the compiler suite's > dependency graph used to determine compilation order. Consequently, > when building a set of source from scratch a separate containing an > inlined routine wasn't being built before its callers. > > I'd like to check that I understand what's wrong and how it should work, > and then ask for advice on where to go from here. > < > > I believe calling an inlined routine creates a dependency from the > caller to the routine itself, and if it is a separate that isn't the > same as the body of the package, as used by the compiler above. > > First question. How well do other compilers handle this; not too well > judging by the the existence of adamakegen > (http://www.ics.uci.edu/~softtest/adamakegen.html) and its complaints > about Verdix/SunAda. In my experience I observed the following results ... Alsys ala version 4: Usually worked, sometimes didn't. VADS ala version 4-6: Never works well. Rational R1000 and Apex: Always works except when mutual inlining is involved. This is a good area for ASIS based tools. I use just such a beast to help resolve this issue. On the other hand, I have also found that compilation orders which general place bodies as soon as possible rarely have this problem so building a tool to handle this case may not be worth while if your tool can do bodies ASAP. If I remember correctly, Alsys had a switch to control when bodies appear in the order. It could do as soon as possible or as late as possible. Note that when a compiler requires a generic body be compiled before it is instantiated, then you have the same basic requirements. > > I've read a little about gnat's gnatmake and how the compiler doesn't > follow the normal library implementation and instead uses the source > files coupled with ALI files. Does that mean in practice it copes > correctly with inline dependencies, including when they're in separates? > The manual seemed to suggest it didn't consider source outside the > current library. That wouldn't help in my case. Consider if foo was > being built into a separate Ada library from bar; I alter foo.y.ada and > build locally there. I then want to move to bar's library and find it > is out of date. > > It seems what I need is something that will take many source files, > parse them, and spit out the dependencies for use in something like a > traditional makefile. It isn't a trivial task as things like package > renames and use clauses help to obscure what is being called. Plus it > mustn't make the mistake of thinking an inline creates a dependency to > the package body when a separate exists. Does something like this > exist? This is easily written using ASIS queries. Lacking access to ASIS, one can get a yacc/lex grammars for Ada and do the extra work yourself. Hopefully, your compiler tool can spit out "normal" dependencies so you don't have to worry about context clauses. You only have to worry about which subprograms are inlines and where they are called. Using syntax processes will easily handle straight subprogram calls but requires more work if your code is using rename declarations. > > The alternative seems to be to re-build bar from scratch whenever foo is > changed because it can't be left to the compiler to calculate what to > rebuild and relying on the programmer to know who calls foo.y is a > no-no. But building bar and everything else could take eons. If your code is stable and your dependencies are not changing much, then you should capture the dependencies once and use that to determine the scope of recompilation. Even if you have to visually inspect for inline calls, you only need capture this once. Using VADS, you can use pragma inline_only and the compiler will complain when it can't inline the call. This feedback is crucial to maintaining your dependency information when you capture it manually. > > This can't be an original problem. What do people with large Ada > projects do? Such things are important to your compiler selection. If you need to change compilers in the future, support for this problem area needs to be on your list. In any event, you use what the compiler will give you and build anything else you need to the degree that it is worth building. > > Ralph. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!"