Hello Jeremiah,

> Le 3 mai 2018 à 02:35, Jeremiah Breeden <jeremiah.bree...@gmail.com> a écrit :
> 
> Thanks, that got the build process going.   Ran into the following problems:
> 
> 1.  building Zanyblue places random "build" folders in my directory structure 
> outside of my gnoga envrionment.  I originally thought this was a windows 
> only issue, but today I was building it for a variant of Ubuntu 16.04 and it 
> did the same there if my gnoga directory was far enough away from root locked 
> folders.  To be clear if I have:
> 
> /d/Program_Files/mingw64/home/Jere/gnoga-code/
> 
> and I build zany blue, I get phantom "build" directories in the following 
> locations:
> 
> /d/build
> /d/Program_Files/build
> /d/Program_Files/mingw64/home/build
> 
> I get the same results in my Ubuntu 16.04 variant OS.  I noticed in the main 
> Makefile that the path ../../../build is passed to the zanyblue makefile.  I 
> wonder if it is using it incorrectly in places?

Here is what I got (macOS):
cd deps/zanyblue/src && 
"/Applications/Xcode.app/Contents/Developer/usr/bin/make" 
INSTALL_DIR=../../../build APPDIRS="zbmcompile zbinfo" install
gprinstall -f -p --prefix=../../../build -p -XOS=unix -XTYPE=static 
-XBUILD=Debug -aP../src zanyblue.gpr
Install project ZanyBlue
gprinstall -f -p --prefix=../../../build -p -XOS=unix -XTYPE=static 
-XBUILD=Debug -aP../src --mode=usage zbmcompile/zbmcompile.gpr
Install project zbmcompile
gprinstall -f -p --prefix=../../../build -p -XOS=unix -XTYPE=static 
-XBUILD=Debug -aP../src --mode=usage zbinfo/zbinfo.gpr
Install project zbinfo

What do you get on your side?

I suspect an issue with gprbuild which some versions don't handle relative path 
correctly.
Here is a patch:

diff --git a/Makefile b/Makefile
index bf6a37c7..5e166458 100644
--- a/Makefile
+++ b/Makefile
@@ -145,7 +145,7 @@ sqlite3: lib/libsqlite3.a
 # Zanyblue with DEBUG on
 zanyblue:
        - cd deps/zanyblue/src && "$(MAKE)" BUILD=Debug APPDIRS="zbmcompile 
zbinfo"
-       - cd deps/zanyblue/src && "$(MAKE)" INSTALL_DIR=../../../build 
APPDIRS="zbmcompile zbinfo" install
+       - cd deps/zanyblue/src && "$(MAKE)" INSTALL_DIR="$(CWD)/build" 
APPDIRS="zbmcompile zbinfo" install
 
 pragmarc:
        $(BUILDER) -P deps/PragmARC/lib_pragmarc.gpr


Does it work better?

> 
> 2.  Some potential bugs:
> components/pixi/src/gnoga-gui-plugin-pixi-sprite.adb
> lines 86 and 876 call Sprite.Loop_Times() but in Ada you cannot use the 
> object.operation notation unless operation is a primitive operation.  Since 
> both the declaration and the definition are in the body file (.adb) it cannot 
> be a primitive operation and thus the call is illegal.  Ironically, recent 
> versions of GNAT compile it fine, but when I use 5.4 on my Ubuntu box, it 
> flags it as illegal.  Moving the declaration to the spec file (.ads) fixes 
> the problem.

Is it thus legal? Ada 2012?
Since Loop_Times is a private method of Sprite package, I prefer then to call 
it in traditional manner:
Loop_Times (Sprite, 0, TFin);

> 
> 3.  For some reason on Ubuntu, it looks for gnoga-application-Linux and 
> gnoga.application-Unix in the build process but the files are all lower case 
> named.  It builds fine on windows which is case insensitive but fails on 
> Ubuntu which is strict on case.  Renaming the files fixes the issue.

Yes, it's a awful trick in gnoga.gpr which works on macOS (case insensitive 
file names with standard file system):
      for Body ("Gnoga.Application.Open_command") use "gnoga-application." & 
Settings.Build_Target;

Here is a patch:

diff --git a/src/gnoga.gpr b/src/gnoga.gpr
index e480793b..198494ea 100644
--- a/src/gnoga.gpr
+++ b/src/gnoga.gpr
@@ -11,7 +11,14 @@ project Gnoga is
    for Library_Kind use "static";
 
    package Naming is
-      for Body ("Gnoga.Application.Open_command") use "gnoga-application." & 
Settings.Build_Target;
+      case Settings.Build_Target is
+         when "Windows" =>
+            for Body ("Gnoga.Application.Open_command") use 
"gnoga-application.windows";
+         when "OSX" =>
+            for Body ("Gnoga.Application.Open_command") use 
"gnoga-application.osx";
+         when others =>
+            for Body ("Gnoga.Application.Open_command") use 
"gnoga-application.linux";
+      end case;
    end Naming;
 
    package Compiler renames Settings.Compiler;


Does it work better?

> 
> Thanks again.
> 
> Side note:  On the ubuntu box, I had to fix one of the zanyblue files in the 
> text subdirectory becauase it was using Object'Image, which 5.4 doesn't 
> support.  However, when I search the copy I have on my windows machine, I 
> don't find it.  In both cases I used "git clone -b dev_1.4 
> source/forge/path/to/gnoga gnoga-code" (both on today).  Since I cant 
> replicate it here, I don't have much to give.  My ubuntu box is essentially 
> standalone, so it is hard to get data off of it to here.

With your following post:

> Right after I sent the email I found it.  Not in zany blue, but in 
> 
> components/ace_editor/src/gnoga-gui-plugin-ace_editor.adb:985:           
> Row'Img & ',' & Column'Image & ");");
> 
> It compiles fine in GNAT FSF 7.3 but not in 5.4.  I don't know if 
> Object'Image is legal Ada or not.  It might be, but in my Ubuntu box with 
> version 5.4, I changed it to Column'Img which is a GNAT extension.


You're right, it's a mistake.
As current Gnoga uses 'Img largely, I will correct it.
As Jean-Pierre said I thought too it was for Ada 2020.
But as Jeff noticed it is Ada 2012 so why don't use 'Image instead specific 
'Img from GNAT?
One more item in Gnoga todo list.

Regards, Pascal.
http://blady.pagesperso-orange.fr



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Reply via email to