Re: SweetAda 0.1 released

[gabriele.galeotti.xyz@gmail.com]

On Friday, July 10, 2020 at 8:44:13 AM UTC+2, Roger wrote:
> On Friday, July 10, 2020 at 10:24:41 AM UTC+10, Roger wrote:
> > On Friday, July 10, 2020 at 5:50:42 AM UTC+10, gabriele....@gmail.com wrote:
> > > Hi Roger.
> > > 
> > > Nice. However it's pretty strange, because elftool get the same PATH as other executables. I guess you are trying to execute it from the outside of SweetAda.
> > > 
> > 
> > The problem occurs when running menu.sh.
> > I decided that updating PATH was needed after finding the declaration of ELFTOOL at Makefile.tc.in which does not provide a path for either : gprbuild or elftool:
> > GPRBUILD := gprbuild$(EXEEXT)
> > ELFTOOL  := elftool$(EXEEXT)
> > GDB      := $(TOOLCHAIN_GDB)
> > 
> > There's a possibilty that the wrong gprbuild may be used as no path is declared for GPRBUILD but may be using /opt/GNAT/2020/bin/gprbuild?
> > I was thinking of adding the /opt/sweetada/bin/path to these declarations in Makefile.tc.in.
> 
> After further investigation I have removed /opt/sweetada/bin from my PATH and have modified my Makefile.tc.in to:
> 
> > GPRBUILD := $(TOOLCHAIN_PREFIX)/bin/gprbuild$(EXEEXT)
> > ELFTOOL  := $(TOOLCHAIN_PREFIX)/bin/elftool$(EXEEXT)
> > GDB      := $(TOOLCHAIN_GDB)
> 
> I think that other tools use  TOOLCHAIN_PROGRAM_PREFIX: x86_64-sweetada-elf-
> resulting in commands such as : x86_64-sweetada-elf-gcc
> which is in the same directory as elftool,  so why  ELFTOOL  := elftool$(EXEEXT) doesn't work remains a mystery to me.

Hi Roger.

I would like to investigate a little bit more. Sorry if I am writing trivial things, it's just to keep ourselves synchronized.

I assume you download 0.1c, but only minor unrelated thing changes, the same holds for 0.1.

First of all, toolchains for Windows and OSX have a GNU make as part of the toolchain. Windows does not have such thing (unless you install MSYS/Cygwin), while for OSX you have to install Xcode. I want sweetada to be as independent as possible, that's why you can find the GNU make in the package.

All begins in menu.sh.

sweetada development could be performed in a shell with a PATH wich 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.

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.

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.

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. 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.