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=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Received: by 2002:ad4:5533:: with SMTP id ba19mr75081028qvb.110.1594547950205; Sun, 12 Jul 2020 02:59:10 -0700 (PDT) X-Received: by 2002:a05:6830:2056:: with SMTP id f22mr28057809otp.240.1594547949984; Sun, 12 Jul 2020 02:59:09 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.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: Sun, 12 Jul 2020 02:59:09 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=87.6.17.20; posting-account=JRF_-woAAABYlsAtkCl_CUxBuQy2SsaQ NNTP-Posting-Host: 87.6.17.20 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: <59edfbd5-3108-47d1-ab0e-982fe568078co@googlegroups.com> Subject: Re: SweetAda 0.1 released From: gabriele.galeotti.xyz@gmail.com Injection-Date: Sun, 12 Jul 2020 09:59:10 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:59436 List-Id: On Sunday, July 12, 2020 at 4:45:11 AM UTC+2, Roger wrote: > On Sunday, July 12, 2020 at 2:18:19 AM UTC+10, gabriele....@gmail.com wro= te: >=20 > >=20 > > I would like to investigate a little bit more. Sorry if I am writing tr= ivial things, it's just to keep ourselves synchronized. > Not trivial at all. I am a relative novice with these things. My Unix ma= ke experience is quite limited. > > I assume you download 0.1c, but only minor unrelated thing changes, the= same 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= the toolchain. I want sweetada to be as independent as possible, that's wh= y 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 ha= s /opt/sweetada/bin (or whatever is the installation prefix) added in front= of its current content (so to override other potential clashes). menu.sh i= s a shortcut and nothing else. > Understood. I note the "could" and the importance of "in front of its cu= rrent content" > > Please note that once you have a correct PATH, you could issues shell c= ommands like "make all", etc etc, without calling menu.sh. In order to obey= to the least surprise principle, stay in the sweetada source code director= y. > By " correct PATH", I presume a PATH which has /opt/sweetada/bin in front= of its other content. > > So you call menu.sh. But menu.sh doesn't know where you really install = the 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.i= n > But not /opt/sweetada/bin; or elsewhere that I can find. > However, the makefile has PATH :=3D $(TOOLCHAIN_PREFIX)/bin:$(PATH) which= should do the job. >=20 > > The particular make in that directory is thus called. > >=20 > > So, the first thing is checking if menu.sh detect "darwin" as a legal o= s. Try to "echo $OSTYPE" inside the script.=20 > "echo $OSTYPE" returns "darwin".=20 >=20 > I also added "@$(call echo-command,"PATH: $(PATH)")" to the Makefile w= hich confirmed that "/opt/sweetada/bin" is at the start of PATH. >=20 > Being convinced of this, I removed my prepends for elftool and gprbuild i= n 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 setti= ngs, 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 PA= TH with the sweetada toolchain as the first path to look in, so it will hav= e no problems in calling executables. GPRBUILD or ELFTOOL are called exactl= y like the compiler, so there is no point in prepend anything. > >=20 > > The reason why ELFTOOL !=3D elftool is honestly rather inexplicable, be= cause if the current OSTYPE is set to "darwin", then EXEEXT evaluates to em= pty, 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. >=20 > 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 f= irst. Fine, Roger. I'm happy to read your post. Now I would like to clarify the difference between: - the installation PREFIX, /opt/sweetada - executable PATH, /opt/sweetada/bin which has a totally general meaning in the unix/gnu world. Maybe this usefu= l also for other people. Windows is a totally different beast and I won't e= xplain it now. Filesystem rules got the concept of hierarchy of directories. If you look a= t a normal Linux filesystem, things appear clear enough. You can find some = hints also in OSX, although is a rather proprietary implementation. A hierarchy is a directory together with a collection of subdirectories. St= andard subdirectories are: - bin - include - lib - share - ... bin is for executables. include is for development headers. lib is for libr= aries. share is for auxiliary files. Other subdirectories may exist, like s= bin, man, doc, ... When you look at a Linux (unix) filesystem, you note that a more or less st= andard hierarchy exists, rooted at /. There is no include, because development in the main filesystem is not allo= wed. share is not present. But you get bin/ and lib/, which are necessary t= o run basic system functionalities. Then there is the /usr hierarchy. Inside /usr you can find, again, bin/, li= b/, and also include/, share/, ... /usr is the main working hierarchy for system development. Then there is normally a third hierarchy rooted at /usr/local. The same sto= ry, but for user development and user "personal" files. A common hierarchy is also rooted at /opt. Here people would often install = their programs. But in order to mantain maximum separation and avoid possible conflicts, yo= u can create your own hierarchy. This hierarchy is known as the PREFIX. And= this is why, normally, most packages defaults to /usr or /usr/local. You c= an change the prefix by passing "--prefix=3D" to the configure= . If every program got installed in the same prefix, things could rapidly b= ecome a mess. SweetAda does that, indeed, inside the installation prefix, you can find bi= n/, lib/, ... Obviously, if you choose a non-pretty-standard prefix, you have to communic= ate that to your system. If are stuck with /usr or /usr/local you have to d= o nothing, because the executables are already visible due to PATH set duri= ng initialization by the system to their corrispondent executables subdirec= tories /usr/bin and /usr/local/bin. But with other prefixes, you have to ad= d them to PATH. Note that you must add PREFIX/bin, not PREFIX alone -- your PREFIX is a hie= rarchy with a standard layout. And there is obviously a rather nice feauture: if you want to delete your p= ackage, you simply delete the prefix. You can't do that if prefix=3D/usr. And obviously, this a rather coarse explanation. Things are not fixed and m= any packages have strange layouts. Hope it was useful, see you soon. G