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-18 17:00:53 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshosting.com!news-xfer1.atl.newshosting.com!uunet!dca.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: The Dreaded "Missing Subunits" Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Thu, 19 Sep 2002 00:00:07 GMT References: <1b585154.0209121449.ef12609@posting.google.com> <3D819EE7.3A69E5EB@praxis-cs.co.uk> NNTP-Posting-Host: shell01.theworld.com Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: Gnus v5.7/Emacs 20.7 Xref: archiver1.google.com comp.lang.ada:29142 Date: 2002-09-19T00:00:07+00:00 List-Id: Stephen Leake writes: > Robert A Duff writes: > > > Anyway, this all seems rather convoluted. Why can't the > > compiler/builder automatically determine which compilation units are in > > which files? Why is a separate tool needed? And a separate file of > > pragmas Source_File_Name to maintain? > > In order for the compiler to determine which compilation units are in > which files, it has to read all the files in the compilation > environment, build the list of file -> unit name mappings, and then > compile them. gnatname + gnatmake does this (caveat; I don't use > gnatname). No, it does not have to do all that every time you rebuild. I am writing a tool that analyzes Ada programs. It's not a compiler, but it has the same issues with respect to this discussion (how to find package Mumble when somebody says "with Mumble;"). I didn't want to build in the conventions of any particular Ada compiler. The solution I chose is that the user specifies a wildcard specification of which files constitute the "universe" (or the "program library"). So you might say "*.ada" or "*.ads and *.adb". Or you might mention several directories. You can tell the tool whatever conventions you use (presumably whatever your Ada compiler wants you to use). This is in some sort of config file. 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. > 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. > 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. > > Furthermore, none of this mumbo-jumbo would be necessary at all, if > > only all Ada compilers agreed on the file naming convention. > > Doesn't seem likely, especially now. True. I'm just griping -- not expecting any improvement. ;-) > > (I must admit, that wasn't easy in the days when operating systems > > had unreasonable limits on file names (like only one dot, or only 8 > > characters). Are those bad-old-days over?) > > I hope they are over. But we are stuck with their legacy; all of the > GNAT compiler source files are krunched to 8.3 names. Yeah, I find that annoying. > > I also admit that C has it easy in this regard, since it has no > > proper notion of "module" separate from source file. > > That is part of the problem. > > -- > -- Stephe - Bob