Re: Multiple compilation-units (was: Re: GWU/ADA Interface)

Re: Multiple compilation-units (was: Re: GWU/ADA Interface)

[John M. Mills]

In article <347r7s$8nk@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:

[..]

>Any suggestions for simple features for utilities like this are certainly
>welcome (as is the contribution of useful utilities :-)

Well, I haven't got as far as suggestions, and these comments may belabor
the obvious, but in case they stimulate some ideas ...

I expect that some of the recent thread on GNATCHOP arises from
the fundamentally different ways that Ada libraries and UNIX 'make' determine
library currency.  To establish required compilations, I understand that
the Ada library manager (or equivalent) checks compilation timestamps on
specs, whereas 'make' assumes that the determinant is the source-file's
"touch" stamp.  There is a basic conceptual split here, and GNAT seems
to be standing on the crack.  Naturally if you need to determine library
currency from package names, and don't know the names of packages from the
names of the source files, you need to do some processing to decide what's
current.  Since differently named Ada sources commonly provide specialized
versions of a particular package, identifying content (i.e., package name)
with source name breaks many programmers' approach to source organization.

Stepping back towards UNIX a bit ('make' is not only usable for 'C'
code libraries), I see some alternative attempts, not wholly successful.
I have used 'imake' and 'make depend' a bit, and find them hairy for a
novice.  It's not for nothing that DuBois' [excellent] book on 'imake'
has a Boa or Python on the cover!  _But_ my main complaint with imake
is really with the broken 'X' directory structures inherited with OpenLook
and OSF/Motif.  Basically, 'imake's objectives of improved portability,
dependency generation, and automatic 'lint' invocation are worthwhile.
Could a 'make depend'-like function be built which works with GNAT libraries?
Maybe this effectively exists, but I didn't get that impression from the
thread.  Could a set of 'imake' templates and rules be built to manage GNAT
builds?

Any comments?

Regards --john--

-- 
John M. Mills, SRE -- john.m.mills@gtri.gatech.edu -- (404)528-3258 (voice)
   Georgia Tech/ GTRI/ SDL, 7220 Richardson Rd., Smyrna, GA 30080
   "Well, I'm an Assistant Regurgitation Engineer --
     but I should make Senior R.E. next year" _The_Far_Side_, G. Larson

Re: Multiple compilation-units (was: Re: GWU/ADA Interface)

[Robert Dewar]

John, you have a misconception, the time of compilation plays no role whatsoever
in the GNAT system. The time stamps are the time stamps of the sources.

Re: Multiple compilation-units (was: Re: GWU/ADA Interface)

[Jonathan AH Hogg]

On 7 Sep 1994, John M. Mills wrote:

> Could a 'make depend'-like function be built which works with GNAT libraries?
> Maybe this effectively exists, but I didn't get that impression from the
> thread.  Could a set of 'imake' templates and rules be built to manage GNAT
> builds?
> 
> Any comments?

i have written a zsh script to generate a list of dependancies for a gnat 
closure when pointed at the base unit. it is not too difficult to do as 
gnat will provide a list of dependancies for a unit on demand with the 
'u' option. parsing this output (here's where it gets hairy) allows you 
to build the dependancies.

i can make this available to anyone who is interested (though you'll have 
to port it if you don't have zsh).

imake is still way beyond me though. i guess i'll have to read the book 
sometime.

jonathan

-- 
Jonathan AH Hogg, Computing Science Department, The University, Glasgow G12 8QQ 
jonathan@dcs.gla.ac.uk | http://www.dcs.gla.ac.uk/~jonathan | (+44|0)41 3304454
MIME, Mailtool, Eudora, MS-Mail, and POP-Mail attachments welcome | MY opinions

Re: Multiple compilation-units (was: Re: GWU/ADA Interface)

[Robert Dewar]

Jonothan mentions that he has built a utility which uses the unit listing
from GNAT to generate dependencies. Much better is using the ALI files.
The D lines in the ALI files are EXACTLY the list of source file 
dependencies. That's how we generate dependencies.

Much better than either approach is an Ada make utility that calculates
the dependencies dynamically as it goes along. We are working on such a
utility and hope to have it available soon.

Jonathan, I think you would find it *much* easier to parse the ALI files!

Robert