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,a7e399a115a66840
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: new programmer wondering what to learn
Date: 1997/05/28
Message-ID: <dewar.864817712@merv>#1/1
X-Deja-AN: 244465895
References: <97052710151645@psavax.pwfl.com> <5mflcq$30v@top.mitre.org>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-05-28T00:00:00+00:00
List-Id: <comp.lang.ada>


Michael says

<<Prior to the gnat age (PTTGA), Ada had a very great
contribution toconfiguration management which gnat eliminated,
which was a built-in method of delivering an entire system in
a single text file, in the correct compilation order, ready to
compile and link. With gnat, we must use and external tool to
configure the parts list, which takes more tool money and labor
money. Luckilly, tools which work most of the time are included
with gnat, namely gnatchop and gnatmake. The configuration
nightmare introduced by gnat/gnatchop/gnatmake is not the
startling increase in manual labor required to externally
control the source code in different external files, nor the
infamous k8-name-overlap problems (try compiling the interrupt
handler provided by Alsys), nor the bugs in gnatmake which
are always to be fixed in the next release, but rather the
loss of the ability to configure multiple bodies for a single
package. Before gnat we did this by strategically placing the
alternate bodies mixed in with linkage pragmas in that single
file. Now, we trade the advantages of gnat for a reduction
in configuration management, and the inability to control
within the compiler, the multiple package bodies needed for
a single package. Tradeoffs like this are common in certain
areas.
>>

My guess from reading this is that Michael does not use GNAT much,
or if he does, he has missed a lot in how to deal with things.
First, and most notably, the reference to "correct compilation
order" is quite bizarre, seeing as GNAT does not require any
particular compilation order.

The reference to a single text file is also a bit curious. Perhaps
he is speaking here of the ability to put multiple units in a single
file that is presented to the compiler? This of course is not something
that is required in either Ada 83 or Ada 95. It is of course a facility
that is provided in GNAT, precisely by the transparent use of gnatchop.

Remember that is it is quite trivial to entirely duplicate the behavior
of a classical Ada 83 library based system in GNAT, so anything you could
do with such a system can be trivially done with GNAT.

The reference to multiple package bodies again is most odd. This is preciesly
something that GNAT can handle far more conveniently than most classical
library based systems. This is because a single library cannot contain
multiple units of the same name. This means that you have to handle this
in Ada 83 using implementation dependent techniques such as the Alsys
multi-lib facility. In GNAT, it is trivial to handle multiple bodies.

Two obvious techniques are to use different file names, and then use
a configuration file that chooses the appropriate files to be used,
or to use the same file name in different directories and then control
the selection by the path name. GNAT itself uses both techniques to
provide multiple bodies for the tasking runtime for different targets,
and we find GNAT particularly convenient for this purpose.

Next, the reference to the "infamous k8-name-overlap problem" also shows
some ignorance of capabilities here. Of course the problem with limited
file names shows up only on DOS. We do not recommend that people use
the DOS version for any serious work, but GNAT is the only full language
Ada 95 compiler for DOS, so if you must use DOS, you will have to use
GNAT, and you certainly will have to address the file name problem.

Here is an important point: GNAT places NO RESTRICTIONS on the names that
can be used for Ada source files. You can call an Ada source file
printf.c if you like. There is a convenient default naming convention,
that many people find quite satisfactory, but certainly if you compile
other than trivial programs for DOS, you will not find the default
satisfactory. You must choose your own appropriate file names, just as
you would for any other system in DOS, and then use the standard GNAT
features for specifying the file names to the compiler (the -x switch
for gcc, and the Source_File_Name configuration pragma).

If you are finding a "startling increase in manual labor", you are
probably not using the system right. Last time I enquired, you said
you were not really using GNAT. I somewhat guess that this is still
the case!

Anyway, I suggest that you try to be more specific, rather than just
generally rambling. You may then well be able to get more specific
help -- try in particular sending specific questions about usage
to chat@gnat.com, where there are definitely people who can help,
if indeed you are genuinely interested in using GNAT!

Robert Dewar
Ada Core Technologies