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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4fe4dfa1b8acdbe4 X-Google-Attributes: gid103376,public From: "David C. Hoos, Sr." Subject: Re: gnat310p on NT Date: 1998/08/15 Message-ID: #1/1 X-Deja-AN: 381396540 References: <01bdc744$cef04bc0$0e2915c0@w95> <0QXRrq2x9GA.123@samson.airnet.net> <01bdc7e9$195db180$0f2915c0@wnt> Newsgroups: comp.lang.ada X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Date: 1998-08-15T00:00:00+00:00 List-Id: bob wrote in message <01bdc7e9$195db180$0f2915c0@wnt>... >I used to be as fervent about this as you, but about 7 years ago I was >called in to find out why a large system took 6.5 hours to compile. This >was a near production system so I didn't have the option to rewrite it. >After some experimenting, we found that if we pullied all of the separates >back into their parent packages, the compilation time fell to 1.2 hours. >Apparently the time to open and close files is a significant percentage of >compilation time. So now I advocate separates during development, but merge >them as they become completed (through thourough testing). The reduced >number of files to manage also helps out the SCM and T&E people. >In addition we found that the Verdix debugger frequently loses track of >symbol tables when crossing into and out of separates. > Well, I have to admit that Verdix (with which I have many years of unhappy experience) does have the problems you describe. But this is more a function of the "heavy" library model used by many Ada83 copilers. Remeb\mber that Verdix opens at least four (and sometimes many more) files for every source file. Gnat, on the other hand will write only one object file and one .ali file when compiling a package body, regardless of whether the source is all in one file or in separate units. There is a certain sense in which the Gnat compilation model might at first seem less efficient because "separates" are not (cannot be) compiled separately at all, but the code of separates is "included" in the compilation stream of its parent unit. The beauty of the Gnat compilation model is that no compilation order is imposed, from which it follows that (unlike Verdix, et. al.) it is impossible to invalidate compilations by the recompilation of a unit on which other iunits depend. Our experience is that not only does Gnat compile faster from the start, but that far fewer recompilations are needed with gant, given the same source code change sequences. >I downloaded the source and will do as you suggest. If I can find "Martins" >address, will send him everything I do. Martins address is on the Help->About box of AdaGIDE -- mcc@cs.usafa.af.mil > I do have access to the source for >a debugger which works very much like the VC++ debugger. Will try inserting >it. Also will try inserting option of selecting editor of users choice (and >whatever else comes to mind, time permitting). Have you tried the gdb-tcl/tk debugger for gnat NT? It's at: ftp://ftp.cs.nyu.edu/pub/gnat/winnt/gdb-3.10p-nt.exe As far as IDEs for gnat are concerned, AdaGIDE suffers from one limitation -- i.e., it is only for the Win32 platform. There are two Gnat-aware IDEs which are available for UNIX as well as Win32 platforms, viz.: Grasp (Graphical Representations of Algorithms, Structures and Processes) available at: http://www.eng.auburn.edu/department/cse/research/grasp/grasp.html and Emacs with ada-mode Beside the cross-platform advantages, these two also provide additional and unique capabilities, but while working on Win32 I use AdaGIDE for the bulk of my work, it's always good to have a variety of tools in one's "toolbox." I advise checking them out. David C. Hoos, Sr.