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,53ca16c587912bce X-Google-Attributes: gid103376,public From: mfb@mbunix.mitre.org (Michael F Brenner) Subject: Re: Source files organisation using gnat Date: 1997/07/01 Message-ID: <5p9jci$eb9@top.mitre.org> X-Deja-AN: 253732489 References: <19970630185901.OAA27670@ladder02.news.aol.com> Summary: Yes, it is possible to organize the files under gnat Organization: The MITRE Corporation, Bedford Mass. Keywords: configuration control, gnat, organize files, batch Newsgroups: comp.lang.ada Date: 1997-07-01T00:00:00+00:00 List-Id: It takes some work, but it is possible to organize the files under gnat. Organizing the directory tree. Because of the design decision that gnat requires one compilation unit per file, much of the organization that the Ada language provides (that is, configuration management) is absent in gnat. Unfortunately, in the latest version, gnat 3.07DOS, there is also an incomplete design that it is not possible to put the sources in one set of directories and the objects in another set of directories. I have been told that this is still the case in the un*x release 3.10. Therefore, there are several approaches: (1) use an external configuration management tool to organize files together instead of releasing them in multi-unit files in multiple directories (2) make up a set of batch files (called shell files in un*x) which creatively type (called cat in un*x) the individualized files into combined files like we used to use (called *.chp files). Run gnatchop on these chp files, corresponding to each of your subdirectories. However, gnatchop in its current versions is severely limited as to howmany units it can take. THe kinds of batch files will have to micro-unchop and micro-chop things as follows: cat first_directory/a*.ad? > first_directory_a.chp cat first_directory/b*.ad? > first_directory_b.chp ... cat last_directory/z*.ad? > last_directory_z.chp Then to make the required gnat pseudo-library directory, use a bunch of batch macros like the following: rm library/*.* cd library gnatchop ../first_directory_a.chp ... gnatchop ../last_directory_z.chp (3) If you have multiple back ends, for example, substitutable device drivers, substitutable algorithms, or substitutable user interfaces, then you can use a set of gnatchops to implement them as follows. cd library gnatchop -w ../selected_device_driver_J.ch gnatchop -w ../selected_algorithm_M.hp gnatchop -w ../selected_ui_W4.chp rm main.o main.ali gnatmake -f -g -O3 -gnatn -gnato main mv main.exe ../executable_directory/J_M_W4.exe (4) In some future release when multiple directories for objects and sources are implemented then there are pragmas that permit selectable sources, but gnatinfo.txt warns that they are still limited to having the objects in the same directory as the sources for now. (5) Run a little Ada, awk, or perl program to take care of the minor issues of residual control-z characters in files, breaking large x.chp files down into gnatchop-able size pieces, deleting files with no extensions in un*x (equivalent to rm *. in DOS), and so forth. (6) In some release after 3.07 the problem of thinking the executable is up to date even though we have changed the files (and therefore the date-time-stamps) of the selectable back- and front-ends will be repaired. Possibly it is already fixed in 3.10. Then we will no longer need the -f parameter to force recompilation in the gnatmake command. In addition, it will not ask for a non-existent *.ads file for a procedure or function compilation unit. The -g parameter is needed to get the traceback from an exception handler when the program terminates (using gdb). The -O3 is the optimization parameter. The gnatn is the parameter that enable inlining of compilation units. The gnato checks for numeric overflow. If overflows do not affect your program then you can leave out the gnato parameter. (7) If you choose a commercial CM tool, there are several which track different versions of software, and can be programmed to create the gnat pseudo-library directory. (8) Now we really get creative. It is possible using the DOS subst command to have two simultaneous gnat pseudo-library directories! (Dr. James showed me this trick). Use the following commands: subst s: c:\ subst t: c:\ subst u: c:\ subst v: c:\ s: cd \util\gnat\bin t: cd \lib\ada\gnat\test u: cd \lib\ada\gnat\tools v: cd \util\gnat\lib\adalib path h:.;i:.;j:.;k:.;l:.;m:.;n:.;o:.;p:.;q:.;r:.;s:.;t:.;u:.;v:. loadhigh smartdrv.exe A- B- C+ /V 64000 loadhigh s:\cwsdpmi -p -sc:\tmp\cswdpmi.swp set TMPDIR=C:\tmp set GO32=2r1 set DJGPP-c:\util\gnat\djgpp.env set ada_include_path=s:..\adainc;t:.;u:.; set ada_objects_path=s:..\lib\adalib;t:.;u:.; copy s:ld.exe d: copy s:strip.exe d: copy s:cpp.exe d: copy s:stubify.exe d: copy s:gnatbl.exe d: copy s:cc1.exe d: copy s:as.exe d: copy s:gnat1.exe d: copy s:gcc.exe d: copy c:\util\misc\exitcode.exe d: copy c:\util\misc\gnatc.bat d: copy c:\util\misc\gnatb.bat d: In this case, the T: directory is the test directory and the u: directory is the production directory. You build the utility packages and the application in the u: directory, but you build the test applications in the t: directory. That way you can manage disk space by deleting the files in the t: directory after each main test program is built. When setting up gnatc.bat use gnatf, not gcc because a known bug prevents gcc from compiling in syntax only mode in the current release, but gnatf works fine as long as you only do a few compilation units at a time. It overflows on large numbers (say greater than about 50 compilation units). Of course, gnatc.bat is intended to copy the file to the pseudo library and do the gnatf, not acutally compile it! When setting up gnatb.bat to be invoked from your text editor, it is just a gnatmake, so it does the actual compile and linking. However, when you have library units that are procedures or functions it will not work without a manual override to delete the *.o and *.ali files file hand for these units. We are now almost ready to automate the whole process as follows. (a) first integrate the configuration management tool with your favorite text editor (microsoft word, bare bones edit, american cybernetics, emacs, M, pi, etc.) or you favorite gui (windowing system, graphical user interface generator, etc.) (b) now integrate that same text editor with gnat using the gnatc and gnatb batch files above (c) now put the above batch commands into autoexec.bat or better make a tognat.bat file that autoexec.bat will just call (d) write up a set of procedures how to check out files from the CM tool, update them, check them back in, and the CM tool will compile them (e) write up a set of procedures how to do a build, upon which command the CM tool will issue the gnatb batch file to compile and bind them. (f) now, before giving it to the users, run all the regression tests manually that were previously run at the bottom of each package in Ada-83. They are now separate executables. (g) Now, use your automated client-server testing tool to verify from your scenario libraries that all the x-windows strokes generated by your application are correct based on the test database and the requested dynamic similation run being tested. -- phew! (h) Now copy the executable onto the delivery media (jazz diskette, ftp file, etc.) and mark the configruation database to show all the service requests which this build fixed. You are under configuration control if you know where all your parts, changes to parts, and service requests instigating changes are. If there is even one executable you dont know what parts are in it, or you do not have those parts, then you are NOT under configuration control.