From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:f49:: with SMTP id x70-v6mr7903234ioi.107.1526742240648; Sat, 19 May 2018 08:04:00 -0700 (PDT) X-Received: by 2002:a9d:5c8d:: with SMTP id a13-v6mr326693oti.0.1526742240553; Sat, 19 May 2018 08:04:00 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!u74-v6no2668644itb.0!news-out.google.com!f20-v6ni3000itd.0!nntp.google.com!v8-v6no2703750itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 19 May 2018 08:04:00 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <9169bb0d-626f-4f6d-82c9-8a9b7543a084@googlegroups.com> <92b78739-e2c5-4e45-bbd8-f80ec4918691@googlegroups.com> <6dc39990-16eb-4717-8b8a-1d41c2767530@googlegroups.com> <1103700103.548265160.819002.laguest-archeia.com@nntp.aioe.org> <4a2e4dc5-aec6-4e59-91cd-9476abdbac7c@googlegroups.com> <1193667974.548270050.319144.laguest-archeia.com@nntp.aioe.org> <2f4dd5ae-a481-4eb4-93ff-2c1cc3cb10bb@googlegroups.com> <3d3c1882-ae3d-42aa-8f13-80c550e50375@googlegroups.com> <144a041b-e870-464c-b16f-9adbd7523a92@googlegroups.com> <9b5ee32b-0b12-48fe-b34f-135f3cd8cfb9@googlegroups.com> <17f9d1c5-7c66-4c19-a1d3-f0e7d30cb063@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: disruptors of & inventory of Ada compilers and latest their era of ISO8652 compliance From: "Dan'l Miller" Injection-Date: Sat, 19 May 2018 15:04:00 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52464 Date: 2018-05-19T08:04:00-07:00 List-Id: 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: >=20 >=20 > >=20 > > 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 =E2=80=9CGCC is a bitch to b= uild=E2=80=9D on > > your GCC build script GitHub README.md. >=20 > I think you'll be reading a lot of AWK if you try. >=20 > One aspect of building gcc being such a bitch is that translation process= =20 > building a lot of *source* code (not only from the def files, but also=20 > from other hooks in the sources that build a garbage collector) in the=20 > *build* tree, which must therefore be kept completely separate from the= =20 > source tree (and makes "clean" and even "distclean" make targets flaky). >=20 > This comes back and bites you (well me, anyway) when debugging, when I=20 > try unsuccessfully to trace a source code file/lineno reference, only to= =20 > find it's nonexistent ... in the source tree and I have to look elsewhere= =20 > for it. >=20 > It would be nice to have a clean separation of sources, generated=20 > sources, and object files, but... >=20 > -- 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 wh= y 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 Fla= ng. Actually, Brian, why doesn't an obvious demarcation exist where the generat= ed 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 & in= clude, which are reserved for the non-generated sources, plus often with so= me 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.