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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4c019ad9cc913bbe X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-09-19 08:30:48 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: The Dreaded "Missing Subunits" Date: 19 Sep 2002 11:24:12 -0400 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: <1b585154.0209121449.ef12609@posting.google.com> <3D819EE7.3A69E5EB@praxis-cs.co.uk> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1032449669 17509 128.183.220.71 (19 Sep 2002 15:34:29 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 19 Sep 2002 15:34:29 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:29180 Date: 2002-09-19T15:34:29+00:00 List-Id: Robert A Duff writes: > Every time you tell the tool to re-analyze the world, it has to do this: > (1) Expand the wildcard(s), to see if there are any new files or any > files have been deleted. Then (2) check the timestamp on each source > file to see if it has been changed. Then it has to re-parse all the > files that have changed, or are new (and it has to forget about > information related to deleted files). This process is quite fast, even > for large programs. It's essentially what 'make' does when you say > 'make main_program', or what 'gnatmake' does when told to build a > program. > > (Actually, it also has to notice when the config file itself is > changed.) > > The point is: it doesn't have to reparse *all* the source code -- just > what has changed since last time, and it can detect those files quickly. > (Of course, the *first* time you run it, it has to parse *all* the > source code.) An Ada compiler could do likewise, but none do. > > > You said this would be "too slow"; which requirement do you really > > want? speed or naming convenience? > > I want both. ;-) > > I outlined above how to achieve it. Yes, using cached data. Sounds pretty good. > > It's faster if you cache the results of the name scan; gnatname > > does this. But as you say, the make system has to be able to > > determine when to rerun gnatname, or do it incrementally. > > > > One of the requirements of the GNAT design is the source-based > > "library"; there are no data structures required to run the compiler, > > other than the source files. Running gnatname automatically starts to > > violate this principle. > > The tool I mentioned above is entirely source based. Well, we could argue about that. You have to build the cache once before you realize the speed gain. The distinction I'm making is between "source based" as in GNAT, and "library based" as in DEC Ada 83. I suggest that your system is somewhere in between; there is a "library" that has knowledge about the compilation environment. It is lightweight compared to the DEC Ada 83 library, but it is more than plain GNAT requires. Although, even GNAT uses the existing .ali files to speed things up. I guess there are no "pure" systems :). > > ObjectAda takes a different approach; you have to manually tell it > > what files are in the compilation environment (at least, last time > > I used it; one reason I gave it up :). No possibility to > > automatically rescan for new files. > > I think ObjectAda allows you to use the "adareg" command to "register" > new Ada source files. It's similar to the gnatname idea. Ok, that makes sense. -- -- Stephe