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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2a94e3d53d82207f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-09-07 22:52:15 PST Path: nntp.gmd.de!xlink.net!slsv6bt!slbh01.bln.sel.alcatel.de!rcvie!Austria.EU.net!EU.net!howland.reston.ans.net!gatech!gt-news!ccrf-news!ccrf-news!not-for-mail From: jmills@ccrf-news.gatech.edu (John M. Mills) Newsgroups: comp.lang.ada Subject: Re: Multiple compilation-units (was: Re: GWU/ADA Interface) Date: 7 Sep 1994 12:28:50 -0400 Organization: Georgia Tech Research Institute Message-ID: <34kpo2$11r@siberia.gatech.edu> References: <1994Sep1.122026.17797@sei.cmu.edu> <347b20$jf9@theopolis.orl.mmc.com> <347r7s$8nk@gnat.cs.nyu.edu> NNTP-Posting-Host: localhost.gatech.edu Date: 1994-09-07T12:28:50-04:00 List-Id: In article <347r7s$8nk@gnat.cs.nyu.edu>, Robert Dewar 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