Re: How to compile Barnes' examples from his book using GNAT

["G.B." <bauhaus@futureapps.invalid>]

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