Source files organisation using gnat

Source files organisation using gnat

[Laurentau]

Hello.

I am a very beginer to gnat. I used Alsys (now Aonix) at work. It uses a
library concept. So, I am used to work this way: our sources are in an
Unix tree with several levels.

When I had a look at gnat, the first thing that I saw was... a lot of
files in the same directory (adainclude). I don't know how to say without
hurting people but if I program this way at work, I may get beaten to
death by my quality manager ;-)

Can someone tell me how they organized there development tree ?

Thanks in advance.

L. Aufrechter

Re: Source files organisation using gnat

[Robert Dewar]

Laurentau said

<<Can someone tell me how they organized there development tree ?>>

If you are asking how ACT organizes its work, you need to realize that
adainclude is the runtime library of GNAT. It consists of hundreds of
routines that are essentially all at the same level, these routines
can be accessed from compiler generated code. There is no "tree"
structure here, it is fundamentally a flat collection of entities,
much as the callable entities in the C library are a flat collection
of entities.

Re: Source files organisation using gnat

[Robert Dewar]

Laurentau said

<<When I had a look at gnat, the first thing that I saw was... a lot of
files in the same directory (adainclude). I don't know how to say without
hurting people but if I program this way at work, I may get beaten to
death by my quality manager ;-)
>>


Try reading the section in the users guide on the compilation model.

The whole point is that "a lot of files in the same directory" *is*
the GNAT representation of what you are used to Alsys representing in
one huge file. Note that this is not actually so much about compilation
models, the issue of whether to use one huge file or multiple small
files to represent a library is a perfectly legitimate design dichotomy
even in compilers that use a conventional Ada 83 model -- many Ada 83
compilers used multiple files to represent a library.

Try to forget everything you learned about Alsys libraries, (note that
you are talking about the old Alsys compiler, the new Aonix compiler
uses a very similar approach to the one used by GNAT -- why? because
the designers of the Aonix front end looked at GNAT, and liked what 
they saw!

If your quality control manager has a fixed idea that one big file is
better than a directory containing many small files, I don't know
quite what to say. I guess you should keep him out of the way of
most C, C++, and Fortran programmers in the world, or there will
be a blood-bath :-)

Seriously, the best way to think about the way GNAT works is to think
of the compilation model as being similar to that used by nearly all
other languages *before* Ada 83 compilers started using black box
libraries.

Re: Source files organisation using gnat

[Samuel T. Harris]

On the fact of it, I have to agree with Laurentau here.
Our working environment includes over 200 engineers working
on one project, a very HUGE project. We simply cannot work
within a single directory. In fact, most groups of 12-20 engineers
cannot work within a singlular directory organization. This
is nothing to do at all with Ada library organization. It is
simply the realities of working with more an a small number
of programmers.

However, development and distribution are two very different
things. Organizing the development environment, one is concerned
with who is doing what to which components and how the programmers
interact with each other. For distribution, one is concerned
with making the act of installation as simply as possible for the
end user. From my experience, it is common to "collapse" a large
and involved directory structure which supports development into
a single or simple directory structure for distribution.

The kicker with GNAT is that the sources are frequenly needed
by the programmer which put us back in the development arena.
Here in is the conflict. But is easily resolved with a good
Ada editor which allows easy navigation from one's own code
to the appropriate GNAT source it refers to. Apex does this
very well. Emacs with the Ada stuff works too. And then there
is David Wheeler's ada2html for the rest of us. Perhaps ACT
could be persuaded to run the GNAT sources through ada2html
and make that available in parallel with the binaries and
source. I suppose that shouldn't involve to much extra work.
My point is that with reasonable development support tools,
the organization of distributed code becomes moot.

Robert Dewar wrote:
> 
> Laurentau said
> 
> <<When I had a look at gnat, the first thing that I saw was... a lot of
> files in the same directory (adainclude). I don't know how to say without
> hurting people but if I program this way at work, I may get beaten to
> death by my quality manager ;-)
> >>
> 
> Try reading the section in the users guide on the compilation model.
> 
> The whole point is that "a lot of files in the same directory" *is*
> the GNAT representation of what you are used to Alsys representing in
> one huge file. Note that this is not actually so much about compilation
> models, the issue of whether to use one huge file or multiple small
> files to represent a library is a perfectly legitimate design dichotomy
> even in compilers that use a conventional Ada 83 model -- many Ada 83
> compilers used multiple files to represent a library.
> 
> Try to forget everything you learned about Alsys libraries, (note that
> you are talking about the old Alsys compiler, the new Aonix compiler
> uses a very similar approach to the one used by GNAT -- why? because
> the designers of the Aonix front end looked at GNAT, and liked what
> they saw!
> 
> If your quality control manager has a fixed idea that one big file is
> better than a directory containing many small files, I don't know
> quite what to say. I guess you should keep him out of the way of
> most C, C++, and Fortran programmers in the world, or there will
> be a blood-bath :-)
> 
> Seriously, the best way to think about the way GNAT works is to think
> of the compilation model as being similar to that used by nearly all
> other languages *before* Ada 83 compilers started using black box
> libraries.

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: Source files organisation using gnat

[Robert Dewar]

Samuel Harris says

<<On the fact of it, I have to agree with Laurentau here.
  Our working environment includes over 200 engineers working
  on one project, a very HUGE project. We simply cannot work
  within a single directory. In fact, most groups of 12-20 engineers
  cannot work within a singlular directory organization. This
  is nothing to do at all with Ada library organization. It is
  simply the realities of working with more an a small number
  of programmers.>>

Goodness, of *course* one does not expect a large development
project to use a single directory, absolutely not. One of the
advantages of the GNAT source based approach is precisely
that you can conveniently use a typical hierarchical directory
structure to arrange your sources.

<<The kicker with GNAT is that the sources are frequenly needed
  by the programmer which put us back in the development arena.>>

I am a little surprised by this statement. It seems like the only
sources in this category are the gnat.* units, which is a small
set of units, not often used. For these, I agree, an HTML version
is a good idea.

For the Ada units, I would think that an HTML version of the
reference manual is a much better source of information than
looking at the GNAT sources.

In any case, if you *do* want to look at any of the GNAT sources
in gnatlib, it is *much* more convenient that they are in a single
flat space, since you would always be searching by name in any case.

Re: Source files organisation using gnat

[Michael Feldman]

In article <dewar.868073014@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

[snip]
>
>For the Ada units, I would think that an HTML version of the
>reference manual is a much better source of information than
>looking at the GNAT sources.
>
>In any case, if you *do* want to look at any of the GNAT sources
>in gnatlib, it is *much* more convenient that they are in a single
>flat space, since you would always be searching by name in any case.
>

For an example of HTML linking of the Ada 95 library interfaces, and
a number of others including the GNAT runtime interfaces, etc., see

http://www.seas.gwu.edu/ada 

and click on "Hypertext-Linked Ada 95 Libraries"

Note that the all-GNAT source code for the tool that does the
linking is available from the address given in that page. You
simply turn the tool loose on a directory containing a bunch of 
.ads files, and stand back. (Yes, they must be in a single directory.)  

This tool links up only package _interfaces_, since the goal is
to help _users_ of sets of packages, not maintainers thereof.
It would be more than trivial but less than horribly difficult
to link bodies as well.

Michael Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) 
http://www.seas.gwu.edu/faculty/mfeldman
------------------------------------------------------------------------
"Cooperate with those who have both know-how and integrity."      
   Fortune cookie, Wu Dynasty, Bethesda, MD, Spring 1996.
------------------------------------------------------------------------
Ada on WWW: http://www.acm.org/sigada/education or http://www.adahome.com 
------------------------------------------------------------------------

Re: Source files organisation using gnat

[David Haslam]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
: Laurentau said

: <<When I had a look at gnat, the first thing that I saw was... a lot of
: files in the same directory (adainclude). I don't know how to say without
: hurting people but if I program this way at work, I may get beaten to
: death by my quality manager ;-)
: >>


: Try reading the section in the users guide on the compilation model.

: The whole point is that "a lot of files in the same directory" *is*
: the GNAT representation of what you are used to Alsys representing in
: one huge file. Note that this is not actually so much about compilation
: models, the issue of whether to use one huge file or multiple small
: ...

I understood the original poster as being concerned with the source
file organisation rather than library issues. The ada subdirectory
under the gcc source tree contains about a 1000 source files. Certainly I
would never organise a large project with a flat structure like this, I 
would want a directory hierarchy. I'm sure I'm not alone in this.

: files to represent a library is a perfectly legitimate design dichotomy
: even in compilers that use a conventional Ada 83 model -- many Ada 83
: compilers used multiple files to represent a library.

: If your quality control manager has a fixed idea that one big file is
: better than a directory containing many small files, I don't know

I don't think that is the problem, it is having lots of source files
in one directory that is objectionable.

--
David Haslam                                 Work: David.Haslam@gecm.com
GEC-Marconi Radar and Defence Systems       Home: dch@sirius.demon.co.uk
Simulation and Training Division    

Re: Source files organisation using gnat

[Robert Dewar]

iDavid Haslam said

<<I understood the original poster as being concerned with the source
file organisation rather than library issues. The ada subdirectory
under the gcc source tree contains about a 1000 source files. Certainly I
would never organise a large project with a flat structure like this, I
would want a directory hierarchy. I'm sure I'm not alone in this.
>>

Hierarchies are not a good thing of themselves, they are helpful only
if they clarify structure. In this case we have hundreds of units that
the programmer can select from since it is the runtime library. I think
you will find many flat structures like this in API contexts. If you
have a Windows interface with several hundred calls, it is often quite
*unhelpful* to try to arrange the calls into hierarchical stuctures.

To me, the suggestion that adainclude be organized into a hierarchy
sounds like a huge pain in the neck.

So far, the objections have been formalistic "everyone knows that
flat structures this big are a *BAD THING*)"  (reminds me of
"everyone knows gotos are bad" etc.)

What would be far more helpful than these general philosophical
observations would be a very specific suggestion:

"I think adainclude should be organized like this, and here is why I
 think that, and here is the advantage of this reorganization."

Note that it is not an advantage to have more directories with fewer
files. Such an organization may or may not be better for a given purpose.

One suggestion some people have is to organize directories according to
the child unit hierarchy. That's superficially appealling, but in practice
is not at all a good idea (if you think it is a good idea, try stating
exactly why, from the point of someone using GNAT).

As another example of a large flat structure, suppose that, as on my Mac
when I was using it, you have a thousand fonts. They are all separate fonts,
there is no particular relation between any one font and any other. I
really don't see any objection to a flat structure in this case. Trying
to group fonts by function sounds useful, but in fact ends up being a pain,
because now you end up thinking:

"Where on earth did I put Adobe Garamond? was it under classic fonts? or
 new postscript fonts? or textbook fonts? ...."

Since (at least in my environment) I almost always want to fetch fonts
by name, any hierarchical arrngement gets in the way.

Of course the best arrangement depends on the expected usage. The
purpose of the adainclude directory is to provide runtime routines to
an Ada program, that are *always* fetched by name.

Now if on the other hand you want to browse the specs of the GNAT routines,
as a kind of not very well organized online RM Annex A, then the arrangement
is definitely NOT ideal, but that is not what adainclude is for!

Re: Source files organisation using gnat

[Robert I. Eachus]

In article <dewar.867959470@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

 > Now if on the other hand you want to browse the specs of the GNAT routines,
 > as a kind of not very well organized online RM Annex A, then the arrangement
 > is definitely NOT ideal, but that is not what adainclude is for!

   Hmmm.  Sounds like a good idea!  An HTML page that makes it easier
to find the "right" package specification for those occasions when you
need to check the implementation dependent parts would be very useful.
Of course, being a glutton for punishment, I want to write a cgi-bin
program (in Ada of course) that makes the with clauses into links,
color codes reserved words and comments, etc.

   Maybe later this week...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Source files organisation using gnat

[Steve Doiel]

In article <dewar.867707107@merv>, dewar@merv.cs.nyu.edu says...
>
>Try reading the section in the users guide on the compilation model.
>
[snip]

I'm suprised you didn't mention gnatchop, Robert.  From what I understand
if you wants to keep all of their sources in a single file... no problem.  It
just adds a couple of steps to building (i.e. running gnatchop first).

Steve Doiel

Re: Source files organisation using gnat

[Robert Dewar]

Steve said

<<I'm suprised you didn't mention gnatchop, Robert.  From what I understand
if you wants to keep all of their sources in a single file... no problem.  It
just adds a couple of steps to building (i.e. running gnatchop first).
>>

Indeed, gnatchop can be used if you want to keep your units stored with
more than one unit per file -- once again, I note that this generally
seems a bad idea.

The error messages and debug information will refer to the original 
file if you like.

As I mentioned in my earlier messages, if you like you can *exactly*
duplicate the precise semantics of a typical Ada 83 library based
system (not sure why anyone would want to do this!)

Re: Source files organisation using gnat

[Michel Gauthier]

In article <dewar.867990043@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>> [...]
>>  
>>  As I mentioned in my earlier messages, if you like you can *exactly*
>>  duplicate the precise semantics of a typical Ada 83 library based
>>  system (not sure why anyone would want to do this!)

Thanks in advance to anybody who can explain me how I could 
know immediately (as simply as a "ls *.o" command) what generic
specifications or bodies are correctly compiled, what non-generic 
bodyless specifications are correctly compiled. 

Please include scripts, if any.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone + 33 5 55 43 69 73
fax +33 5 55 43 69 77
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------

Re: Source files organisation using gnat

[Robert Dewar]

Michel says

<<Thanks in advance to anybody who can explain me how I could
know immediately (as simply as a "ls *.o" command) what generic
specifications or bodies are correctly compiled, what non-generic
bodyless specifications are correctly compiled.
>>

Of course now we are not talking about Ada 83 vs Ada 95, or about library
model vs source model. This is not a language issue at all, just an issue
of what tools are available.

In fact this kind of information is certainly useful, and GNAT 3.10 has
a new tool gnatls tha is designed to provide exactly this kind of
information in a convenient form.

Robert Dewar
Ada Core Technologies

Re: Source files organisation using gnat

[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.

Re: Source files organisation using gnat

[Robert Dewar]

Michael Brenner says

<<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
>>


First, the idea that "configuration management" is present in the Ada
language at all is pretty thin, as previously discused in detail on CLA.

Second, the idea that this CM relies on having multiple compilation units
per file is even thinner:

  (a) The Ada language has never required multiple compilation units per file.
      In fact it has nothing to say at all about files and source 
      representation issues.

  (b) Most Ada style guidelines, including AQ&S, advise in any case the
      style of one compilation unit per file (to do otherwise underrmines
      the intent of the independent compialtion design in Ada).

Third, it is perfectly easy to set up appropriate scripts to deal with
multiple compilation units per file if that is what you really want. 
Error messages and debugging information can refer to the original file
in this case. We do this e.g. with the ACVC suite, but very rarely 
otherwise, since our style guidelines, like AQ&S, require one unit per file.

Finally, the idea that you cannot have souces in one set of directories
and objects in another is completely wrong. This is a normal setup used
by us and by many others for a long long time.

Robert Dewar
Ada Core Technologies

P.S. it is true that the use of a classical Ada 83 library system gives
some kind of very thin CM-related help, but that has nothing at all to
do with multiple units per file. If you want to duplicate this semantics
with GNAT it is pretty easy to do so (Jean-Pierre Rosen has a little
set of scripts that duplicate the effect of an Ada 83 library, it is
pretty easy to do). But in practice this is not of much interest, because
it makes better sense to design precisely the setup of directories and
"library" handling that you want. Most GNAT users do not want something
that duplicates Ada 83 semantics (including for examle the requirement
that compilations be done in the "right" order).

Re: Source files organisation using gnat

[Wes Groleau]

>       (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.

 the concept of having each package do its own regression tests
as part of elaboration has merit in some circumstances.  However, 
it is not a part of many standard development processes.  So it is 
misleading to offer this step as if it were a necessary part of 
organizing source files into various directories (which is what 
the original question was about)

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Source files organisation using gnat

[Michael F Brenner]

Mike said:
       (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.

Wes said:
 the concept of having each package do its own regression tests
as part of elaboration has merit in some circumstances.  However,
it is not a part of many standard development processes.  So it is
misleading to offer this step as if it were a necessary part of
organizing source files into various directories (which is what
the original question was about)


Mike responds:
  If a standard development process does not have packages do their
  own regression test, then that standard development process should
  state where the regression tests are done instead. A development
  process without regression testing is incomplete. The benefit of
  the automated regression tests, during the period when they were
  possible, was that the process was automated, and therefore
  cheaper. You could tell with a quick search if the package
  body ended with the statements: BEGIN REGRESSION_TEST; END
  which automated quality checking of regression test occurrences
  (although you still had to manually check the DEPTH of the 
  regression test, to make sure it verified that each required
  change still works). This is in accord with the original
  post and the original answer to the post that some of the
  configuration management features well used in Ada are
  either not universally possible anymore, or are not considered
  as important as they are. When a language feature automates
  a good programming practice, that is good (and economical).

Re: Source files organisation using gnat

[Geert Bosch]

Laurentau <laurentau@aol.com> wrote:
   Can someone tell me how they organized there development tree ?

Put the sources in the directories you want them to be in and
set the ADA_INCLUDE_PATH to include those directories. For more
information read the documentation.

Regards,
   Geert

Source files organisation using gnat: more...

[Laurentau]

Hello.

I am afraid the answers are not compatible with my constraints: about 3000
files and a lot of lines of code in ;-).

Of course, the Unix grep command does not work in this context:
grep a_symbol *
I get something like:
Are you crazy ? There are too much files in that ### directory !

I agree this can work on a medium size project but even using variables is
not a good solution for me. 1000 directories is not compatible with
variables...

Thanks for usable solutions...

L. Aufrechter

Re: Source files organisation using gnat: more...

[Robert B. Love]

In <19970702184001.OAA25612@ladder01.news.aol.com> Laurentau wrote:
> Hello.
> 
> I am afraid the answers are not compatible with my constraints: about 
3000
> files and a lot of lines of code in ;-).

First, there is a perl recursive grep you might try.  Second what 
about the GNAT cross reference?  If you compile all the files with the
right option, doesn't it build a location tree?  Yes, it would take
a lot of time and yes, you'd have to visit many directories but
you're going to have to compile them all anyway, right?

----------------------------------------------------------------
 Bob Love                                   MIME & NeXT Mail OK
 rlove@neosoft.com                            PGP key available
----------------------------------------------------------------

Re: Source files organisation using gnat: more...

[nasser]

In article <5penf5$m75$1@uuneo.neosoft.com>, rlove@antispam.neosoft.com says...

>First, there is a perl recursive grep you might try.  

is this perl script something more than I can do just by typing:

% grep "pattern" `find . -name "*.adb" -print`

or

%find . -name "*.adb" -print | xargs grep -i "pattern"

etc.. I am sure there are other ways to do recusrive greps.


Nasser

Re: Source files organisation using gnat: more...

[Ian Caldwell]

Laurentau wrote:
> 
> Hello.
One solution is to to use gnatchop to 'load' your source files into the
GNAT library. 

In this case the pre choped files are your sources and the choped file
are treated as just internal to the compilation system.

When a file needs changing the pre choped file is edited and re-choped.

This allow source files (incluing multiple compilation units files) to
be stored  in anyway you chose.

Ian Caldwell.

Re: Source files organisation using gnat: more...

[Michael F Brenner]

    > 3000 files is too many to use un*x tools

There are several alternatives. One is to increase your shell
size to permit 3000 files in the command line expansion, it is
a variable length character string. Two is to use the FIND command.
Three is to use a separate configuration management tool. Etc.

Re: Source files organisation using gnat

[Michel Gauthier]

In article <19970630185901.OAA27670@ladder02.news.aol.com>,
laurentau@aol.com (Laurentau) wrote:

>>  I am a very beginer to gnat. I used Alsys (now Aonix) at work. It uses a
>>  library concept. So, I am used to work this way: our sources are in an
>>  Unix tree with several levels.
>>  
>>  When I had a look at gnat, the first thing that I saw was... a lot of
>>  files in the same directory (adainclude). I don't know how to say without
>>  hurting people but if I program this way at work, I may get beaten to
>>  death by my quality manager ;-)
>>  
>>  Can someone tell me how they organized there development tree ?

I agree that keeping a big number of files require organising them, which is
generally obtained by use of directories. 

I guess that a library structure could have been a better solution than
throwing Ada into the same melting pot as other languages. The gnat
choice wastes much time of useless recompilations, that would have
been left aside with more information kept instead of rebuilt.

However, it is no longer the question. How can we deal now with both
a gnat compiler and a tree structure of the sef of source files ?
  Our solution was to use the shell variables that define sets of paths.
Gnat uses some of them to indicate where the sources, and other files,
can be found (I do not have the detail in mind, look at the documentation).

In practice, each of our directories with Ada sources contain a suitable
'a9path' file, which is a script of 'a9pend directory' commands
which establish the shell variables with their parameter, in a 
transitive manner. This a9path is built as part of the directory initialisation
process. After that, two suitable commands replace the gcc and gnatmake
with analogous commands using the local library dependencies.

This has been used all last year by 50 students without any problem,
including after the designer has gone away to another job.

I am neither fluent in unix shells nor the creator of these scripts,
but I can search for them if they can be useful for somebody.

Any comment appreciated.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone + 33 5 55 43 69 73
fax +33 5 55 43 69 77
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------

Re: Source files organisation using gnat

[Robert Dewar]

Michel says

<<I guess that a library structure could have been a better solution than
throwing Ada into the same melting pot as other languages. The gnat
choice wastes much time of useless recompilations, that would have
been left aside with more information kept instead of rebuilt.
>>

People often guess this, but that is all it is, a guess! And in fact
it is almost certainly an incorrect guess. The advantage of the source
model, which you may note is also adopted by the AdaMagic front ends,
is that you do not have to write the tree when you do a compilation,
this definitely saves time, since the tree structures are big (Ada 83
libraries could quickly get very large).

As to "useless recompilations", actually nothing is uselessly recompiled.
The internal semantic tree of withed units is reconstructed from source,
but this is nothing like a full compilation, since the expensive part,
namely code generation is always skipped for with'ed units.

The question of whether to save information rather than recompute it is
a rather general one. You definitely cannot assume that it is always
more efficient to save than to recompute. 

There are certainly several approaches for significantly increasing
GNAT compilation speed by a large factor, but none of these involve
writing libraries. So far, speeding up compilation has been a lower
priority task. As the compiler gets into more solid shape, we can
spend more resources speeding up the performance of the generated code,
the runtime, and the compiler itself. But don't look for us to switch
to a library model, since this would actually *slow down* compilation,
and this is even more true when some of the speed ups we do plan get
done. 

In particular, the reading of with'ed files is a front end activity,
and so far the distributed versions of GNAT have been the full debugging
versions, with all sorts of very inefficient assertions around (just
take a look at the sources and grep for assert :-)

Now that the front end is pretty stable, we are experimenting to see if
it is time to generate the originally planned fast inlined version of the
front end. We are not sure that this will be a feature of the forthcoming
3.10 release, but it maybe, and if not it certainly will be in the 
subsequent release.

Actually most people who have run into slow compilation times in GNAt
are dealing with cases where the GCC back end is slow., and the issue
of library vs recreating from source is of course entirely irrelevant
to such problems.

For most, but not all, users, the compilation performance of GNAT, even
with the full assertions on, is acceptable. Certainly that is the way
I always run, and it takes me 13 minutes to compile the GNAT sources,
and under 5 minutes to recompile the GNAT library (nearly 300 units),
and that's fast enough that I don't bother to build the fast compiler yet.

Re: Source files organisation using gnat

[Geert Bosch]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
   As to "useless recompilations", actually nothing is uselessly recompiled.
   The internal semantic tree of withed units is reconstructed from source,
   but this is nothing like a full compilation, since the expensive part,
   namely code generation is always skipped for with'ed units.

However many source files are uselessly parsed into a semantic
tree.  When you have a program that uses a large binding, like the
1.2 MB OS/2 API package specifications I use, these will get read
and parsed for every single compilation unit that withs it. The
time spend in parsing these packages specs (8 seconds on my 486DX-100)
tends to be much longer than the actual compilation time. 

The flat nature of these API specifications do lead to big packages,
since splitting them in a hierarchical structure is not meaningful
as you argued a while ago.

So what might be useful is to have some kind of compilation server
that can keep state between compilations and re-use internal datastructures
like parse trees. Of course in that case you may have to worry about
memory management and for example restart the server periodically.

Regards,
   Geert

Re: Source files organisation using gnat

[Tucker Taft]

Geert Bosch (geert@gonzo.sun3.iaf.nl) wrote:

: ...
: So what might be useful is to have some kind of compilation server
: that can keep state between compilations and re-use internal datastructures
: like parse trees. Of course in that case you may have to worry about
: memory management and for example restart the server periodically.

A feature of the AdaMagic(tm) front end is that it can compile multiple
Ada source files in a single execution (and each source file may contain
multiple compilation units, if you wish), while retaining (in an LRU cache)
information from "with"ed library units.  This means that when you
recompile the world, the rate of compilation actually increases the
more files that are compiled at one time.  There is a "build" tool
which drives the compiler in this mode, or you can simply type
something like "adacomp *.ada" and reap the benefits.

You could also configure the front end as a server, by building a driver
that receives file names as messages, and compiles them without
restarting.  The LRU cache would keep the memory footprint from 
exploding.  Some of our licensees have considered this, but it
turns out that the compiler is fast enough that this added complexity
hasn't turned out to be worth the effort yet.

In fact, it seems that most people use the compiler in a 
"compile one source file" mode or "compile the world" mode.  Compiling
one source file is quite fast, and compiling the world in a single
execution of the compiler is also fast due to the caching, so there 
doesn't seem to be much demand for a "server" configuration.

: Regards,
:    Geert

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Source files organisation using gnat

[Robert Dewar]

Geert said

<<

So what might be useful is to have some kind of compilation server

that can keep state between compilations and re-use internal datastructures

like parse trees. Of course in that case you may have to worry about

memory management and for example restart the server periodically.>>


Yes, of course, this is an obvious idea, and is exactly what I was talking about
when I said we had some schemes to substantially speed up compiatlations. In fact
we hvae had a detyailed design for doing this for over a year -- i's on the list!

Re: Source files organisation using gnat

[nabbasi]

In article <dewar.868369368@merv>, dewar@merv.cs.nyu.edu says...
>
>>Geert said
>>
>>So what might be useful is to have some kind of compilation server
>>that can keep state between compilations and re-use internal datastructures
>>like parse trees. Of course in that case you may have to worry about
>>memory management and for example restart the server periodically.>>
>
>Yes, of course, this is an obvious idea, and is exactly what I was 
>talking about when I said we had some schemes to substantially 
>speed up compiatlations. In fact we hvae had a detyailed design for 
>doing this for over a year -- i's on the list!
>

This does not sound much different in its idea (may be not in
implementation) than using a library-based Ada compilation system
to store such informations,  as is done for example by the VAX/VMS 
Ada83 compiler, i.e. the traditional Ada compilation system, 
instead of source-based Ada compilation system such as gnat.  

no ?

Nasser

Re: Source files organisation using gnat

[Robert Dewar]

bassi says

<<

This does not sound much different in its idea (may be not in

implementation) than using a library-based Ada compilation system

to store such informations,  as is done for example by the VAX/VMS

Ada83 compiler, i.e. the traditional Ada compilation system,

instead of source-based Ada compilation system such as gnat.>>



If it does not sound much different, then you don't qiute understand
the suggestion. It is *totally* different. This would be 100% transparent from a user
point of view, not at ALL like a library.