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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,91d0d8cd28bbb477 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!e65g2000hsc.googlegroups.com!not-for-mail From: Lucretia Newsgroups: comp.lang.ada Subject: Re: Implementing an Ada compiler and libraries. Date: 11 May 2007 15:41:35 -0700 Organization: http://groups.google.com Message-ID: <1178923295.678315.237810@e65g2000hsc.googlegroups.com> References: <1178721451.073700.10730@y80g2000hsf.googlegroups.com> <6819scxft9y4$.1vlh83ppnnyrh$.dlg@40tude.net> <1178731280.075981.23040@u30g2000hsc.googlegroups.com> <8cu67r7wcdn7$.18rtn6g7506w2$.dlg@40tude.net> <1178818792.829214.95870@q75g2000hsh.googlegroups.com> <1178820387.916393.238070@y80g2000hsf.googlegroups.com> <4644179d$1_5@news.bluewin.ch> <1178905186.012787.167150@y80g2000hsf.googlegroups.com> <1178905389.489947.61760@o5g2000hsb.googlegroups.com> <1178909398.745971.215770@o5g2000hsb.googlegroups.com> NNTP-Posting-Host: 62.56.75.195 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1178923296 1615 127.0.0.1 (11 May 2007 22:41:36 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 11 May 2007 22:41:36 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Opera/9.10 (X11; Linux i686; U; en),gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: e65g2000hsc.googlegroups.com; posting-host=62.56.75.195; posting-account=G-J9fgwAAADgpzBiEyy5tO4f8MX5fbpw Xref: g2news1.google.com comp.lang.ada:15775 Date: 2007-05-11T15:41:35-07:00 List-Id: On May 11, 11:06 pm, Robert A Duff wrote: > Lucretia writes: > > True, but how would a compiler that didn't impose limits (are there > > any?) manage to find compilation units with'd? > > Here's one way: > > I presume the way one invokes the compiler is via a "build" tool of some > sort (something like gnatmake or adabuild). > > Keep a data structure that tells which compilation units are in which > source files. Whenever the build tool is invoked, it first parses all > the files that changed since last time, and updates this data structure. > If any files are new, they need to be parsed. If any files have been > deleted, all information about them in the data structure should be > deleted. You can store this data structure on disk, if you like. So, essentially you're saying create a project file which lists which compilation units are in which files then the build tool will know where they are? > At this point, give an error if there are duplicate names (unless the > user has explicitly requested that one should override the other). > > Now you have all the information you need to run the rest of the > compiler phases (after parsing) on everything in the right order > (or partially in parallel). > > I know this method can be implemented efficiently, because I've done it > several times (not for Ada compilers, but for other language processing > tools (Ada and non-Ada)). > > >... At least with GNAT it > > uses package name => filename, so that's easy to implement, but with > > multiple compilation units per file, it's much more tricky. I've > > basically thought the only way to partially do it is to compile the > > source into a parse tree, then traverse it to generate the AST, > > Generate the AST from the parse tree? I normally generate the syntax > tree directly during parsing. Well, I was thinking that as you didn't know which compilation units were in which files, then building a tree without checking, you can then parse the tree and when you hit a "with" node, you then start looking for other compilation units. Just a thought ;D Thanks, Luke.