comp.lang.ada
 help / color / mirror / Atom feed
From: jmills@ccrf-news.gatech.edu (John M. Mills)
Subject: Re: Multiple compilation-units (was: Re: GWU/ADA Interface)
Date: 7 Sep 1994 12:28:50 -0400
Date: 1994-09-07T12:28:50-04:00	[thread overview]
Message-ID: <34kpo2$11r@siberia.gatech.edu> (raw)
In-Reply-To: 347r7s$8nk@gnat.cs.nyu.edu

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



       reply	other threads:[~1994-09-07 16:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1994Sep1.122026.17797@sei.cmu.edu>
     [not found] ` <347b20$jf9@theopolis.orl.mmc.com>
     [not found]   ` <347r7s$8nk@gnat.cs.nyu.edu>
1994-09-07 16:28     ` John M. Mills [this message]
1994-09-09  1:46       ` Multiple compilation-units (was: Re: GWU/ADA Interface) Robert Dewar
1994-09-10 12:46       ` Jonathan AH Hogg
1994-09-10 15:22         ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox