Re: SweetAda 0.1 released

[gabriele.galeotti.xyz@gmail.com]

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 wrote:
> 
> > 
> > I would like to investigate a little bit more. Sorry if I am writing trivial 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 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 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 of 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 current content"
> > Please note that once you have a correct PATH, you could issues shell commands like "make all", etc etc, without calling menu.sh. In order to obey to 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 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 := /opt/sweetada is declared in configuration.in
> But not  /opt/sweetada/bin; or elsewhere that I can find.
> However, the makefile has PATH := $(TOOLCHAIN_PREFIX)/bin:$(PATH) which should do the job.
> 
> > The particular make in that directory is thus called.
> > 
> > So, the first thing is checking if menu.sh detect "darwin" as a legal os. Try to "echo $OSTYPE" inside the script. 
> "echo $OSTYPE"  returns "darwin". 
> 
> I also added "@$(call echo-command,"PATH:    $(PATH)")" to the Makefile which 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 
> > which is located inside the toolchain.
> > 
> > Maybe I could add a read of the master configuration.in to import settings, I will think about it.
> > 
> > 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.
> > 
> > The reason why ELFTOOL != elftool is honestly rather inexplicable, because if the current OSTYPE is set to "darwin", then EXEEXT evaluates to empty, so ELFTOOL should end up in simply "elftool".
> > 
> > That's how things should work. Try to insert a line like
> > $(info $(<varname)) in the Makefiles in order to dump some variable, maybe it could help.
> > 
> > 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 first.

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 useful also for other people. Windows is a totally different beast and I won't explain it now.

Filesystem rules got the concept of hierarchy of directories. If you look at 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. Standard subdirectories are:
- bin
- include
- lib
- share
- ...
bin is for executables. include is for development headers. lib is for libraries. share is for auxiliary files. Other subdirectories may exist, like sbin, man, doc, ...

When you look at a Linux (unix) filesystem, you note that a more or less standard hierarchy exists, rooted at /.

There is no include, because development in the main filesystem is not allowed. share is not present. But you get bin/ and lib/, which are necessary to run basic system functionalities.

Then there is the /usr hierarchy. Inside /usr you can find, again, bin/, lib/, 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 story, 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, you 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 can change the prefix by passing "--prefix=<your_prefix>" to the configure. If every program got installed in the same prefix, things could rapidly become a mess.

SweetAda does that, indeed, inside the installation prefix, you can find bin/, lib/, ...

Obviously, if you choose a non-pretty-standard prefix, you have to communicate that to your system. If are stuck with /usr or /usr/local you have to do nothing, because the executables are already visible due to PATH set during initialization by the system to their corrispondent executables subdirectories /usr/bin and /usr/local/bin. But with other prefixes, you have to add them to PATH.

Note that you must add PREFIX/bin, not PREFIX alone -- your PREFIX is a hierarchy with a standard layout.

And there is obviously a rather nice feauture: if you want to delete your package, you simply delete the prefix. You can't do that if prefix=/usr.

And obviously, this a rather coarse explanation. Things are not fixed and many packages have strange layouts.

Hope it was useful, see you soon.

G