Re: [Gnoga-list] building v1.4 in windows

[Pascal via Gnoga-list]

> Le 11 juil. 2018 à 04:25, Jeremiah Breeden  a 
> écrit :
> 
> As a note, while testing 1.3 today, I found a similar issue to the "random 
> build directory" that is not present in 1.4.  If I use the command "make all" 
> with version 1.3, it generates a random directory named "home" and all the 
> subdirectories going to gnoga-code/build/*.  This does not occur in version 
> 1.4.  I am guessing it is something similar to what you fixed for 1.4, but a 
> quick diff of the makefiles didn't reveal anything that jumped out at me.  
> For reference, if my directory structure is:
> 
> d:/Program_Files/msys64/home/user/gnoga-code/
> 
> then running "make all" creates:
> 
> d:/home
> 

Hello Jeremiah,

The install process of Zanyblue in 1.3 has been improved in 1.4.

Thanks, 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

Re: [Gnoga-list] building v1.4 in windows

[Pascal via Gnoga-list]

> Le 11 mai 2018 à 02:04, Jeremiah Breeden  a écrit 
> :
> 
> Sorry for the late response.  I was working in a standalone environment, so 
> it took a bit to get setup again.
> 
> I was able to verify that this change fixes the case-sensitivity issue in 
> linux and still works in windows
> 

Thanks, Jeremiah, I'll push them to SF.

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

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

On Sat, May 5, 2018 at 11:58 AM, Jeremiah Breeden  wrote:

> On Sat, May 5, 2018 at 5:11 AM, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> wrote:
>
>> > Le 4 mai 2018 à 01:35, Jeremiah Breeden a écrit :
>> > make[1]: *** [../src/mkfile/install.mk:69: install-zb] Error 1
>> > make[1]: Leaving directory '/home/Jere/gnoga-code-2018_05
>> _01/deps/zanyblue/src'
>> > make: [Makefile:148: zanyblue] Error 2 (ignored)
>> >
>> > I looked and zbmcompile.exe is the correct location, so I don't know
>> why it says it doesn't exist unless it can't tell due to the lack of ".exe"
>> in the build setup somewhere?
>>
>> I agree with your analysis, maybe an issue with grpinstall.
>> It's ok on my side with gprinstall from GNAT GPL 2017, where does your
>> gprinstall come from?
>>
>>
> I use the one supplied here by the Gnoga Sourceforge site.  The gprbuild
> and gprinstall supplied by GNAT GPL 2017 targets a different architecture
> than minw64 so it doesn't work.
>
>
As an update, I tried pulling in the GPRBUILD and GPRINSTALL and other
programs from GNAT GPL 2017, but the issue still persisted.  If I don't
have ".exe" at the end of some generated files, then it barfs on them.  So
far I have discovered that it affects zbinfo, zbmcompile, gnoga_make, and
gnoga_doc.  There might be others, but there is a lot of output to even try
to parse.  Perhaps this is a windows specific issue?
--
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

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

On Sat, May 5, 2018 at 5:11 AM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Thanks again Jeremiah for reporting,
>
> > Le 4 mai 2018 à 01:35, Jeremiah Breeden  a écrit :
> > >
> > > 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?
> >
> > I'll have to try it out next week to be sure.  I'm at home tomorrow and
> my ubuntu box is at work.  Thanks.
>
> Let us informed.
>
>
Sorry for the late response.  I was working in a standalone environment, so
it took a bit to get setup again.

I was able to verify that this change fixes the case-sensitivity issue in
linux and still works in windows
--
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

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

On Sat, May 5, 2018 at 5:11 AM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> > Le 4 mai 2018 à 01:35, Jeremiah Breeden  a
> écrit :
> > make[1]: *** [../src/mkfile/install.mk:69: install-zb] Error 1
> > make[1]: Leaving directory '/home/Jere/gnoga-code-2018_
> 05_01/deps/zanyblue/src'
> > make: [Makefile:148: zanyblue] Error 2 (ignored)
> >
> > I looked and zbmcompile.exe is the correct location, so I don't know why
> it says it doesn't exist unless it can't tell due to the lack of ".exe" in
> the build setup somewhere?
>
> I agree with your analysis, maybe an issue with grpinstall.
> It's ok on my side with gprinstall from GNAT GPL 2017, where does your
> gprinstall come from?
>
>
I use the one supplied here by the Gnoga Sourceforge site.  The gprbuild
and gprinstall supplied by GNAT GPL 2017 targets a different architecture
than minw64 so it doesn't work.
--
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

Re: [Gnoga-list] building v1.4 in windows

[Pascal via Gnoga-list]

Thanks again Jeremiah for reporting,

> Le 4 mai 2018 à 01:35, Jeremiah Breeden  a écrit :
> 
> Unrelated thing to the previous bugs:
> 
> In Gnoga.Gui.Elements.Form, there is a function for turning Autocomplete off 
> and on.  When I tried to disable autocomplete on a Text input type, it didn't 
> work.  Inspecting the DOM showed that it set:
> 
> autocomplete="false"
> 
> when (at least for that input type) it should be
> 
> autocomplete="off"
> 
> I used the Property procedure in Gnoga.Gui.Base to work around it (setting 
> the field manually).

Well done, confirmed with 
https://www.w3schools.com/tags/att_input_autocomplete.asp.
Here is a fix:

diff --git a/src/gnoga-gui-element-form.adb b/src/gnoga-gui-element-form.adb
index 80e9bb57..207529ae 100644
--- a/src/gnoga-gui-element-form.adb
+++ b/src/gnoga-gui-element-form.adb
@@ -142,7 +142,11 @@ package body Gnoga.Gui.Element.Form is
   Value : in  Boolean := True)
is
begin
-  Form.Property ("autocomplete", Value);
+  if Value then
+ Form.Property ("autocomplete", "on");
+  else
+ Form.Property ("autocomplete", "off");
+  end if;
end Autocomplete;
 
--
@@ -151,7 +155,7 @@ package body Gnoga.Gui.Element.Form is
 
function Autocomplete (Form : Form_Type) return Boolean is
begin
-  return Form.Property ("autocomplete");
+  return Form.Property ("autocomplete") = "on";
end Autocomplete;
 

@@ -258,7 +262,11 @@ package body Gnoga.Gui.Element.Form is
   Value   : in Boolean := True)
is
begin
-  Element.Property ("autocomplete", Value);
+  if Value then
+ Element.Property ("autocomplete", "on");
+  else
+ Element.Property ("autocomplete", "off");
+  end if;
end Autocomplete;
 
---
@@ -267,7 +275,7 @@ package body Gnoga.Gui.Element.Form is
 
function Autocomplete (Element : Form_Element_Type) return Boolean is
begin
-  return Element.Property ("autocomplete");
+  return Element.Property ("autocomplete") = "on";
end Autocomplete;
 


> 
> The rest of my responses are below:
> 
> On Thu, May 3, 2018 at 5:03 PM, Pascal via Gnoga-list 
>  wrote:
> Hello Jeremiah,
> 
> 
> > Le 3 mai 2018 à 02:35, Jeremiah Breeden  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?
> 
> The patch stops the phantom "build" directories. Thank you!  
> 
> I did notice it was failing to build zbcompile on my side (while your side 
> compiled it correctly.
> 
> My new output is:
> 
> $ make zanyblue
> cd deps/zanyblue/src && "make" 

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

Unrelated thing to the previous bugs:

In Gnoga.Gui.Elements.Form, there is a function for turning Autocomplete
off and on.  When I tried to disable autocomplete on a Text input type, it
didn't work.  Inspecting the DOM showed that it set:

autocomplete="false"

when (at least for that input type) it should be

autocomplete="off"

I used the Property procedure in Gnoga.Gui.Base to work around it (setting
the field manually).

The rest of my responses are below:

On Thu, May 3, 2018 at 5:03 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah,
>
>
> > Le 3 mai 2018 à 02:35, Jeremiah Breeden  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?
>

The patch stops the phantom "build" directories. Thank you!

I did notice it was failing to build zbcompile on my side (while your side
compiled it correctly.

My new output is:

$ make zanyblue
cd deps/zanyblue/src && "make" BUILD=Debug APPDIRS="zbmcompile zbinfo"
make[1]: Entering directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src'
gprbuild -p -XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../src -P
zanyblue.gpr
"libzanyblue.a" up to date
make -C zbmcompile
make[2]: Entering directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src/zbmcompile'
gprbuild -p -p -XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../../src -P
zbmcompile
gprbuild: "zbmcompile.exe" up to date
make[2]: Leaving directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src/zbmcompile'
make -C zbinfo
make[2]: Entering directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src/zbinfo'
gprbuild -p -p -XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../../src -P
zbinfo
gprbuild: "zbinfo.exe" up to date
make[2]: Leaving directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src/zbinfo'
make[1]: Leaving directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src'
cd deps/zanyblue/src && "make"
INSTALL_DIR=/home/Jere/gnoga-code-2018_05_01/build APPDIRS="zbmcompile
zbinfo" install
make[1]: Entering directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src'
gprinstall -f -p --prefix=/home/Jere/gnoga-code-2018_05_01/build -p
-XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../src zanyblue.gpr
Install project ZanyBlue
gprinstall -f -p --prefix=/home/Jere/gnoga-code-2018_05_01/build -p
-XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../src --mode=usage
zbmcompile/zbmcompile.gpr
Install project zbmcompile
file
D:\Program_Files\msys64\home\Jere\gnoga-code-2018_05_01\deps\zanyblue\bin\zbmcompile
does not exist, build may not be complete
make[1]: *** [../src/mkfile/install.mk:69: install-zb] Error 1
make[1]: Leaving directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src'
make: [Makefile:148: zanyblue] Error 2 (ignored)

I 

Re: [Gnoga-list] building v1.4 in windows

[Pascal via Gnoga-list]

Hello Jeremiah,


> Le 3 mai 2018 à 02:35, Jeremiah Breeden  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 
> 

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

That's a good point on portability.  I think Gnoga could benefit from more
portability.  I think right now it still uses a lot of GNAT extensions like
'Unrestricted_Access, and I don't know if the other libraries like
Simple_Components rely on any or not.  On the flip side, I'm not aware of
any other compilers besides GNAT that implement 2012, so I guess there is
time before it would be beneficial (which is a shame!)..

It is neat that GNAT is implementing some 2020 possible features early.

On Thu, May 3, 2018 at 1:35 AM, Jean-Pierre Rosen  wrote:

> Le 03/05/2018 à 02:47, Jeremiah Breeden a écrit :
> > SNIPPED
> It is an Ada 2020 extension, so it is normal that older versions of Gnat
> don't support it.
>
> But the good fix is to use T'Image(Object) instead. Works since Ada83
> and does not depend on compiler or version.
>
> --
> J-P. Rosen
> Adalog
> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
> Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
> http://www.adalog.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
>
--
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

Re: [Gnoga-list] building v1.4 in windows

[Jean-Pierre Rosen]

Le 03/05/2018 à 02:47, Jeremiah Breeden a écrit :
> 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.
> 
> So I don't know if it is a bug or not, but it is something to at least
> consider.
> 
It is an Ada 2020 extension, so it is normal that older versions of Gnat
don't support it.

But the good fix is to use T'Image(Object) instead. Works since Ada83
and does not depend on compiler or version.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.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

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

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.

So I don't know if it is a bug or not, but it is something to at least
consider.

On Wed, May 2, 2018 at 8:35 PM, Jeremiah Breeden  wrote:

>
> 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.
>
> On Wed, May 2, 2018 at 3:17 PM, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> wrote:
>
>>
>> > Le 2 mai 2018 à 02:39, Jeremiah Breeden  a
>> écrit :
>> >
>> > Build environment:
>> > mingw64/msys2 x86_64 GNAT 7.2 FSF on Windows 10
>> >
>> > I cloned the 1.4 branch and tried to make a build.  I started with a
>> "make all" command and after a bit it erred on:
>> >
>> > ***
>> > make[2]: Leaving directory '/home/Jere/gnoga-code-2018_05
>> _01/components/pixi'
>> > make -C mnmenu install
>> > make[2]: Entering directory '/home/Jere/gnoga-code-2018_05
>> _01/components/mnmenu'
>> > cp -p css/*.* ../../css
>> > cp -p html/*.* ../../html
>> > cp -p img/*.* ../../img
>> > cp -p js/*.* ../../js
>> > make[2]: Leaving directory '/home/Jere/gnoga-code-2018_05
>> _01/components/mnmenu'
>> > make[1]: Leaving directory '/home/Jere/gnoga-code-2018_05
>> _01/components'
>> > gprbuild -p --target=x86_64-w64-mingw32 -P src/gnoga.gpr
>> -XPRJ_TARGET=Windows
>> > gnoga.gpr:2:06: unknown project file: "lib_components.gpr"
>> > gprbuild: "src/gnoga.gpr" processing failed
>> > make: *** [Makefile:188: gnoga] Error 4
>> >
>> > ***
>> > SNIPPED...
>> > anyone know where I go from here?
>> >
>> >
>>
>> Thanks Jeremiah for reporting,
>>
>> Thanks for help log, it is really helpful for analysis.
>> The issue is cause by the wrong choice of PATH separator which is not the
>> same between Unix and Windows.
>>
>> Here is a patch for the makefile:
>>
>> diff --git a/Makefile b/Makefile
>> index bf6a37c7..c350701e 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -79,7 +79,7 @@ endif
>>
>>  PATHSEP=$(strip $(PATHSEP2))
>>
>> -ifeq ($(PRJ_TARGET),Windows)
>> +ifeq ($(BUILD_OS),Windows)
>> GPR_PROJECT_PATH_SEP=;
>>  else
>> GPR_PROJECT_PATH_SEP=:
>>
>> The separator choice should be good now.
>>
>> HTH, 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
>>
>
>
--
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

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

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?

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.

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.

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.

On Wed, May 2, 2018 at 3:17 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

>
> > Le 2 mai 2018 à 02:39, Jeremiah Breeden  a
> écrit :
> >
> > Build environment:
> > mingw64/msys2 x86_64 GNAT 7.2 FSF on Windows 10
> >
> > I cloned the 1.4 branch and tried to make a build.  I started with a
> "make all" command and after a bit it erred on:
> >
> > ***
> > make[2]: Leaving directory '/home/Jere/gnoga-code-2018_
> 05_01/components/pixi'
> > make -C mnmenu install
> > make[2]: Entering directory '/home/Jere/gnoga-code-2018_
> 05_01/components/mnmenu'
> > cp -p css/*.* ../../css
> > cp -p html/*.* ../../html
> > cp -p img/*.* ../../img
> > cp -p js/*.* ../../js
> > make[2]: Leaving directory '/home/Jere/gnoga-code-2018_
> 05_01/components/mnmenu'
> > make[1]: Leaving directory '/home/Jere/gnoga-code-2018_05_01/components'
> > gprbuild -p --target=x86_64-w64-mingw32 -P src/gnoga.gpr
> -XPRJ_TARGET=Windows
> > gnoga.gpr:2:06: unknown project file: "lib_components.gpr"
> > gprbuild: "src/gnoga.gpr" processing failed
> > make: *** [Makefile:188: gnoga] Error 4
> >
> > ***
> > SNIPPED...
> > anyone know where I go from here?
> >
> >
>
> Thanks Jeremiah for reporting,
>
> Thanks for help log, it is really helpful for analysis.
> The issue is cause by the wrong choice of PATH separator which is not the
> same between Unix and Windows.
>
> Here is a patch for the makefile:
>
> diff --git a/Makefile b/Makefile
> index bf6a37c7..c350701e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -79,7 +79,7 @@ endif
>
>  PATHSEP=$(strip $(PATHSEP2))
>
> -ifeq ($(PRJ_TARGET),Windows)
> +ifeq ($(BUILD_OS),Windows)
> GPR_PROJECT_PATH_SEP=;
>  else
> GPR_PROJECT_PATH_SEP=:
>
> The separator choice should be good now.
>
> HTH, 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
>
--
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

Re: [Gnoga-list] building v1.4 in windows

[Pascal via Gnoga-list]

> Le 2 mai 2018 à 02:39, Jeremiah Breeden  a écrit :
> 
> Build environment:
> mingw64/msys2 x86_64 GNAT 7.2 FSF on Windows 10
> 
> I cloned the 1.4 branch and tried to make a build.  I started with a "make 
> all" command and after a bit it erred on:
> 
> ***
> make[2]: Leaving directory '/home/Jere/gnoga-code-2018_05_01/components/pixi'
> make -C mnmenu install
> make[2]: Entering directory 
> '/home/Jere/gnoga-code-2018_05_01/components/mnmenu'
> cp -p css/*.* ../../css
> cp -p html/*.* ../../html
> cp -p img/*.* ../../img
> cp -p js/*.* ../../js
> make[2]: Leaving directory 
> '/home/Jere/gnoga-code-2018_05_01/components/mnmenu'
> make[1]: Leaving directory '/home/Jere/gnoga-code-2018_05_01/components'
> gprbuild -p --target=x86_64-w64-mingw32 -P src/gnoga.gpr -XPRJ_TARGET=Windows
> gnoga.gpr:2:06: unknown project file: "lib_components.gpr"
> gprbuild: "src/gnoga.gpr" processing failed
> make: *** [Makefile:188: gnoga] Error 4
> 
> ***
> 
> I remebered that we needed to set the GPR_PROJECT_PATH, so I did a make help:
> ***
> $ make help
> -
> -- --
> -- make --
> -- --
> --  ::= help-- print this message   --
> -- | all   -- build gnoga and all dependencies (debug mode)--
> -- | release   -- build gnoga in release mode  --
> -- | install   -- install gnoga release mode   --
> -- | install_debug -- install gnoga debug mode --
> -- | uninstall -- uninstall gnoga  --
> -- | demo  -- build all demos  --
> -- | tutorials -- build all tutorials  --
> -- | gnoga_tools   -- build all tools  --
> -- | tests -- build all tests  --
> -- | clean -- clean build files--
> -- | clean_all -- clean build files and deps   --
> -- | rm-docs   -- build reference manual   --
> -- | html-docs -- build html docs  --
> -- | gps   -- launch GPS with gnoga environnement  --
> -- | check_rules   -- check gnoga with AdaControl  --
> -- --
> -- PREFIX   = /home/Jere/gnoga-code-2018_05_01/inst_folder
> --
> -- GPRCHECK = GPRBUILD GPL 2016 (20160515) (i686-pc-mingw32) 
> Copyright (C) 2004-2016, AdaCore This is free software; see the source for 
> copying conditions. There is NO warranty; not even for MERCHANTABILITY or 
> FITNESS FOR A PARTICULAR PURPOSE.  --
> -- TARGET   = x86_64-w64-mingw32  
>   --
> -- GPR_PROJECT_PATH = 
> /home/Jere/gnoga-code-2018_05_01/build/share/gpr;/home/Jere/gnoga-code-2018_05_01/build/lib/gnat
>   --
> -- ATOMIC_ACCESS= GCC-long-offsets --
> -- BUILDER  = gprbuild -p --target=x86_64-w64-mingw32 
>   --
> -- PRJ_TARGET   = Windows--
> -- BUILD_OS = UnixLike  --
> -- --
> -
> 
> ***
> 
> when I tried to set the GPR_PROJECT_PATH using that value, I got:
> 
> $ set 
> GPR_PROJECT_PATH=/home/Jere/gnoga-code-2018_05_01/build/share/gpr;/home/Jere/gnoga-code-2018_05_01/build/lib/gnat
> bash: /home/Jere/gnoga-code-2018_05_01/build/lib/gnat: No such file or 
> directory
> 
> anyone know where I go from here?
> 
> 

Thanks Jeremiah for reporting,

Thanks for help log, it is really helpful for analysis.
The issue is cause by the wrong choice of PATH separator which is not the same 
between Unix and Windows.

Here is a patch for the makefile:

diff --git a/Makefile b/Makefile
index bf6a37c7..c350701e 100644
--- a/Makefile
+++ b/Makefile
@@ -79,7 +79,7 @@ endif
 
 PATHSEP=$(strip $(PATHSEP2))
 
-ifeq ($(PRJ_TARGET),Windows)
+ifeq ($(BUILD_OS),Windows)
GPR_PROJECT_PATH_SEP=;
 else
GPR_PROJECT_PATH_SEP=:

The