Re: SweetAda 0.1 released

[Roger <rogermcm2@gmail.com>]

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.