Re: Source files organisation using gnat

[mfb@mbunix.mitre.org (Michael F Brenner)]

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.