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

["Dan'l Miller" <optikos@verizon.net>]

On Saturday, May 19, 2018 at 8:04:12 AM UTC-5, Brian Drummond wrote:
> On Fri, 18 May 2018 18:48:03 -0700, Dan'l Miller wrote:
> 
> 
> > 
> > I need to investigate those def files.  Specifically I'll need to learn:
> >  where is the script/code that reads def files and generates C code or C
> > macros to manipulate the C IR tree?  Perhaps running these def scripts
> > is a major portion of what you refer to as “GCC is a bitch to build” on
> > your GCC build script GitHub README.md.
> 
> I think you'll be reading a lot of AWK if you try.
> 
> One aspect of building gcc being such a bitch is that translation process 
> building a lot of *source* code (not only from the def files, but also 
> from other hooks in the sources that build a garbage collector) in the 
> *build* tree, which must therefore be kept completely separate from the 
> source tree (and makes "clean" and even "distclean" make targets flaky).
> 
> 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.
> 
> It would be nice to have a clean separation of sources, generated 
> sources, and object files, but...
> 
> -- Brian

Luke & Simon & anyone else, do you concur?  Is this your experience?

If so, then I think we have arrived at the A#1 internal-technical reason why Apple et al pulled out of GCC to go author Clang (and why Flang community also is fleeing GCC).  Licensing alone isn't what is driving Clang and Flang.

Actually, Brian, why doesn't an obvious demarcation exist where the generated C/C++-language sources are versus separate where the nongenerated C/C++-language sources are.  (It is customary in most development communities to put the generated sources in some sort of different directory than src & include, which are reserved for the non-generated sources, plus often with some different file extension, e.g., .g.h and .g.c (i.e., g for generated) or something like that.  I am going to have really delve into this to see the mess in the vicinity of the C IR tree (especially within GIGI) with my own eyes.  Clean room (without referring to this mess) is always an option.