Re: Problems with the GNAT gnatchop utility

["David C. Hoos, Sr." <david.c.hoos.sr@ada95.com>]

Max Spicer <mjs116@my-dejanews.com> wrote in message
news:7fmn4m$uhv$1@nnrp1.dejanews.com...
> I have recently started to use the GNAT Ada compiler (v. 3.11p) in order
to
> carry on the development of a system, written in Ada.  The original
> development suite for the system used different filenaming conventions to
> GNAT and so I am trying to use gnatchop to convert all the Ada files to
the
> default GNAT file naming standard.  When I did an initial test, using a
> single file, I had no problems.  However, when I tried to use gnatchop
with
> more than one file at a time, I ran into problems.  To illustrate the
> problem, say that I have two files as follows.
>
> test1.ada contains:
> --------------------------
> package Test1 is
>
>    procedure Hello;
>
> end Test1;
>
> package body Test1 is
>
>    procedure Hello is
>    begin
>       null;
>    end Hello;
>
> end Test1;
> --------------------------
>
>
> test2.ada contains:
> --------------------------
> package Test2 is
>
>    procedure Goodbye;
>
> end Test2;
>
> package body Test2 is
>
>    procedure Goodbye is
>    begin
>       null;
>    end Goodbye;
>
> end Test2;
> --------------------------
>
> If, from a directory containing _just_ these two files, I type
>   gnatchop test1.ada test2.ada
> I get the following output:
>   splitting test1.ada into:
>      test1.ads
>      test1.adb
>   test1.adb already exists, use -w to overwrite
>   test1.ads already exists, use -w to overwrite
>   no files have been written
>
> However, if I run gnatchop on the two files individually, everything works
as
> expected (test1.ads, test1.adb, test2.ads, test2.adb are created).  It
seems
> that gnatchop is treating the second (or final) argument as a directory to
> which it should send its output.  In the documentation, the directory
> argument appears to be optional (as are multiple files), and I can't see
how
> gnatchop should be able to distinguish between its last argument being a
file
> to work on, or a directory.  I know that I could get around this problem
by
> using the -w switch, however I am afraid that this could result in a
"real"
> error being ignored (I am working on a large amount of code).
>
> Is this a bug in gnatchop, have I missed something, or am I doing
> something wrong?

First, I suggest you send things like this to report@gnat.com,
as comp.lang.ada is not gnat-specific, and problems reported to
report@gnat.com get put into the hopper to be worked.

I am sending them a copy of this reply.

gnatchop clearly does not work as described in the gnat users guide,
but it does work as described in the output of gnatchop -h, viz.:

Usage: gnatchop [-c] [-h] [-k#] [-r] [-q] [-v] [-w] file [direc]

  -c     compilation mode, configuration pragmas follow RM rules
  -h     help: output this usage information
  -k#    krunch file names of generated files to no more than # characters
  -k     krunch file names of generated files to no more than 8 characters
  -q     quiet mode, no output of generated file names
  -r     generate Source_Reference pragmas referencing original source file
  -v     verbose mode, output version and generated gnat1 commands
  -w     overwrite existing filenames

  file   source file to be chopped
  direc  directory location for split files (default = current directory)

You will note that only one file argument is permitted by the above Usage
message, and gnatchop works as described there.

Also, note that despite the command line examples in the Users Guide, the
description of gnatchop's main purpose refers to file in the singular.

David. C. Hoos, Sr.