[Bug ada/113877] New: gnatchop -c puts gnat.adc in the current working directory

[Bug ada/113877] New: gnatchop -c puts gnat.adc in the current working directory

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113877

            Bug ID: 113877
           Summary: gnatchop -c puts gnat.adc in the current working
                    directory
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: simon at pushface dot org
                CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57387&action=edit
Demonstrator

In the attached demo, where demo-00.a contains only a configuration pragma,
you’d have expected "gnatchop -c *.a tmp" to put the configuration file 
"gnat.adc" into the same directory "tmp/" as the chopped code. Instead, it’s
output into the current directory.

$ gnatchop -c *.a tmp
writing configuration pragmas from demo-00.a to gnat.adc
splitting demo-00.a into:
splitting demo-01.a into:
   tmp/demo.ads

$ ls -R
demo-00.a       demo-01.a       gnat.adc        tmp

./tmp:
demo.ads

[Bug ada/113877] gnatchop -c puts gnat.adc in the current working directory

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113877

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |ebotcazou at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-02-14

--- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
No clear if anybody else uses -c with gnatchop.

[Bug ada/113877] gnatchop -c puts gnat.adc in the current working directory

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113877

--- Comment #2 from simon at pushface dot org ---
I came across -c in ACATS[1]. I do agree it’s an uncommon usage, and indeed I 
can’t think of other reasons to do it; perhaps it’s to support porting from 
other compilers? (if that’s something we should be concerned about still).

At the moment, if I

  gnatchop -c foo.a -w foo_src
  gnatchop -c bar.a -w bar_src

and both foo.a and bar.a contain a configuration-pragma-only section, then 
bar.a’s configuration pragmas are appended to foo.a’s in gnat.adc in the 
current working directory.

If all configuration pragmas need to be partition-wide, that would justify the
current design, but I don’t think that’s the case.

I just don’t know what the original use case was, or whether there are users 
whose workflows would be disrupted by a change (one of those would _not_ be 
ACATS: it deletes gnatchopped files, including gnat.adc, after each test).

[1]
https://github.com/gcc-mirror/gcc/blob/2c2f57e4158924467afbf4c2fd3938e507287dab/gcc/testsuite/ada/acats/run_all.sh#L332

[Bug ada/113877] gnatchop -c puts gnat.adc in the current working directory

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113877

--- Comment #3 from simon at pushface dot org ---
I’ve now found the related documentation[1].

I think the conclusion is that gnatchop is working-as-designed, and that this 
PR should be marked WONTFIX (or INVALID), as seems best.

Sorry for the noise.

[1]
https://docs.adacore.com/live/wave/gnat_ugn/html/gnat_ugn/gnat_ugn/the_gnat_compilation_model.html#operating-gnatchop-in-compilation-mode

[Bug ada/113877] gnatchop -c puts gnat.adc in the current working directory

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113877

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|NEW                         |RESOLVED

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Thanks for investigating this.