Re: disruptors of & inventory of Ada compilers and latest their era of ISO8652 compliance

[Simon Wright <simon@pushface.org>]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> This comes back and bites you (well me, anyway) when debugging, when I
> try unsuccessfully to trace a source code file/lineno reference, only
> to find it's nonexistent ... in the source tree and I have to look
> elsewhere for it.

Not directly related, but when exploring the compiler's innards (only
the Ada part, since the machine definition files etc. are way outside my
competence/area of interest) I've used a GPR like

   project Gcc_8 is

      for Source_Dirs use ("gcc-8.1.0-build/gcc/ada",
                           "gcc-8.1.0/gcc/ada");
      for Object_Dir use "gcc-8.1.0-build/gcc/ada";
      for Languages use ("Ada", "C");

   end Gcc_8;

The build process selects/generates some Ada files from templates in
the source tree, gcc-8.1.0/gcc/ada, into the build tree,
gcc-8.1.0-build/gcc/ada; the Ada objects are compiled in the build tree.

I can then use Emacs ada-mode or GPS to explore the code.

One reason for needing to do this is the AdaCore fondness for "use". For
example, bindgen.adb's context clauses are

   with ALI;      use ALI;
   with Casing;   use Casing;
   with Fname;    use Fname;
   with Gnatvsn;  use Gnatvsn;
   with Hostparm;
   with Namet;    use Namet;
   with Opt;      use Opt;
   with Osint;    use Osint;
   with Osint.B;  use Osint.B;
   with Output;   use Output;
   with Rident;   use Rident;
   with Stringt;  use Stringt;
   with Table;
   with Targparm; use Targparm;
   with Types;    use Types;

   with System.OS_Lib;
   with System.WCh_Con; use System.WCh_Con;

   with GNAT.Heap_Sort_A; use GNAT.Heap_Sort_A;
   with GNAT.HTable;