Re: Pragma Inline and its Effects of Compilation Dependencies.

["Samuel T. Harris" <samuel_t_harris@Raytheon.com>]

Ralph Corderoy wrote:
> 
> Hi Samuel,
> 
> > This is a good area for ASIS based tools. I use just such a beast to
> > help resolve this issue.
> 
> Can you expand on that?
> 
> > 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.
> 
> It does, but the routines to be inlined are normally in separates, not
> the body, and due to the missing dependency they can be placed too
> late in the order.

I don't see why their being i separates presents a problem for
ASAP body order. The package body will be  placed in order as soon
as its extra supporters are in order. Assuming your separate has
no extra with clauses, then it will be placed immediately after
the parent body. Doing bodies ASAP means units dependent upon
the spec come after the body of the spec!

> 
> > > 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.
> 
> We might have access to ASIS but isn't that an interface to the DIANA
> standard intermediate format?  Are you suggesting building everything
> once, ignoring warnings about missed inline opportunities, and then use
> ASIS to poke around the library to find the dependencies?

Not all compiler use DIANA trees. ASIS is a standard way to query
the semantic nature of the program, regardless of its internal
representation. ASIS code should be very portable across
supported compilers.

What I am suggesting is using a tool to capture ALL the dependencies
(i.e. with clauses, generic bodies to their instantiations, pragma
inline bodies, anything else you need) before initial compilation.

However, as you point out, using the warning for failed inlines
as feedback is also a alternative course of action. Given a
"normal" dependency list, one can simply add more entries
based on the inline warning you get. The problem with this is
that you never know when you'll be done. Changes to code can
siginficantly change the base order and cause more inline
warnings. Your initial order may satisfy some inlining so these
won't be captured explicitly in your dependency list.

> 
> I've picked up a yacc grammar with lex parser from John Levine's
> archive (one minor bug in the lexer), and it spits out some parts
> easily enough.  Not sure if it is worth the hassle to add the necessary
> rename handling, etc., code;  it might be easier for the project to
> burn some man hours on maintaining the order manually over the next few
> years.

I gave up on this approach for any but the most basic stuff
years ago when I discovered ASIS. It is much more work to do
anything useful especially on a large project. ASIS is so much
easier, but does have its own learning curve.

> 
> > > 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.
> 
> This is a project that is getting on for a decade old;  all the
> hardware, OS, and compilers were specified years ago and we aren't
> allowed to change them now.  Yes, development is still ongoing ;-)  We
> could probably get away with an extra tool that worked out compilation
> order for us though.

There is a distinct difference between development compiler and
target compiler. Many project use the same compiler for both, but
we all must recognize that this does not need to be the case.
Say I use compiler X for development and target execution. Compiler
X does not provide an ASIS interface. I find that I need to write
some ASIS tools to do various things. I find compiler Y which
supports ASIS. I use compiler Y on the same source simply to
run the ASIS queries. If your doing Ada 95, GNAT is free and
fully supports ASIS.

> 
> Ralph.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"