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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a32653cf595422e6 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.205.130.15 with SMTP id hk15mr720167bkc.5.1335437750011; Thu, 26 Apr 2012 03:55:50 -0700 (PDT) Path: h15ni167504bkw.0!nntp.google.com!news1.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: GNAT and register allocation References: <4f9138c2$0$6628$9b4e6d93@newsspool2.arcor-online.net> <4f9145b5$0$6557$9b4e6d93@newsspool4.arcor-online.net> <4f918218$0$6557$9b4e6d93@newsspool4.arcor-online.net> <82r4vhi8v4.fsf@stephe-leake.org> <4f94352f$0$6625$9b4e6d93@newsspool2.arcor-online.net> <87aa23d5tz.fsf@adaheads.sparre-andersen.dk> <4f9474d4$0$7611$9b4e6d93@newsspool1.arcor-online.net> <82lillgvx9.fsf@stephe-leake.org> <4f96aa50$0$7617$9b4e6d93@newsspool1.arcor-online.net> <82vckof2s8.fsf@stephe-leake.org> <4f97f411$0$7620$9b4e6d93@newsspool1.arcor-online.net> Date: Thu, 26 Apr 2012 06:55:46 -0400 Message-ID: <82sjfqep8t.fsf@stephe-leake.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt) Cancel-Lock: sha1:68EL4yoHm8hRwWA4QXqgwddS5Xc= MIME-Version: 1.0 X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: c0ff74f9929b5e029e66117180 X-Received-Bytes: 4008 Content-Type: text/plain; charset=us-ascii Date: 2012-04-26T06:55:46-04:00 List-Id: Georg Bauhaus writes: > On 25.04.12 13:51, Stephen Leake wrote: > >>> Yes, GNAT project files are understandable, though non-portable TTBOMK. >> >> What do you mean by "portable" here? > > Portable from one compiler to another. The Ada programs typically > are portable as-is. Ok. But the C and Fortran compiler options are equally non-portable, so I don't see this as significant. >>> Gpr files will likely not be used by those who code for Intel's >>> Fortran compiler, or the C part of GCC; they can easily specify >>> IFCOPTS or GCCOPTS referenced in Makefiles. >> >> Why is that relevant? > >> So if that gnatmake line includes -P, and is kept with the >> rest of the Ada source code, what's the problem? > > The problem is that there exists a setup, and personnel (P), and > (1) there is a script > (2) that processes a .ini file (common to all languages) > (3) runs a simple makefile injecting few variables from step (2) > (4) for all languages (more than a dozen). > > In the interest of manageability and transparency to (P), things are > to be kept simple and comparable, as far as I understand previous > comments. The programs do change every now and then. > The configuration files would have to change, too. > Such changes need to be checked by (P), for all languages, > in order to prevent anything that in effect violates some rules. So the Ada programers are required to understand the C and Fortran compiler options well enough to maintain them? And conversely, the C and Fortran people are expected to maintain the Ada compiler options. That doesn't sound reasonable to me. I will grant that the gpr files are not as well documented as the compiler options; it is not possible to determine which package should contain any given compiler option. If that were fixed, I think it's reasonable to expect anyone who can maintain makefiles and compiler options in general to maintain gpr files. And as I have said, in the long run everyone would gain if everyone switched to gpr files. > Ideally, settings commonly used by all compilers, such as "optimize", > or "use this hardware", will be sufficiently effective and understood > by all compilers. Do you mean "spelled the same for all compilers" or "all compilers will have an option similar enough in meaning". I'd expect the latter, but not the former. > In fact, an earlier version of the GNAT make rule had been referring > to COPTS, which was -O3 -fomit-frame-pointer; the C++ rule did the > same, I think. Fortran cannot refer to GCCish COPTS, since they > switched to Intel Fortran. And did anyone object to that "non-compatible options" change? -- -- Stephe