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,53ca16c587912bce
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Source files organisation using gnat
Date: 1997/07/03
Message-ID: <dewar.867959470@merv>#1/1
X-Deja-AN: 254353967
References: <19970630185901.OAA27670@ladder02.news.aol.com>
 <dewar.867707107@merv> <5pghpn$1k5@gcsin3.geccs.gecm.com>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-07-03T00:00:00+00:00
List-Id: <comp.lang.ada>


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!