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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: How to compile Barnes' examples from his book using GNAT
Date: Thu, 10 Dec 2015 13:34:24 +0100
Organization: A noiseless patient Spider
Message-ID: <n4brbs$tcr$1@dont-email.me>
References: <2c68ffdd-f55e-4c68-84f1-fbe0f83a0b57@googlegroups.com>
 <n415t5$uko$2@dont-email.me>
 <5ba1035b-7ffa-4ea8-b9cd-fde589b99904@googlegroups.com>
 <87wpsqmwgj.fsf@adaheads.sparre-andersen.dk>
 <4b452d31-f0f6-4e65-ab87-cc250edd32be@googlegroups.com>
 <n4beh1$fnu$1@dont-email.me>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 10 Dec 2015 12:31:56 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="b96887e80893c84a90c3007226ca0d1c";
	logging-data="30107"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+rJ6t+JwwIINKO5xX3I51ABFqrM5daPMg="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.4.0
In-Reply-To: <n4beh1$fnu$1@dont-email.me>
Cancel-Lock: sha1:xV+xwWpfOhzwprR/3DXffNc+5Ws=
Xref: news.eternal-september.org comp.lang.ada:28751
Date: 2015-12-10T13:34:24+01:00
List-Id: <comp.lang.ada>

On 10.12.15 09:55, J-P. Rosen wrote:
> Le 10/12/2015 04:26, Jerry a écrit :
>> It would be nice if it were possible to put multiple specs in one
>> file and multiple bodies in another file thus maintaining interface
>> from implementation but without a proliferation of files.
>
> But since you submit a /file/ to the compiler, if you change something
> in one spec, all the specs get recompiled, possibly triggering a huge
> cascade of (useless) recompilations.

It's not necessarily true that recompilation is needed if gnatmake's
-m switch does a good job:

    * Using `gnatmake' along with the `-m (minimal recompilation)'
      switch provides a mechanism for avoiding unnecessary
      recompilations. Using this switch, you can update the
      comments/format of your source files without having to recompile
      everything.

-m seems to work reasonably well when routinely using gnatchop. If
some file multi.ada has specs for procedures A and B, and I change
the spec for A by adding a parameter, I see this after changing
and saving multi.ada:

$ gnatchop -r -w -c multi.ada && gnatmake -m b
splitting multi.ada into:
    a.ads
    b.ads
gnatmake: "b" up to date.

With recent gnatmake/gcc, there also is a way now to have them
pick one unit from a file for compilation. With gnatmake,

   -eI      Index of unit in multi-unit source file

For example, using the above file with two specs in it,

$ gnatmake -gnatc -eI1 multi.ada
gcc -c -gnatc -x ada -gnateI1 -o multi~1.o multi.ada
$

Two subprogram specs in a file could be alike except for subtypes
of parameters. So, file singlefile.ada could have two almost identical
subprogram specs:

$ cat singlefile.ada

procedure A (X : Integer);

procedure A (X : Positive);
$

Using this scheme consistently, one could then see what happens
when picking one or the other subprogram for compiling a program
that calls A.

Also, for completeness, with -gnats,
  "in syntax-check-only mode (..) it is possible to check
   a file containing multiple compilation units concatenated
   together".

> I prefer to stick to the one-unit/one-file rule. Actually, it was
> already the recommended practice before Gnat made it a requirement.

With good text editors, and standard ways of handling files and
directories, there shouldn't be anything affecting compilation.
Surprisingly, there is.  (Maybe that's the effect of Unix and
MS DOS/Windows™ traditions of addressing compilation systems
and files...)