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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Brian Drummond Newsgroups: comp.lang.ada Subject: Re: disruptors of & inventory of Ada compilers and latest their era of ISO8652 compliance Date: Sat, 19 May 2018 13:04:10 -0000 (UTC) Organization: A noiseless patient Spider Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sat, 19 May 2018 13:04:10 -0000 (UTC) Injection-Info: h2725194.stratoserver.net; posting-host="466b465532ed1c7125454987b596a349"; logging-data="4664"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/QljyyB+uE1mjfu2MSzWkmMEYwQ9qpH8c=" User-Agent: Pan/0.141 (Tarzan's Death; 168b179 git.gnome.org/pan2) Cancel-Lock: sha1:dyyWUKPWVNnI4wsb06mqc91p0Bo= Xref: reader02.eternal-september.org comp.lang.ada:52463 Date: 2018-05-19T13:04:10+00:00 List-Id: 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