Re: Pragma Inline and its Effects of Compilation Dependencies.

[ralph@inputplus.demon.co.uk (Ralph Corderoy)]

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.

> > 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?

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.

> > 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.


Ralph.