From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:ac8:22d2:: with SMTP id g18mr80759389qta.38.1594521910830; Sat, 11 Jul 2020 19:45:10 -0700 (PDT) X-Received: by 2002:a9d:424:: with SMTP id 33mr46808484otc.76.1594521910529; Sat, 11 Jul 2020 19:45:10 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!feeder1.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 11 Jul 2020 19:45:10 -0700 (PDT) In-Reply-To: <89558f25-5b98-40a4-a106-d1e9f12eb6beo@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=203.59.139.151; posting-account=d51RWwoAAADvR-x0zYAtT9z3CRxT1eXo NNTP-Posting-Host: 203.59.139.151 References: <242465de-0171-44b1-9618-752b22c3604co@googlegroups.com> <11c21c57-69de-4fcb-9193-71a98ca93ecao@googlegroups.com> <126727e4-3108-46cd-acc6-e42dbdb9dd6bo@googlegroups.com> <011aef92-84e3-47e5-a558-a8c2c6504161o@googlegroups.com> <8959b86d-ec38-4e0b-a272-384751914732o@googlegroups.com> <16b49b03-8657-425d-bad5-67cc5fe725d2o@googlegroups.com> <891fe070-40a4-4ba2-a7be-a7e9c4c036a4o@googlegroups.com> <04195e55-a82f-4035-a05d-5078ea2e6259o@googlegroups.com> <2790711b-d169-4a19-b666-5853eb0f5268o@googlegroups.com> <7052e60c-33ad-4961-9a2c-76014bd6c516o@googlegroups.com> <6efbebf3-8dd2-4909-ab48-d57ba39dc309o@googlegroups.com> <7e2ea50e-412b-421a-b842-e97014043e37o@googlegroups.com> <24f16e6b-e885-4dc5-8519-05c6a786f4dfo@googlegroups.com> <53e66aa5-c298-4b27-8718-386e7a624141o@googlegroups.com> <43a34342-88a2-4af3-b146-817192dab5b7o@googlegroups.com> <80160030-7962-4abd-a6cb-46ea2c91decao@googlegroups.com> <8469bb3c-4caa-404d-8fd0-b74d0238450fo@googlegroups.com> <654e2ffe-f7ee-439d-a535-aab4360fad67o@googlegroups.com> <3ad33643-08b1-4ab6-8672-f9df27d822f6o@googlegroups.com> <89558f25-5b98-40a4-a106-d1e9f12eb6beo@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: SweetAda 0.1 released From: Roger Injection-Date: Sun, 12 Jul 2020 02:45:10 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:59432 List-Id: On Sunday, July 12, 2020 at 2:18:19 AM UTC+10, gabriele....@gmail.com wrote= : >=20 > I would like to investigate a little bit more. Sorry if I am writing triv= ial things, it's just to keep ourselves synchronized. Not trivial at all. I am a relative novice with these things. My Unix make= experience is quite limited. > I assume you download 0.1c, but only minor unrelated thing changes, the s= ame holds for 0.1. Yes, I am using 0.1c. > First of all, toolchains for Windows and OSX have a GNU make as part of t= he toolchain. I want sweetada to be as independent as possible, that's why = you can find the GNU make in the package. Seems a good idea. > All begins in menu.sh. Understood. I have been starting with menu.sh. > sweetada development could be performed in a shell with a PATH which has = /opt/sweetada/bin (or whatever is the installation prefix) added in front o= f its current content (so to override other potential clashes). menu.sh is = a shortcut and nothing else. Understood. I note the "could" and the importance of "in front of its curr= ent content" > Please note that once you have a correct PATH, you could issues shell com= mands like "make all", etc etc, without calling menu.sh. In order to obey t= o the least surprise principle, stay in the sweetada source code directory. By " correct PATH", I presume a PATH which has /opt/sweetada/bin in front o= f its other content. > So you call menu.sh. But menu.sh doesn't know where you really install th= e toolchain. In the case of OSX, there is a guess in the standard prefix, i= .e. /opt/sweetada/bin. Noted. TOOLCHAIN_PREFIX :=3D /opt/sweetada is declared in configuration.in But not /opt/sweetada/bin; or elsewhere that I can find. However, the makefile has PATH :=3D $(TOOLCHAIN_PREFIX)/bin:$(PATH) which s= hould do the job. > The particular make in that directory is thus called. >=20 > So, the first thing is checking if menu.sh detect "darwin" as a legal os.= Try to "echo $OSTYPE" inside the script.=20 "echo $OSTYPE" returns "darwin".=20 I also added "@$(call echo-command,"PATH: $(PATH)")" to the Makefile whi= ch confirmed that "/opt/sweetada/bin" is at the start of PATH. Being convinced of this, I removed my prepends for elftool and gprbuild in = Makefile.tc.in and menu.sh now WORKS. >Be sure that MAKE is set to the GNU make=20 > which is located inside the toolchain. >=20 > Maybe I could add a read of the master configuration.in to import setting= s, I will think about it. >=20 > Once menu.sh calls the Makefile, everything should be handled correctly. = If the configuration.in is correctly configured, Makefile will build a PATH= with the sweetada toolchain as the first path to look in, so it will have = no problems in calling executables. GPRBUILD or ELFTOOL are called exactly = like the compiler, so there is no point in prepend anything. >=20 > The reason why ELFTOOL !=3D elftool is honestly rather inexplicable, beca= use if the current OSTYPE is set to "darwin", then EXEEXT evaluates to empt= y, so ELFTOOL should end up in simply "elftool". >=20 > That's how things should work. Try to insert a line like > $(info $(=20 > Let me know, I will continue to check also in my environment. FIXED! as explained above. I suspect that some change in 0.1c fixed my problem. Appologies for the inconvenience. I should have checked properly 0.1c fir= st.