Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

I unset the environment variable and redid it and it works now.  Sorry
about that.  I'm guessing I misspelled the variable or something last time
(I used tab completion for the path, so it should have been correct
regardless).  It now correctly fails on tutorial 10 (I don't have sqlite
3).  Side question:  should failures to build tutorials (or demos) be hard
make failures?  It might be good to have the makefile ignore those and keep
going.

One other update.  I installed GNAT GPL 2017 and tried it.  The issue I had
with the tools.gpr not finding the exe files doesn't exist for the Adacore
supplied GPRBuild vs the Gnoga sourceforge supplied version.  This suggests
either a configuration issue or a build issue.  I've been looking through
the GPRbuild documentation but haven't run across anything about setting
known file extension types yet.  It's weird that the Adacore one doesn't
need you to specify .exe while the gnoga supplied version does.

Sorry for the trouble.  Thanks again!

On Sun, Dec 10, 2017 at 1:33 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah,
>
> The error gnoga.gpr:2:06: unknown project file: "lib_components.gpr" at
> the end of log indicates that GPR_PROJECT_PATH is not well set.
>
> Can you just send the print log of "make help" for confirmation?
>
> Thanks for your help, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> > Le 10 déc. 2017 à 18:03, Jeremiah Breeden 
> a écrit :
> >
> > Thanks.
> >
> > I downloaded the most recent from today and tried make all.  It failed
> at some point.  I am attaching the output to help out.  I did ensure that
> the GPR_PROJECT_PATH variable was set.
> >
> > I was confused about the comment you made: "So former makefile couldn't
> work at all for Windows users."  With patches we discussed last month, I
> was able to make Gnoga before, just not out of the box.  The makefile was
> at least functional in Windows using mingw, just some configuration
> problems.  Did you mean something else?
> >
> > Again, thanks for taking a look at this.
> >
> > On Wed, Dec 6, 2017 at 4:29 PM, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> wrote:
> > Hello,
> >
> > "Reading the manuel always brings you benefit."
> > I has verified that one more time reading in GPRBuild manual how
> GPR_PROJECT_PATH is processed either with UnixLike OS or with Windows.
> > UnixLike, separator is ":", Windows it is ";".
> > So former makefile couldn't work at all for Windows users.
> >
> > Thus I've  made this change and some more to deal with directory paths
> including space character.
> >
> > 1) Now for users who want to use Gnoga as a library, just do:
> > $ make install
> >
> > By default installation is in "inst_folder" in current directory, it can
> be overridden with:
> > $ make PREFIX= install
> >
> > To install also Zanyblue and Pragmarc, you can do before:
> > $ make zanyblue pragmarc
> >
> > I you don't have Sqlite3, you can do before (automatic for Windows):
> > $ make sqlite3
> >
> > And then enjoy, don't forget to set GPR_PROJECT_PATH for your
> installation directory.
> >
> > 2) I you want to play with Gnoga source code, demos, tutorials or even
> tests, do:
> > $ make all
> >
> > And for installation, do:
> > $ make install_debug
> >
> >
> > These changes have been pushed on Gnoga SF GIT branch dev_1.3:
> > https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/
> >
> > Could you please test it on your own environnement?
> > Feel free to send feedback.
> >
> > 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
>
>
> 
> --
> 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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Hello Jeremiah,

The error gnoga.gpr:2:06: unknown project file: "lib_components.gpr" at the end 
of log indicates that GPR_PROJECT_PATH is not well set.

Can you just send the print log of "make help" for confirmation?

Thanks for your help, Pascal.
http://blady.pagesperso-orange.fr


> Le 10 déc. 2017 à 18:03, Jeremiah Breeden  a 
> écrit :
> 
> Thanks.  
> 
> I downloaded the most recent from today and tried make all.  It failed at 
> some point.  I am attaching the output to help out.  I did ensure that the 
> GPR_PROJECT_PATH variable was set.
> 
> I was confused about the comment you made: "So former makefile couldn't work 
> at all for Windows users."  With patches we discussed last month, I was able 
> to make Gnoga before, just not out of the box.  The makefile was at least 
> functional in Windows using mingw, just some configuration problems.  Did you 
> mean something else?
> 
> Again, thanks for taking a look at this.
> 
> On Wed, Dec 6, 2017 at 4:29 PM, Pascal via Gnoga-list 
>  wrote:
> Hello,
> 
> "Reading the manuel always brings you benefit."
> I has verified that one more time reading in GPRBuild manual how 
> GPR_PROJECT_PATH is processed either with UnixLike OS or with Windows.
> UnixLike, separator is ":", Windows it is ";".
> So former makefile couldn't work at all for Windows users.
> 
> Thus I've  made this change and some more to deal with directory paths 
> including space character.
> 
> 1) Now for users who want to use Gnoga as a library, just do:
> $ make install
> 
> By default installation is in "inst_folder" in current directory, it can be 
> overridden with:
> $ make PREFIX= install
> 
> To install also Zanyblue and Pragmarc, you can do before:
> $ make zanyblue pragmarc
> 
> I you don't have Sqlite3, you can do before (automatic for Windows):
> $ make sqlite3
> 
> And then enjoy, don't forget to set GPR_PROJECT_PATH for your installation 
> directory.
> 
> 2) I you want to play with Gnoga source code, demos, tutorials or even tests, 
> do:
> $ make all
> 
> And for installation, do:
> $ make install_debug
> 
> 
> These changes have been pushed on Gnoga SF GIT branch dev_1.3:
> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/
> 
> Could you please test it on your own environnement?
> Feel free to send feedback.
> 
> 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


--
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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Thanks.

I downloaded the most recent from today and tried make all.  It failed at
some point.  I am attaching the output to help out.  I did ensure that the
GPR_PROJECT_PATH variable was set.

I was confused about the comment you made: "So former makefile couldn't
work at all for Windows users."  With patches we discussed last month, I
was able to make Gnoga before, just not out of the box.  The makefile was
at least functional in Windows using mingw, just some configuration
problems.  Did you mean something else?

Again, thanks for taking a look at this.

On Wed, Dec 6, 2017 at 4:29 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello,
>
> "Reading the manuel always brings you benefit."
> I has verified that one more time reading in GPRBuild manual how
> GPR_PROJECT_PATH is processed either with UnixLike OS or with Windows.
> UnixLike, separator is ":", Windows it is ";".
> So former makefile couldn't work at all for Windows users.
>
> Thus I've  made this change and some more to deal with directory paths
> including space character.
>
> 1) Now for users who want to use Gnoga as a library, just do:
> $ make install
>
> By default installation is in "inst_folder" in current directory, it can
> be overridden with:
> $ make PREFIX= install
>
> To install also Zanyblue and Pragmarc, you can do before:
> $ make zanyblue pragmarc
>
> I you don't have Sqlite3, you can do before (automatic for Windows):
> $ make sqlite3
>
> And then enjoy, don't forget to set GPR_PROJECT_PATH for your installation
> directory.
>
> 2) I you want to play with Gnoga source code, demos, tutorials or even
> tests, do:
> $ make all
>
> And for installation, do:
> $ make install_debug
>
>
> These changes have been pushed on Gnoga SF GIT branch dev_1.3:
> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/
>
> Could you please test it on your own environnement?
> Feel free to send feedback.
>
> Regards, Pascal.
> http://blady.pagesperso-orange.fr
>
>
>
$ make all
gprbuild -p --target=x86_64-w64-mingw32 -P 
deps/simple_components/lib_components   
 .gpr 
-XAtomic_Access=GCC-long-offsets -XLegacy=Ada2012
object directory 
"D:\Program_Files\msys64\home\Jere\gnoga-code-2017_12_10\deps\s 

   imple_components\obj\components\static\" created
library directory 
"D:\Program_Files\msys64\home\Jere\gnoga-code-2017_12_10\deps\  

  simple_components\lib\components\static" created for project lib_components
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat   
 12 parsers-multiline_source-xpm.ads
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 parsers-generic_source-xpm.adb
parsers-generic_source-xpm.adb:360:10: warning: "Name" is not modified, could 
be declared constant
parsers-generic_source-xpm.adb:496:13: warning: "Name" is not modified, could 
be declared constant
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 gnat-sockets-server.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 generic_blackboard.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 tables.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 tables-utf8_names.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 tables-names.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization.ads
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization-pulse_events.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization-mutexes.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization-generic_pulse_events.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization-generic_mutexes_array.adb
synchronization-generic_mutexes_array.adb:140:23: warning: "Success" modified 
by call, but value might not be referenced
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization-generic_events_array.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization-events.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 strings_edit.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 strings_edit-utf8.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Hello,

"Reading the manuel always brings you benefit."
I has verified that one more time reading in GPRBuild manual how 
GPR_PROJECT_PATH is processed either with UnixLike OS or with Windows.
UnixLike, separator is ":", Windows it is ";".
So former makefile couldn't work at all for Windows users.

Thus I've  made this change and some more to deal with directory paths 
including space character.

1) Now for users who want to use Gnoga as a library, just do:
$ make install

By default installation is in "inst_folder" in current directory, it can be 
overridden with:
$ make PREFIX= install

To install also Zanyblue and Pragmarc, you can do before:
$ make zanyblue pragmarc

I you don't have Sqlite3, you can do before (automatic for Windows):
$ make sqlite3

And then enjoy, don't forget to set GPR_PROJECT_PATH for your installation 
directory.

2) I you want to play with Gnoga source code, demos, tutorials or even tests, 
do:
$ make all

And for installation, do:
$ make install_debug


These changes have been pushed on Gnoga SF GIT branch dev_1.3:
https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/

Could you please test it on your own environnement?
Feel free to send feedback.

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


> Le 12 nov. 2017 à 13:35, Pascal via Gnoga-list 
>  a écrit :
> 
> Hello Jeremiah,
> 
> Well, I guess mingw or cygwin is expected for Gnoga. As I hadn't got full 
> feedbacks with full logs of these users if any, I actually don't know.
> The point is that it appears that Zanyblue expected cmd window.
> 
> Thus, I have customized the makefile with cmd.exe prefix in case of Windows, 
> see attached file:
> 
> 
> 
> Can you please test this version 1.3 on a dedicated repository with last 
> dev_1.3 commit and makefile replaced by attached one?
> 
> I haven't yet pushed it, if ok I'll pushed it to SF.
> 
> Thanks, Pascal.
> http://blady.pagesperso-orange.fr
> 
> 
>> Le 10 nov. 2017 à 19:05, Jeremiah Breeden  a 
>> écrit :
>> 
>> Thanks for the feedback!
>> 
>> Perhaps a better question is what is the expected build environment for FSF 
>> based Gnoga on Windows?  
>> 
>> By default the command window does not have "make" nor does it have a non 
>> GPL version of GCC.  When you built it, what did you use as an environment?  
>> I got mingw64 because it comes with both make and FSF GCC.  If there is a 
>> different environment that Gnoga requires, I can try to accomodate.  It 
>> might also be good to have something somewhere that lays out the specific 
>> build environment needed since base windows is not compatible.
>> 
>> 
>> On Wed, Nov 8, 2017 at 1:20 PM, Pascal via Gnoga-list 
>>  wrote:
>> Hello Jeremiah,
>> 
>> Here is the answer from Zanyblue:
>> "The Windows build of ZB is pretty much a Native build, not under a Unix 
>> style env as supplied by mingw64.  Build in a cmd window is pretty much how 
>> I verify the build.  It would be possible to detect mingw64 in the build 
>> process, will investigate however I do expect the a native Windows env., 
>> e.g., "\" instead of "/"."
>> 
>> Zanyblue catch the OS environment variable:
>> OS=Windows_NT
>> 
>> Here are some build results under cmd window:
>> 
>> 
>> 
>> Let me know what you think.
>> 
>> 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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Hello Jeremiah,

Well, I guess mingw or cygwin is expected for Gnoga. As I hadn't got full 
feedbacks with full logs of these users if any, I actually don't know.
The point is that it appears that Zanyblue expected cmd window.

Thus, I have customized the makefile with cmd.exe prefix in case of Windows, 
see attached file:



Makefile
Description: Binary data


Can you please test this version 1.3 on a dedicated repository with last 
dev_1.3 commit and makefile replaced by attached one?

I haven't yet pushed it, if ok I'll pushed it to SF.

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


> Le 10 nov. 2017 à 19:05, Jeremiah Breeden  a 
> écrit :
> 
> Thanks for the feedback!
> 
> Perhaps a better question is what is the expected build environment for FSF 
> based Gnoga on Windows?  
> 
> By default the command window does not have "make" nor does it have a non GPL 
> version of GCC.  When you built it, what did you use as an environment?  I 
> got mingw64 because it comes with both make and FSF GCC.  If there is a 
> different environment that Gnoga requires, I can try to accomodate.  It might 
> also be good to have something somewhere that lays out the specific build 
> environment needed since base windows is not compatible.
> 
> 
> On Wed, Nov 8, 2017 at 1:20 PM, Pascal via Gnoga-list 
>  wrote:
> Hello Jeremiah,
> 
> Here is the answer from Zanyblue:
> "The Windows build of ZB is pretty much a Native build, not under a Unix 
> style env as supplied by mingw64.  Build in a cmd window is pretty much how I 
> verify the build.  It would be possible to detect mingw64 in the build 
> process, will investigate however I do expect the a native Windows env., 
> e.g., "\" instead of "/"."
> 
> Zanyblue catch the OS environment variable:
> OS=Windows_NT
> 
> Here are some build results under cmd window:
> 
> 
> 
> Let me know what you think.
> 
> 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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

My make:

$ make -v
GNU Make 4.2.1
Built for x86_64-pc-msys
Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


On Sun, Nov 5, 2017 at 12:30 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah, see answers below.
> HTH, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> According the (complex) makefiles of Zanyblue, directories should only be
> created if they don't already exist with a rule as for instance:
> $(INSTALL_INCDIR):
> $(call MKDIR,$(INSTALL_INCDIR))
>
> So I wonder about make tool, here is the one I get:
> cmd$ make -v
> GNU Make 3.81
> Copyright (C) 2006  Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> This program built for i386-apple-darwin11.3.0
>
> What is yours?
>
>
>
--
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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

I'm not sure the correct way to get the version numbers.  I download
snapshots.

The 4/7 one was from the old 1.2 branch.  It lists:
gnoga-code-c1d52b72c56033c328c838b4726a2dd5a019bbf2

the 11/2 one lists:
gnoga-code-bb4b7329fa0674c9a7eabd9c8974c33980ecd1ab

Though recently I was doing git clone and git checkout so I have no idea
how to get the version numbers for those.

On Sun, Nov 5, 2017 at 12:56 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah,
>
> Can precise which version number for both 4/7 and 11/2?
>
> It seems to me a make tool issue.
> I'll ask Zanyblue author what is the configuration used for Windows.
>
> Regards, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> > Le 4 nov. 2017 à 21:20, Jeremiah Breeden  a
> écrit :
> >
> > Ok, some progress.  It looks like for some reason it is picking
> windows_nt.mk in the zanyblue/src/mkfile/ dir instead of unix.mk (for
> mingw64).  The major problem is it wants to use "\" instead of "/" but "\"
> is also an escape character in text strings and certain combinations work
> in commands and others do not.  If I renamed windows_nt.mk to
> windows_nt.old and copied unix.mk to windows_nt.mk
> >
> > For whatever reason the version I downloaded on 4/7/2017 does not have
> this problem.  I don't know if it picks unix.mt or something else occurs,
> but it builds fine with that copy of gnoga.  I found out that the one I
> downloaded on 11/2/2017 (the one I am having problems with) was trying to
> create a home directory in a completely different spot due to the
> windows_nt.mk file command format.  Since it was in the wrong location
> and the commands had "\" in them the build wasn't working correctly.
> >
> > So the question is what changed with zanyblue between 4/7 and 11/2?  I'm
> curious if that was the cause of my "lib" issue earlier.  I'll need to
> start over and check that out.
>
>
> 
> --
> 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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Responses below

On Sun, Nov 5, 2017 at 1:07 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah,
>
> What is your GNAT version?
>

FSF GNAT 7.2 for mingw64

mingw64 output:
$ GNAT --version
GNAT 7.2.0
Copyright (C) 1996-2017, Free Software Foundation, Inc.
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 machine:
$ GCC -dumpmachine
x86_64-w64-mingw32



> Could be a system detection issue in GPRBuild?
>
>
I don't know, but I don't feel like it is.  It works well with all other
ada projects.  It is originally targetted for i686-pc-mingw32 but I created
a configuration file (per the gprbuild documentation) and now it retargets
x86_64-w64-mingw32.  If it were a system detection issue inside of
GPRBuild, I would expect all of my ada projects to fail to install or
build.  It only fails when trying to install tools without the exe
extension, but it builds and installs libraries just fine.  That doesn't
rule out a GPRBuild issue, but I don't think it is system detection in
particular.


> HTH, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> > Le 4 nov. 2017 à 21:28, Jeremiah Breeden  a
> écrit :
> >
> > Forgot to add.  So now "make all" works with all the changes I have gone
> through.  The command "make install" still fails as I described in a
> separate email chain a while back (couple of months maybe?).
> >
> > In particular, to get "make install" to work, I have to modify
> tools/tools.gpr and add ".exe" to both executable names:
> >
> >package Builder is
> >   for Executable ("gnoga_make-main.adb") use "gnoga_make.exe";
> >   for Executable ("gnoga_doc-main.adb") use "gnoga_doc.exe";
> >end Builder;
> >
> > Otherwise make install fails with
> > ---
> > Install project Tools
> > file D:\Program_Files\msys64\home\Jere\gnoga-code-2017_11_02\bin\gnoga_make
> does not exist, build may not be complete
> > make: *** [Makefile:202: install] Error 1
> > ---
> >
> > and a similar error for gnoga_doc
> >
>
--
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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Thanks for the response.  Some responses below.

On Sun, Nov 5, 2017 at 1:24 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Thanks Jeremiah,
>
> Anyway your feedback is important.
> Your diff file is also important.
> I'll apply the patch for:
> Makefile
> deps/zanyblue/src/zbcom.gpr
> deps/zanyblue/src/zbmcompile/Makefile
>
> Thanks for information below, sorry if I've already asked you them before,
> I read and answer the e-mail one by one.
>
> 1. Seems to me a confusion from make tool between mingw64 and Windows
> systems.
> I'm waiting for Zanyblue answer on Windows building configuration.
>

I would agree, especially with the more recent email.


> 2. Seems to me a GPRBuild issue with Windows.
>
>
Most likely.  I am using the GPRBuild that comes from the Gnoga sourceforge
site.  Unfortunately there aren't any other options out there for 64 bit
windows.  I did ensure that GPRBuild is targetting the correct
platform/architecture.  It works well with all other Ada related projects I
have.
--
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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Thanks for the feedback!

Perhaps a better question is what is the expected build environment for FSF
based Gnoga on Windows?

By default the command window does not have "make" nor does it have a non
GPL version of GCC.  When you built it, what did you use as an
environment?  I got mingw64 because it comes with both make and FSF GCC.
If there is a different environment that Gnoga requires, I can try to
accomodate.  It might also be good to have something somewhere that lays
out the specific build environment needed since base windows is not
compatible.


On Wed, Nov 8, 2017 at 1:20 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah,
>
> Here is the answer from Zanyblue:
> "The Windows build of ZB is pretty much a Native build, not under a Unix
> style env as supplied by mingw64.  Build in a cmd window is pretty much how
> I verify the build.  It would be possible to detect mingw64 in the build
> process, will investigate however I do expect the a native Windows env.,
> e.g., "\" instead of "/"."
>
> Zanyblue catch the OS environment variable:
> OS=Windows_NT
>
> Here are some build results under cmd window:
>
>
>
> Let me know what you think.
>
> Regards, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> > Le 5 nov. 2017 à 19:24, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> a écrit :
> >
> > Thanks Jeremiah,
> >
> > Anyway your feedback is important.
> > Your diff file is also important.
> > I'll apply the patch for:
> > Makefile
> > deps/zanyblue/src/zbcom.gpr
> > deps/zanyblue/src/zbmcompile/Makefile
> >
> > Thanks for information below, sorry if I've already asked you them
> before, I read and answer the e-mail one by one.
> >
> > 1. Seems to me a confusion from make tool between mingw64 and Windows
> systems.
> > I'm waiting for Zanyblue answer on Windows building configuration.
> >
> > 2. Seems to me a GPRBuild issue with Windows.
> >
> > Thanks again, Pascal.
> > http://blady.pagesperso-orange.fr
> >
> >
> >> Le 5 nov. 2017 à 15:19, Jeremiah Breeden 
> a écrit :
> >>
> >> Hi,
> >>
> >> The patch partially worked.  It removed all the "make all" errors but
> still had the windows_nt.mk issue which made the "make all" create
> spurious directories outside of the gnoga directory.  It also caused the
> sequence "make all" => "make clean" => "make all" to fail on the second
> "make all" due to some zanyblue conflicts.  "make install" still did not
> work.  I made the two changes I discussed earlier:
> >>
> >> 1.  fix the COPY, MKDIR, RMDIR, and DELETE commands
> >> cd deps/zanyblue/src/mkfile
> >> mv Windows_NT.mk Windows_NT.old
> >> cp unix.mk Windows_NT.mk
> >>
> >> 2.  Fix make install
> >> changed tools/tools.gpr to have ".exe" appended to the executable names.
> >>
> >> I've never made a diff before, so I might have messed this up, but I am
> attaching my updated diff file for reference.
> >>
> >> I don't know if these are good changes, but they are what worked for:
> >> Windows 10 Home
> >> mingw64, gcc 7.2 for x86_64-w64-mingw32
> >> gprbuild from Gnoga sourceforge site.
> >>
> >> They may break things on other platforms or configurations.  And one
> comes involves changing zanyblue files...so not sure how useful this is.
> >>
> >>
> >> On Sat, Nov 4, 2017 at 4:54 PM, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> wrote:
> >> Hello Jeremiah, see answers below.
> >> 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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Hello Jeff,

I've pushed to dev_1.3 branch changes concerning Gnoga makefile and issues with 
Zanyblue and SQLite3.
Can you please test this version 1.3 on a dedicated repository?

INSTALL file has also been updated with more information.
Let me know if it is helpful.

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


> Le 5 nov. 2017 à 20:18, Jeffrey R. Carter  a écrit :
> 
> On 11/05/2017 07:44 PM, Pascal wrote:
>> 
>> In 1.3, source files of deps (Simple components, Zanyblue, PramgArc) are no 
>> more mixed with Gnoga source files. There are built and installed as 
>> separate libraries in "build" directory.
>> Thus when building your own application GPR_PROJECT_PATH is needed to tell 
>> gprbuild to find them.
>> For instance:
>> GPR_PROJECT_PATH = /gnoga-1.3a/build/share/gpr:/gnoga-1.3a/build/lib/gnat
>> See make help prompt for your own settings.
> 
> My application does not depend directly on these, only indirectly through 
> Gnoga,
> so it seems to me that Gnoga should take care of this for me.
> 
> When you have all your makefile patches in git I'll try again.
> 
> -- 
> Jeff Carter
> "The men get one hot meal a day: a bowl of steam."
> Take the Money and Run
> 145
> 
> --
> 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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Hello Jeremiah,

Here is the answer from Zanyblue:
"The Windows build of ZB is pretty much a Native build, not under a Unix style 
env as supplied by mingw64.  Build in a cmd window is pretty much how I verify 
the build.  It would be possible to detect mingw64 in the build process, will 
investigate however I do expect the a native Windows env., e.g., "\" instead of 
"/"."

Zanyblue catch the OS environment variable:
OS=Windows_NT

Here are some build results under cmd window:
make -C ../src/root
make[1]: Entering directory `D:/zanyblue-1.3.0b/src/root'
gnatprep -DV_MAJOR=1 -DV_MINOR=3 -DV_PATCH=0 -DV_STATUS=Beta -DVERSION=1.3.0 
-DSVN_VERSION='"3059X"' -DCOPYRIGHT_YEAR=2016 zanyblue.adb-in zanyblue.adb
make[1]: Leaving directory `D:/zanyblue-1.3.0b/src/root'
gprbuild -p -XOS=Windows_NT -XTYPE=static -XBUILD=Production -XV_MAJOR=1 
-XV_MINOR=3 -XV_PATCH=0 -XV_STATUS=Beta -aP../lib/gnat -aP../src -P zblib.gpr
Compile
   [Ada]  zanyblue-utils.adb
...
   [Ada]  zanyblue.adb
Build Libraries
   [gprlib]   zanyblue.lexch
   [archive]  libzanyblue.a
   [index]libzanyblue.a
make -C zbmcompile
make[1]: Entering directory `D:/zanyblue-1.3.0b/src/zbmcompile'
gprbuild -p -XOS=Windows_NT -XTYPE=static -XBUILD=Production -XV_MAJOR=1 
-XV_MINOR=3 -XV_PATCH=0 -XV_STATUS=Beta -aP../../lib/gnat -aP../../src -P 
zbmcompile
Compile
   [Ada]  zbmcompile-main.adb
...
   [Ada]  zbmcompile-parser_handler.adb
Bind
   [gprbind]  zbmcompile-main.bexch
   [Ada]  zbmcompile-main.ali
Link
   [link] zbmcompile-main.adb
make[1]: Leaving directory `D:/zanyblue-1.3.0b/src/zbmcompile'
make -C zbinfo
make[1]: Entering directory `D:/zanyblue-1.3.0b/src/zbinfo'
../../bin/zbmcompile -i -p -v -O -A -C -G exceptions -G prints -o mesg -d mesg 
-S mesg/zbinfo-messages.stamp ZBInfo_Messages ZBInfo
...
gprbuild -p -XOS=Windows_NT -XTYPE=static -XBUILD=Production -XV_MAJOR=1 
-XV_MINOR=3 -XV_PATCH=0 -XV_STATUS=Beta -aP../../lib/gnat -aP../../src -P zbinfo
Compile
   [Ada]  zbinfo-main.adb
...
   [Ada]  zbinfo_messages-zbinfo_prints.adb
Bind
   [gprbind]  zbinfo-main.bexch
   [Ada]  zbinfo-main.ali
Link
   [link] zbinfo-main.adb
make[1]: Leaving directory `D:/zanyblue-1.3.0b/src/zbinfo'
make -C zbtest
make[1]: Entering directory `D:/zanyblue-1.3.0b/src/zbtest'
../../bin/zbmcompile -i -A -C -p -v -O -G exceptions -G prints -o mesg -d mesg 
-S mesg/zbtest-messages.stamp ZBTest_Messages ZBTest
...
gprbuild -p -XOS=Windows_NT -XTYPE=static -XBUILD=Production -XV_MAJOR=1 
-XV_MINOR=3 -XV_PATCH=0 -XV_STATUS=Beta -aP../../lib/gnat -aP../../src -P zbtest
Compile
   [Ada]  zbtest-main.adb
...
   [Ada]  zbtest-commands-file_type_arguments.ads
Bind
   [gprbind]  zbtest-main.bexch
   [Ada]  zbtest-main.ali
Link
   [link] zbtest-main.adb
make[1]: Leaving directory `D:/zanyblue-1.3.0b/src/zbtest'
cmd.exe /c "mkdir ..\build\include\zanyblue"
cmd.exe /c "copy ..\include\zanyblue\zanyblue-os-ld_run_path.ads 
..\build\include\zanyblue\zanyblue-os-ld_run_path.ads"
1 fichier(s) copi‚(s).
...
cmd.exe /c "copy ..\include\zanyblue\zanyblue.ads 
..\build\include\zanyblue\zanyblue.ads"
1 fichier(s) copi‚(s).
cmd.exe /c "mkdir ..\build\lib\zanyblue"
cmd.exe /c "copy ..\lib\zanyblue\zanyblue-os-ld_run_path.ali 
..\build\lib\zanyblue\zanyblue-os-ld_run_path.ali"
1 fichier(s) copi‚(s).
...
cmd.exe /c "copy ..\lib\zanyblue\zanyblue.ali 
..\build\lib\zanyblue\zanyblue.ali"
1 fichier(s) copi‚(s).
cmd.exe /c "mkdir ..\build\lib\gnat"
cmd.exe /c "copy ..\lib\gnat\zanyblue.gpr ..\build\lib\gnat\zanyblue.gpr"
1 fichier(s) copi‚(s).
make -C zbmcompile
make[1]: Entering directory `D:/zanyblue-1.3.0b/src/zbmcompile'
gprbuild -p -XOS=Windows_NT -XTYPE=static -XBUILD=Production -XV_MAJOR=1 
-XV_MINOR=3 -XV_PATCH=0 -XV_STATUS=Beta -aP../../lib/gnat -aP../../src -P 
zbmcompile
gprbuild: "zbmcompile.exe" up to date
make[1]: Leaving directory `D:/zanyblue-1.3.0b/src/zbmcompile'
make -C zbinfo
make[1]: Entering directory `D:/zanyblue-1.3.0b/src/zbinfo'
gprbuild -p -XOS=Windows_NT -XTYPE=static -XBUILD=Production -XV_MAJOR=1 
-XV_MINOR=3 -XV_PATCH=0 -XV_STATUS=Beta -aP../../lib/gnat -aP../../src -P zbinfo
gprbuild: "zbinfo.exe" up to date
make[1]: Leaving directory `D:/zanyblue-1.3.0b/src/zbinfo'
make -C zbtest
make[1]: Entering directory `D:/zanyblue-1.3.0b/src/zbtest'
gprbuild -p -XOS=Windows_NT -XTYPE=static -XBUILD=Production -XV_MAJOR=1 
-XV_MINOR=3 -XV_PATCH=0 -XV_STATUS=Beta -aP../../lib/gnat -aP../../src -P zbtest
gprbuild: "zbtest.exe" up to date
make[1]: Leaving directory `D:/zanyblue-1.3.0b/src/zbtest'
cmd.exe /c "mkdir ..\build\bin"
cmd.exe /c "copy ..\bin\zbinfo.exe ..\build\bin\zbinfo.exe"
1 fichier(s) copi‚(s).
cmd.exe /c "copy ..\bin\zbmcompile.exe ..\build\bin\zbmcompile.exe"
1 fichier(s) copi‚(s).
cmd.exe /c "copy ..\bin\zbtest.exe ..\build\bin\zbtest.exe"
1 fichier(s) copi‚(s).

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeffrey R. Carter]

On 11/05/2017 07:44 PM, Pascal wrote:
> 
> In 1.3, source files of deps (Simple components, Zanyblue, PramgArc) are no 
> more mixed with Gnoga source files. There are built and installed as separate 
> libraries in "build" directory.
> Thus when building your own application GPR_PROJECT_PATH is needed to tell 
> gprbuild to find them.
> For instance:
> GPR_PROJECT_PATH = /gnoga-1.3a/build/share/gpr:/gnoga-1.3a/build/lib/gnat
> See make help prompt for your own settings.

My application does not depend directly on these, only indirectly through Gnoga,
so it seems to me that Gnoga should take care of this for me.

When you have all your makefile patches in git I'll try again.

-- 
Jeff Carter
"The men get one hot meal a day: a bowl of steam."
Take the Money and Run
145

--
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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Hello Jeff,
See some answers below.
Regards, Pascal.
http://blady.pagesperso-orange.fr


> Le 5 nov. 2017 à 15:12, Jeffrey R. Carter  a écrit :
> 
> On 11/04/2017 12:18 PM, Pascal wrote:
>> 
>> My bad, more lines have to be changed in Gnoga makefile, see attached patch:
> 
> With that patch, make all proceeds successfully until tutorial_10.adb, and
> trying to rebuild an existing application fails as before.

See below.

> 
>> Well sqlite3 is present as default on macOS.
>> Isn't there some path from your Xubuntu libs to add to the linker?
>> What is your target name (to add it in the supported ones)? Do make help.
>> Gnoga makefile foresees building it but only for Windows.
>> You can force to build it with:
>> make sqlite3
> 
> I don't have sqlite3 and it was never needed before. Building the tutorials 
> that
> use it (10 and 11) failed before, but their failure didn't cause the overall
> make to fail. The prior behavior seems desirable.

Bad regression, I'll fix it with following patch:
-   cd tutorial/tutorial-10 && $(BUILDER) -Ptutorial_10.gpr 
-XPRJ_TARGET=${PRJ_TARGET}
-   cd tutorial/tutorial-11 && $(BUILDER) -Ptutorial_11.gpr 
-XPRJ_TARGET=${PRJ_TARGET}
+   - cd tutorial/tutorial-10 && $(BUILDER) -Ptutorial_10.gpr 
-XPRJ_TARGET=${PRJ_TARGET}
+   - cd tutorial/tutorial-11 && $(BUILDER) -Ptutorial_11.gpr 
-XPRJ_TARGET=${PRJ_TARGET}

> 
>> You need to add installed component GPR paths with GPR_PROJECT_PATH, do make 
>> help to take yours.
> 
> I don't understand this sentence. No additional action was needed before and I
> don't see why it should be needed now.

In 1.3, source files of deps (Simple components, Zanyblue, PramgArc) are no 
more mixed with Gnoga source files. There are built and installed as separate 
libraries in "build" directory.
Thus when building your own application GPR_PROJECT_PATH is needed to tell 
gprbuild to find them.
For instance:
GPR_PROJECT_PATH = /gnoga-1.3a/build/share/gpr:/gnoga-1.3a/build/lib/gnat
See make help prompt for your own settings.

> 
>> From the beginning Gnoga makes copying of components / plugins in src 
>> directory, as Pixi is a new one in 1.3, it is not supported in 1.2.
>> You need to remove it before from 1.3, do make clean_all.
>> Well, I'm not satisfied by the actual behavior but I really not found a 
>> better.
> 
> Removing them allows the make to finish. This hasn't arisen before because I
> never had to go back to an earlier version.

I wonder about a script parsing the plugin directories and making a dynamic gpr 
project with references to source files instead of copying source files.

> 
> -- 
> Jeff Carter
> "The men get one hot meal a day: a bowl of steam."
> Take the Money and Run
> 145


--
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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Thanks Jeremiah,

Anyway your feedback is important.
Your diff file is also important.
I'll apply the patch for:
Makefile
deps/zanyblue/src/zbcom.gpr
deps/zanyblue/src/zbmcompile/Makefile

Thanks for information below, sorry if I've already asked you them before, I 
read and answer the e-mail one by one.

1. Seems to me a confusion from make tool between mingw64 and Windows systems.
I'm waiting for Zanyblue answer on Windows building configuration.

2. Seems to me a GPRBuild issue with Windows.

Thanks again, Pascal.
http://blady.pagesperso-orange.fr


> Le 5 nov. 2017 à 15:19, Jeremiah Breeden  a écrit 
> :
> 
> Hi,
> 
> The patch partially worked.  It removed all the "make all" errors but still 
> had the windows_nt.mk issue which made the "make all" create spurious 
> directories outside of the gnoga directory.  It also caused the sequence 
> "make all" => "make clean" => "make all" to fail on the second "make all" due 
> to some zanyblue conflicts.  "make install" still did not work.  I made the 
> two changes I discussed earlier:
> 
> 1.  fix the COPY, MKDIR, RMDIR, and DELETE commands
> cd deps/zanyblue/src/mkfile
> mv Windows_NT.mk Windows_NT.old
> cp unix.mk Windows_NT.mk
> 
> 2.  Fix make install
> changed tools/tools.gpr to have ".exe" appended to the executable names.
> 
> I've never made a diff before, so I might have messed this up, but I am 
> attaching my updated diff file for reference.
> 
> I don't know if these are good changes, but they are what worked for:
> Windows 10 Home
> mingw64, gcc 7.2 for x86_64-w64-mingw32
> gprbuild from Gnoga sourceforge site.
> 
> They may break things on other platforms or configurations.  And one comes 
> involves changing zanyblue files...so not sure how useful this is.
> 
> 
> On Sat, Nov 4, 2017 at 4:54 PM, Pascal via Gnoga-list 
>  wrote:
> Hello Jeremiah, see answers below.
> 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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Hello Jeremiah,

Normally GPRBuild cope with that:
2.2.7. Executable File Names
By default, the executable name corresponding to a main file is computed from 
the main source file name. Through the attribute Executable in package Builder, 
it is possible to change this default.
For instance, instead of building an executable named "proc" (or "proc.exe" on 
Windows), we could configure our project file to build proc1 (respectively 
proc1.exe) as follows:
project Build is
...  --  same as before
package Builder is
for Executable ("proc.adb") use "proc1";
end Builder
end Build;
Attribute Executable_Suffix, when specified, changes the suffix of the 
executable files when no attribute Executable applies: its value replaces the 
platform-specific executable suffix. The default executable suffix is the empty 
string empty on Unix and ".exe" on Windows.
(from 
https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/gnat_project_manager.html)

What is your GNAT version?
Could be a system detection issue in GPRBuild?

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


> Le 4 nov. 2017 à 21:28, Jeremiah Breeden  a écrit 
> :
> 
> Forgot to add.  So now "make all" works with all the changes I have gone 
> through.  The command "make install" still fails as I described in a separate 
> email chain a while back (couple of months maybe?).
> 
> In particular, to get "make install" to work, I have to modify 
> tools/tools.gpr and add ".exe" to both executable names:
> 
>package Builder is
>   for Executable ("gnoga_make-main.adb") use "gnoga_make.exe";
>   for Executable ("gnoga_doc-main.adb") use "gnoga_doc.exe";
>end Builder;
> 
> Otherwise make install fails with
> ---
> Install project Tools
> file D:\Program_Files\msys64\home\Jere\gnoga-code-2017_11_02\bin\gnoga_make 
> does not exist, build may not be complete
> make: *** [Makefile:202: install] Error 1
> ---
> 
> and a similar error for gnoga_doc
> 


--
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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Hello Jeremiah,

Can precise which version number for both 4/7 and 11/2?

It seems to me a make tool issue.
I'll ask Zanyblue author what is the configuration used for Windows.

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


> Le 4 nov. 2017 à 21:20, Jeremiah Breeden  a écrit 
> :
> 
> Ok, some progress.  It looks like for some reason it is picking windows_nt.mk 
> in the zanyblue/src/mkfile/ dir instead of unix.mk (for mingw64).  The major 
> problem is it wants to use "\" instead of "/" but "\" is also an escape 
> character in text strings and certain combinations work in commands and 
> others do not.  If I renamed windows_nt.mk to windows_nt.old and copied 
> unix.mk to windows_nt.mk
> 
> For whatever reason the version I downloaded on 4/7/2017 does not have this 
> problem.  I don't know if it picks unix.mt or something else occurs, but it 
> builds fine with that copy of gnoga.  I found out that the one I downloaded 
> on 11/2/2017 (the one I am having problems with) was trying to create a home 
> directory in a completely different spot due to the windows_nt.mk file 
> command format.  Since it was in the wrong location and the commands had "\" 
> in them the build wasn't working correctly.
> 
> So the question is what changed with zanyblue between 4/7 and 11/2?  I'm 
> curious if that was the cause of my "lib" issue earlier.  I'll need to start 
> over and check that out.


--
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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Hello Jeremiah, see answers below.
HTH, Pascal.
http://blady.pagesperso-orange.fr


> Le 4 nov. 2017 à 20:44, Jeremiah Breeden  a écrit 
> :
> 
> I tried your makefile change but it didn't work.  
Well I forgot some changes indeed, see previous e-mail with full patch.


> I did what Jeff Carter suggested and got through that step but now I am 
> failing on:
> 
> -
> cmd.exe /c "mkdir \home\Jere\gnoga-code-2017_11_02\build\lib\gnat"
> A subdirectory or file \home\Jere\gnoga-code-2017_11_02\build\lib\gnat 
> already exists.
> make[1]: *** [../src/mkfile/install.mk:93: 
> /home/Jere/gnoga-code-2017_11_02/build/lib/gnat/zanyblue.gpr] Error 1
> make[1]: Leaving directory 
> '/home/Jere/gnoga-code-2017_11_02/deps/zanyblue/src'
> make: *** [Makefile:145: zanyblue] Error 2
> -
> 
> I had similar errors for 
> \home\Jere\gnoga-code-2017_11_02\build\lib\zanyblue
> and 
> \home\Jere\gnoga-code-2017_11_02\build\include\zanyblue
> 
> Adding the directories for those last two seemed to placate the make (though 
> counter intuitive since the directories didn't exist), however that last one 
> does not go away.  Did something change in Zanyblue?  These type of errors 
> are new to me.
> 
> Just trying the command:   cmd.exe /c "mkdir 
> \home\Jere\gnoga-code-2017_11_02\build\lib\gnat"
> 
> manually leads to the same error.  I think it is a poorly formed command for 
> windows (the \ is probably interpreted as an escape)?  The directory isn't 
> actually there but it thinks it is for some reason.
> 
> Using unix style slashes makes the command work (manually) in mingw64.  I 
> have no clue how it works in cygwin.  I don't, however, know how to fix the 
> zanyblue compilation to use unix slashes instead.
> 
> So right now I am dead in the water for building until I can figure this part 
> out.  Still looking around though.

According the (complex) makefiles of Zanyblue, directories should only be 
created if they don't already exist with a rule as for instance:
$(INSTALL_INCDIR):
$(call MKDIR,$(INSTALL_INCDIR))

So I wonder about make tool, here is the one I get:
cmd$ make -v
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-apple-darwin11.3.0

What is yours?

> 
> 
> On Sat, Nov 4, 2017 at 5:50 AM, Pascal via Gnoga-list 
>  wrote:
> Thanks Jeremiah for reporting.
> 
> See some answers below.
> But in a general case,I need more information on what happened, can you send 
> attached full log?
> 
> Regards, Pascal.
> http://blady.pagesperso-orange.fr
> 
> 
> > Le 3 nov. 2017 à 01:02, Jeremiah Breeden  a 
> > écrit :
> >
> > Right now there are a lot of issues compiling with the following setup:
> >
> > Windows 10 64 bit
> > mingw64 (GCC 7.2)
> > "make all" command
> >
> > Issues so far:
> > 
> 
> >
> > 4.  zbtest failed to compile due to no xmlada library.  I stopped here.  
> > Prior to 1.3 I was able to do make all with this setup no problem.  I'm 
> > guessing xmlada is a new dependency?  Or perhaps the make file used to 
> > ignore?  not sure what to do here.
> 
> XMLAda lib is a default lib for GNAT GPL. I missed that. As zbtest is not 
> required for you, you can omit it:
> Gnoga Makefile change:
> 
> # Zanyblue with DEBUG on
> zanyblue:
> -   cd deps/zanyblue/src && $(MAKE) BUILD=Debug
> +   cd deps/zanyblue/src && $(MAKE) BUILD=Debug APPDIRS="zbmcompile 
> zbinfo"
> cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build install
> 
> 
> 
> --
> 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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Hi,

The patch partially worked.  It removed all the "make all" errors but still
had the windows_nt.mk issue which made the "make all" create spurious
directories outside of the gnoga directory.  It also caused the sequence
"make all" => "make clean" => "make all" to fail on the second "make all"
due to some zanyblue conflicts.  "make install" still did not work.  I made
the two changes I discussed earlier:

1.  fix the COPY, MKDIR, RMDIR, and DELETE commands
cd deps/zanyblue/src/mkfile
mv Windows_NT.mk Windows_NT.old
cp unix.mk Windows_NT.mk

2.  Fix make install
changed tools/tools.gpr to have ".exe" appended to the executable names.

I've never made a diff before, so I might have messed this up, but I am
attaching my updated diff file for reference.

I don't know if these are good changes, but they are what worked for:
Windows 10 Home
mingw64, gcc 7.2 for x86_64-w64-mingw32
gprbuild from Gnoga sourceforge site.

They may break things on other platforms or configurations.  And one comes
involves changing zanyblue files...so not sure how useful this is.


On Sat, Nov 4, 2017 at 4:54 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah, see answers below.
> HTH, Pascal.
> http://blady.pagesperso-orange.fr
>
>
>
>
diff --git a/Makefile b/Makefile
index ef21757..3a41ce7 100644
--- a/Makefile
+++ b/Makefile
@@ -132,6 +132,7 @@ simple_components:
$(INSTALLER) --prefix=$(CWD)/build --install-name=components 
deps/simple_components/lib_components.gpr -XAtomic_Access=${ATOMIC_ACCESS} 
-XLegacy=Ada2012
 
 lib/libsqlite3.a:
+   - $(MKDIR) lib
cd deps/simple_components/sqlite-sources && gcc -s -c -O2 -o sqlite3.o 
sqlite3.c
cd deps/simple_components/sqlite-sources && ar rcs libsqlite3.a 
sqlite3.o
cd deps/simple_components/sqlite-sources && $(MOVE) libsqlite3.a 
..$(PATHSEP)..$(PATHSEP)..$(PATHSEP)lib
@@ -141,8 +142,8 @@ sqlite3: lib/libsqlite3.a
 
 # Zanyblue with DEBUG on
 zanyblue:
-   cd deps/zanyblue/src && $(MAKE) BUILD=Debug
-   cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build install
+   cd deps/zanyblue/src && $(MAKE) BUILD=Debug APPDIRS="zbmcompile zbinfo"
+   cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build 
APPDIRS="zbmcompile zbinfo" install
 
 pragmarc:
$(BUILDER) -P deps/PragmARC/lib_pragmarc.gpr
@@ -197,7 +198,7 @@ release: deps $(BUILD_SQLITE3) setup basic_components
 install: release gnoga_tools
$(INSTALLER) --prefix=$(PREFIX) --install-name=components 
deps/simple_components/lib_components.gpr -XAtomic_Access=${ATOMIC_ACCESS} 
-XLegacy=Ada2012
 # TODO libsqlite3
-   $(MAKE) -C deps/zanyblue/src INSTALL_DIR=$(PREFIX) install
+   $(MAKE) -C deps/zanyblue/src INSTALL_DIR=$(PREFIX) APPDIRS="zbmcompile 
zbinfo" install
$(INSTALLER) --prefix=$(PREFIX) --install-name=pragmarc 
deps/PragmARC/lib_pragmarc.gpr
cd src && $(INSTALLER) --prefix=$(PREFIX) --install-name=gnoga 
gnoga.gpr -XPRJ_BUILD=Release -XPRJ_TARGET=${PRJ_TARGET}
cd tools && $(INSTALLER) --prefix=$(PREFIX) --install-name=gnoga 
--mode=usage tools.gpr -XPRJ_BUILD=Release -XPRJ_TARGET=${PRJ_TARGET}
@@ -206,7 +207,7 @@ install: release gnoga_tools
 install_debug:
$(INSTALLER) --prefix=$(PREFIX) --install-name=components 
deps/simple_components/lib_components.gpr -XAtomic_Access=${ATOMIC_ACCESS} 
-XLegacy=Ada2012
 # TODO libsqlite3
-   $(MAKE) -C deps/zanyblue/src INSTALL_DIR=$(PREFIX) BUILD=Debug install
+   $(MAKE) -C deps/zanyblue/src INSTALL_DIR=$(PREFIX) BUILD=Debug 
APPDIRS="zbmcompile zbinfo" install
$(INSTALLER) --prefix=$(PREFIX) --install-name=pragmarc 
deps/PragmARC/lib_pragmarc.gpr
cd src && $(INSTALLER) --prefix=$(PREFIX) --install-name=gnoga 
gnoga.gpr -XPRJ_TARGET=${PRJ_TARGET}
cd tools && $(INSTALLER) --prefix=$(PREFIX) --install-name=gnoga 
--mode=usage tools.gpr -XPRJ_TARGET=${PRJ_TARGET}
@@ -297,7 +298,7 @@ clean_all: clean clean_deps
 clean_deps:
$(CLEANER) -P deps/simple_components/lib_components.gpr
$(CLEANER) -P deps/PragmARC/lib_pragmarc.gpr
-   cd deps/zanyblue && $(MAKE) -C src clean
+   cd deps/zanyblue && $(MAKE) -C src APPDIRS="zbmcompile zbinfo" clean
$(RMS) build
cd deps && $(RMS) MultiMarkdown-4
cd deps && $(RMS) electron-quick-start
diff --git a/deps/zanyblue/src/mkfile/Windows_NT.mk 
b/deps/zanyblue/src/mkfile/Windows_NT.mk
index c9a3d6e..5bf39ca 100644
--- a/deps/zanyblue/src/mkfile/Windows_NT.mk
+++ b/deps/zanyblue/src/mkfile/Windows_NT.mk
@@ -1,67 +1,74 @@
-#  -*- coding: utf-8 -*-
-#
-#  ZanyBlue, an Ada library and framework for finite element analysis.
-#
-#  Copyright (c) 2012, 2016, Michael Rohan 
-#  All rights reserved.
-#
-#  Redistribution and use in source and binary forms, with or without
-#  modification, are permitted provided that the following conditions
-#  are met:
-#
-#* Redistributions of source code must retain the above copyright
-#  notice, this 

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeffrey R. Carter]

On 11/04/2017 12:18 PM, Pascal wrote:
> 
> My bad, more lines have to be changed in Gnoga makefile, see attached patch:

With that patch, make all proceeds successfully until tutorial_10.adb, and
trying to rebuild an existing application fails as before.

> Well sqlite3 is present as default on macOS.
> Isn't there some path from your Xubuntu libs to add to the linker?
> What is your target name (to add it in the supported ones)? Do make help.
> Gnoga makefile foresees building it but only for Windows.
> You can force to build it with:
> make sqlite3

I don't have sqlite3 and it was never needed before. Building the tutorials that
use it (10 and 11) failed before, but their failure didn't cause the overall
make to fail. The prior behavior seems desirable.

> You need to add installed component GPR paths with GPR_PROJECT_PATH, do make 
> help to take yours.

I don't understand this sentence. No additional action was needed before and I
don't see why it should be needed now.

> From the beginning Gnoga makes copying of components / plugins in src 
> directory, as Pixi is a new one in 1.3, it is not supported in 1.2.
> You need to remove it before from 1.3, do make clean_all.
> Well, I'm not satisfied by the actual behavior but I really not found a 
> better.

Removing them allows the make to finish. This hasn't arisen before because I
never had to go back to an earlier version.

-- 
Jeff Carter
"The men get one hot meal a day: a bowl of steam."
Take the Money and Run
145

--
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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Hello Jeremiah, see answers below.
HTH, Pascal.
http://blady.pagesperso-orange.fr


> Le 4 nov. 2017 à 19:20, Jeremiah Breeden  a écrit 
> :
> 
> Thanks for the reply.  Individual responses below.  Note that both the -g 
> switch and bin folder issues have existed in Gnoga for a long time.  I've 
> mentioned them before but figured since I was reporting back on other issues 
> to include them.
> 
> On Sat, Nov 4, 2017 at 5:50 AM, Pascal via Gnoga-list 
>  wrote:
> Thanks Jeremiah for reporting.
> 
> 
> 
> Seems that starting with a fresh empty working directory is needed in this 
> case then clone, checkout and make all.
> 
>  
> Well I always start with a fresh directory.  I get the .zip from sourceforge, 
> extract it to a new folder, move the old folder into my __old directory, and 
> then move in the new gnoga folder I just made.  Then I open up mingw64, cd to 
> my new gnoga directory and do make all.  I attached a file, lib_issue.txt, to 
> show the output.  The fix is to delete the file named "lib" (it is created by 
> gnoga's make all command..verified that), and manually create a lib directory 
> in the top level of my gnoga folder.

The lib file you got comes from sqlite build in Windows environment only:
cd deps/simple_components/sqlite-sources && mv libsqlite3.a ../../../lib
It should be move instead of mv and lib directory is not yet created. Thus it 
becomes a file.
I will add mkdir lib.

>  
> >
> > 2.  zbcom fails to build due to warnings treated as errors.  I removed the 
> > -g switch from zbcom.gpr to continue
> 
> What were the warnings?
> What about -g switch?
>  
> After the fix for the lib, I run the make all. I attached a file, 
> warnings_issue.txt, to illustrate.  The fix is to go into zbcom.gpr and 
> change one of the switches not to use -g.  Specifically:
> -gnatygO
> 
> is changed to
> 
> -gnatyO
> 
> I don't know if this is a good long term fix, but it gets the make going 
> again.

Yes the file zanyblue-os.adb is not the same for Windows and Unix.
So with Unix I didn't get the error.
I will report this issue to Zanyblue author.
In the meanwhile I will deactivate style checks.

> 
> 
> >
> > 3.  zbcomile fails because it cannot create the bin folder in zanyblue.  I 
> > manually added the binf file to continue
> 
> Maybe same as point 1.
> 
> I attached a file, bin_issue.txt, with the output.  Here, gnoga cannot create 
> a bin folder in  deps/zanyblue/
> If I add the folder manually, the make can continue.  Note that windows 10 
> cannot use chmod to modify permissions it seems (tried that first).  The 
> commond in mingw exists but doesn't fully work.
> 

Yes it's an issue with zbmcompile makefile, -p switch is missing for stampfile 
rule:
$(GPRBUILD) -p $(GNATFLAGS) -P $(APPNAME)

But this path "Need to regenerate the messages source files" should not append.
I will report this issue to Zanyblue author.
In the meanwhile I will deactivate stampfile check.

> 
> >
> > 4.  zbtest failed to compile due to no xmlada library.  I stopped here.  
> > Prior to 1.3 I was able to do make all with this setup no problem.  I'm 
> > guessing xmlada is a new dependency?  Or perhaps the make file used to 
> > ignore?  not sure what to do here.
> 
> XMLAda lib is a default lib for GNAT GPL. I missed that. As zbtest is not 
> required for you, you can omit it:
> Gnoga Makefile change:
> 
> # Zanyblue with DEBUG on
> zanyblue:
> -   cd deps/zanyblue/src && $(MAKE) BUILD=Debug
> +   cd deps/zanyblue/src && $(MAKE) BUILD=Debug APPDIRS="zbmcompile 
> zbinfo"
> cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build install
> 
> I'll try that out and get back with you.

Well, it's not enough, more lines need the same change.
I will make them.

> 
> 
> >
> > Right now, using Gnoga with FSF GNAT on windows has a lot of speed bumps.  
> > For now I am reverting back to 1.2 until I can figure it out.
> 
> Sorry for that, 1.3 is really worth while as it includes modal dialogs ;-)
> 
> Sorry, that sounded harsher than I meant.  I just meant that since I cannot 
> build gnoga for 1.3 yet I have to revert to 1.2 in my build environment until 
> I figure it out.  I still plan on trying to get gnoga to build for 1.3...just 
> had to shelve it for a day or two.

You are the very first one to report on Windows, it's a precious knowledge for 
me.
We will do it ;-)

Here is full patch:


patch_1.3.diff
Description: Binary data


Can you please test it?
I will push it to SF when ok on your side.

PS: I see your last e-mails, I will go on them tomorrow; lets go step by step, 
anyway many thanks ;-)


--
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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Forgot to add.  So now "make all" works with all the changes I have gone
through.  The command "make install" still fails as I described in a
separate email chain a while back (couple of months maybe?).

In particular, to get "make install" to work, I have to modify
tools/tools.gpr and add ".exe" to both executable names:

   package Builder is
  for Executable ("gnoga_make-main.adb") use "gnoga_make.exe";
  for Executable ("gnoga_doc-main.adb") use "gnoga_doc.exe";
   end Builder;

Otherwise make install fails with
---
Install project Tools
file D:\Program_Files\msys64\home\Jere\gnoga-code-2017_11_02\bin\gnoga_make
does not exist, build may not be complete
make: *** [Makefile:202: install] Error 1
---

and a similar error for gnoga_doc

On Sat, Nov 4, 2017 at 4:20 PM, Jeremiah Breeden  wrote:

> Ok, some progress.  It looks like for some reason it is picking
> windows_nt.mk in the zanyblue/src/mkfile/ dir instead of unix.mk (for
> mingw64).  The major problem is it wants to use "\" instead of "/" but "\"
> is also an escape character in text strings and certain combinations work
> in commands and others do not.  If I renamed windows_nt.mk to
> windows_nt.old and copied unix.mk to windows_nt.mk
>
> For whatever reason the version I downloaded on 4/7/2017 does not have
> this problem.  I don't know if it picks unix.mt or something else occurs,
> but it builds fine with that copy of gnoga.  I found out that the one I
> downloaded on 11/2/2017 (the one I am having problems with) was trying to
> create a home directory in a completely different spot due to the
> windows_nt.mk file command format.  Since it was in the wrong location
> and the commands had "\" in them the build wasn't working correctly.
>
> So the question is what changed with zanyblue between 4/7 and 11/2?  I'm
> curious if that was the cause of my "lib" issue earlier.  I'll need to
> start over and check that out.
>
>
--
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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Ok, some progress.  It looks like for some reason it is picking
windows_nt.mk in the zanyblue/src/mkfile/ dir instead of unix.mk (for
mingw64).  The major problem is it wants to use "\" instead of "/" but "\"
is also an escape character in text strings and certain combinations work
in commands and others do not.  If I renamed windows_nt.mk to
windows_nt.old and copied unix.mk to windows_nt.mk

For whatever reason the version I downloaded on 4/7/2017 does not have this
problem.  I don't know if it picks unix.mt or something else occurs, but it
builds fine with that copy of gnoga.  I found out that the one I downloaded
on 11/2/2017 (the one I am having problems with) was trying to create a
home directory in a completely different spot due to the windows_nt.mk file
command format.  Since it was in the wrong location and the commands had
"\" in them the build wasn't working correctly.

So the question is what changed with zanyblue between 4/7 and 11/2?  I'm
curious if that was the cause of my "lib" issue earlier.  I'll need to
start over and check that out.

On Sat, Nov 4, 2017 at 3:44 PM, Jeremiah Breeden  wrote:

> I tried your makefile change but it didn't work.  I did what Jeff Carter
> suggested and got through that step but now I am failing on:
>
> 
> -
> cmd.exe /c "mkdir \home\Jere\gnoga-code-2017_11_02\build\lib\gnat"
> A subdirectory or file \home\Jere\gnoga-code-2017_11_02\build\lib\gnat
> already exists.
> make[1]: *** [../src/mkfile/install.mk:93: /home/Jere/gnoga-code-2017_11_
> 02/build/lib/gnat/zanyblue.gpr] Error 1
> make[1]: Leaving directory '/home/Jere/gnoga-code-2017_
> 11_02/deps/zanyblue/src'
> make: *** [Makefile:145: zanyblue] Error 2
> 
> -
>
> I had similar errors for
> \home\Jere\gnoga-code-2017_11_02\build\lib\zanyblue
> and
> \home\Jere\gnoga-code-2017_11_02\build\include\zanyblue
>
> Adding the directories for those last two seemed to placate the make
> (though counter intuitive since the directories didn't exist), however that
> last one does not go away.  Did something change in Zanyblue?  These type
> of errors are new to me.
>
> Just trying the command:   cmd.exe /c "mkdir \home\Jere\gnoga-code-2017_11_
> 02\build\lib\gnat"
>
> manually leads to the same error.  I think it is a poorly formed command
> for windows (the \ is probably interpreted as an escape)?  The directory
> isn't actually there but it thinks it is for some reason.
>
> Using unix style slashes makes the command work (manually) in mingw64.  I
> have no clue how it works in cygwin.  I don't, however, know how to fix the
> zanyblue compilation to use unix slashes instead.
>
> So right now I am dead in the water for building until I can figure this
> part out.  Still looking around though.
>
>
> On Sat, Nov 4, 2017 at 5:50 AM, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> wrote:
>
>> Thanks Jeremiah for reporting.
>>
>> See some answers below.
>> But in a general case,I need more information on what happened, can you
>> send attached full log?
>>
>> Regards, Pascal.
>> http://blady.pagesperso-orange.fr
>>
>>
>> > Le 3 nov. 2017 à 01:02, Jeremiah Breeden 
>> a écrit :
>> >
>> > Right now there are a lot of issues compiling with the following setup:
>> >
>> > Windows 10 64 bit
>> > mingw64 (GCC 7.2)
>> > "make all" command
>> >
>> > Issues so far:
>> > 
>>
>> >
>> > 4.  zbtest failed to compile due to no xmlada library.  I stopped
>> here.  Prior to 1.3 I was able to do make all with this setup no problem.
>> I'm guessing xmlada is a new dependency?  Or perhaps the make file used to
>> ignore?  not sure what to do here.
>>
>> XMLAda lib is a default lib for GNAT GPL. I missed that. As zbtest is not
>> required for you, you can omit it:
>> Gnoga Makefile change:
>>
>> # Zanyblue with DEBUG on
>> zanyblue:
>> -   cd deps/zanyblue/src && $(MAKE) BUILD=Debug
>> +   cd deps/zanyblue/src && $(MAKE) BUILD=Debug APPDIRS="zbmcompile
>> zbinfo"
>> cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build install
>>
>>
>>
>
--
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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

I tried your makefile change but it didn't work.  I did what Jeff Carter
suggested and got through that step but now I am failing on:

-
cmd.exe /c "mkdir \home\Jere\gnoga-code-2017_11_02\build\lib\gnat"
A subdirectory or file \home\Jere\gnoga-code-2017_11_02\build\lib\gnat
already exists.
make[1]: *** [../src/mkfile/install.mk:93:
/home/Jere/gnoga-code-2017_11_02/build/lib/gnat/zanyblue.gpr] Error 1
make[1]: Leaving directory
'/home/Jere/gnoga-code-2017_11_02/deps/zanyblue/src'
make: *** [Makefile:145: zanyblue] Error 2
-

I had similar errors for
\home\Jere\gnoga-code-2017_11_02\build\lib\zanyblue
and
\home\Jere\gnoga-code-2017_11_02\build\include\zanyblue

Adding the directories for those last two seemed to placate the make
(though counter intuitive since the directories didn't exist), however that
last one does not go away.  Did something change in Zanyblue?  These type
of errors are new to me.

Just trying the command:   cmd.exe /c "mkdir
\home\Jere\gnoga-code-2017_11_02\build\lib\gnat"

manually leads to the same error.  I think it is a poorly formed command
for windows (the \ is probably interpreted as an escape)?  The directory
isn't actually there but it thinks it is for some reason.

Using unix style slashes makes the command work (manually) in mingw64.  I
have no clue how it works in cygwin.  I don't, however, know how to fix the
zanyblue compilation to use unix slashes instead.

So right now I am dead in the water for building until I can figure this
part out.  Still looking around though.


On Sat, Nov 4, 2017 at 5:50 AM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Thanks Jeremiah for reporting.
>
> See some answers below.
> But in a general case,I need more information on what happened, can you
> send attached full log?
>
> Regards, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> > Le 3 nov. 2017 à 01:02, Jeremiah Breeden  a
> écrit :
> >
> > Right now there are a lot of issues compiling with the following setup:
> >
> > Windows 10 64 bit
> > mingw64 (GCC 7.2)
> > "make all" command
> >
> > Issues so far:
> > 
>
> >
> > 4.  zbtest failed to compile due to no xmlada library.  I stopped here.
> Prior to 1.3 I was able to do make all with this setup no problem.  I'm
> guessing xmlada is a new dependency?  Or perhaps the make file used to
> ignore?  not sure what to do here.
>
> XMLAda lib is a default lib for GNAT GPL. I missed that. As zbtest is not
> required for you, you can omit it:
> Gnoga Makefile change:
>
> # Zanyblue with DEBUG on
> zanyblue:
> -   cd deps/zanyblue/src && $(MAKE) BUILD=Debug
> +   cd deps/zanyblue/src && $(MAKE) BUILD=Debug APPDIRS="zbmcompile
> zbinfo"
> cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build install
>
>
>
--
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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Thanks for the reply.  Individual responses below.  Note that both the -g
switch and bin folder issues have existed in Gnoga for a long time.  I've
mentioned them before but figured since I was reporting back on other
issues to include them.

On Sat, Nov 4, 2017 at 5:50 AM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Thanks Jeremiah for reporting.
>
> 
>
> Seems that starting with a fresh empty working directory is needed in this
> case then clone, checkout and make all.
>
>
Well I always start with a fresh directory.  I get the .zip from
sourceforge, extract it to a new folder, move the old folder into my __old
directory, and then move in the new gnoga folder I just made.  Then I open
up mingw64, cd to my new gnoga directory and do make all.  I attached a
file, lib_issue.txt, to show the output.  The fix is to delete the file
named "lib" (it is created by gnoga's make all command..verified that), and
manually create a lib directory in the top level of my gnoga folder.


> >
> > 2.  zbcom fails to build due to warnings treated as errors.  I removed
> the -g switch from zbcom.gpr to continue
>
> What were the warnings?
> What about -g switch?
>

After the fix for the lib, I run the make all. I attached a file,
warnings_issue.txt, to illustrate.  The fix is to go into zbcom.gpr and
change one of the switches not to use -g.  Specifically:
-gnatygO

is changed to

-gnatyO

I don't know if this is a good long term fix, but it gets the make going
again.


> >
> > 3.  zbcomile fails because it cannot create the bin folder in zanyblue.
> I manually added the binf file to continue
>
> Maybe same as point 1.
>

I attached a file, bin_issue.txt, with the output.  Here, gnoga cannot
create a bin folder in  deps/zanyblue/
If I add the folder manually, the make can continue.  Note that windows 10
cannot use chmod to modify permissions it seems (tried that first).  The
commond in mingw exists but doesn't fully work.


> >
> > 4.  zbtest failed to compile due to no xmlada library.  I stopped here.
> Prior to 1.3 I was able to do make all with this setup no problem.  I'm
> guessing xmlada is a new dependency?  Or perhaps the make file used to
> ignore?  not sure what to do here.
>
> XMLAda lib is a default lib for GNAT GPL. I missed that. As zbtest is not
> required for you, you can omit it:
> Gnoga Makefile change:
>
> # Zanyblue with DEBUG on
> zanyblue:
> -   cd deps/zanyblue/src && $(MAKE) BUILD=Debug
> +   cd deps/zanyblue/src && $(MAKE) BUILD=Debug APPDIRS="zbmcompile
> zbinfo"
> cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build install
>

I'll try that out and get back with you.


> >
> > Right now, using Gnoga with FSF GNAT on windows has a lot of speed
> bumps.  For now I am reverting back to 1.2 until I can figure it out.
>
> Sorry for that, 1.3 is really worth while as it includes modal dialogs ;-)
>

Sorry, that sounded harsher than I meant.  I just meant that since I cannot
build gnoga for 1.3 yet I have to revert to 1.2 in my build environment
until I figure it out.  I still plan on trying to get gnoga to build for
1.3...just had to shelve it for a day or two.
$ make all
gprbuild -p --target=x86_64-w64-mingw32 -P 
deps/simple_components/lib_components.gpr -XAtomic_Access=GCC-long-offsets 
-XLegacy=Ada2012
"libcomponents.a" up to date
gprinstall -p -f --target=x86_64-w64-mingw32 
--prefix=/home/Jere/gnoga-code-2017_11_02/build --install-name=components 
deps/simple_components/lib_components.gpr -XAtomic_Access=GCC-long-offsets 
-XLegacy=Ada2012
Install project Lib_Components
warning: path does not exist 
'd:\program_files\msys64\home\jere\gnoga-code-2017_11_02\deps\simple_components\obj/components/static/gnatdoc/'
make -C src
make[1]: Entering directory '/home/Jere/gnoga-code-2017_11_02/src'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/Jere/gnoga-code-2017_11_02/src'
make -C components
make[1]: Entering directory '/home/Jere/gnoga-code-2017_11_02/components'
make -C bootstrap install
make[2]: Entering directory 
'/home/Jere/gnoga-code-2017_11_02/components/bootstrap'
cp -p src/*.* ../../src
cp -p css/*.* ../../css
cp -p html/*.* ../../html
mkdir ../../html/fonts
mkdir: cannot create directory ‘../../html/fonts’: File exists
make[2]: [Makefile:19: install] Error 1 (ignored)
cp -p html/fonts/*.* ../../html/fonts
cp -p js/*.* ../../js
make[2]: Leaving directory 
'/home/Jere/gnoga-code-2017_11_02/components/bootstrap'
make -C jqueryui install
make[2]: Entering directory 
'/home/Jere/gnoga-code-2017_11_02/components/jqueryui'
cp -p src/*.* ../../src
cp -p css/*.* ../../css
cp -p html/*.* ../../html
mkdir ../../css/images
mkdir: cannot create directory ‘../../css/images’: File exists
make[2]: [Makefile:19: install] Error 1 (ignored)
cp -p css/images/*.* ../../css/images
cp -p js/*.* ../../js
make[2]: Leaving directory 
'/home/Jere/gnoga-code-2017_11_02/components/jqueryui'
make -C message_boxes install
make[2]: Entering directory 
'/home/Jere

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Thanks Jeff for logs.
See some answers below.
Regards, Pascal.
http://blady.pagesperso-orange.fr


> Le 4 nov. 2017 à 11:31, Jeffrey R. Carter  a écrit :
> 
> On 11/04/2017 10:32 AM, Pascal via Gnoga-list wrote:
>> Version 1.3 was in beta since the 16th of July.
>> You were the very first to report on it.
>> Feedback is obviously needed good or bad as I can only make test with macOS 
>> environment on my side.
>> Version 1.3a has been cancelled until I understand what it was bad.
> 
> I have been sticking with the release version and upgrading when new releases 
> were made.
> 
>> I need more information on what happened, can you please send attached full 
>> log and changes you made?
> 
> I'm using Xubuntu 17.10, which provides GNAT 7.2.0. I'm not sure where the 
> log is to attach. Starting from scratch:
> 
> $ git clone git://git.code.sf.net/p/gnoga/code gnoga2
> Cloning into 'gnoga2'...
> remote: Counting objects: 15923, done.
> remote: Compressing objects: 100% (5815/5815), done.
> remote: Total 15923 (delta 11199), reused 14125 (delta 9761)
> Receiving objects: 100% (15923/15923), 28.73 MiB | 1.56 MiB/s, done.
> Resolving deltas: 100% (11199/11199), done.
> $ cd gnoga2/
> $ git checkout dev_1.3
> Branch dev_1.3 set up to track remote branch dev_1.3 from origin.
> Switched to a new branch 'dev_1.3'
> jrcarter@jrcarter-Inspiron-15:~/Code/gnoga2$ make all
> ...
> ZBMCompile completed on 11/4/17 at 11:07 AM, elapsed time 0:00:01.645
> gprbuild -p -XOS=unix -XTYPE=static -XBUILD=Debug -XV_MAJOR=1 -XV_MINOR=3 
> -XV_PATCH=0 -XV_STATUS=Beta -aP../../lib/gnat -aP../../src -P zbtest
> zbtest.gpr:36:06: unknown project file: "xmlada"
> gprbuild: "zbtest" processing failed
> Makefile:72: recipe for target 'all' failed
> make[2]: *** [all] Error 4
> make[2]: Leaving directory 
> '/home/jrcarter/Code/gnoga2/deps/zanyblue/src/zbtest'
> Makefile:113: recipe for target 'zbtest.app' failed
> make[1]: *** [zbtest.app] Error 2
> make[1]: Leaving directory '/home/jrcarter/Code/gnoga2/deps/zanyblue/src'
> Makefile:144: recipe for target 'zanyblue' failed
> make: *** [zanyblue] Error 2
> 
> Modifying Makefile as you suggested in your msg of 2017-11-01, make all gives 
> the same error.
> 
> Modifying deps/zanyblue/src/Makefile to have
> 
> APPDIRS=zbmcompile zbinfo

My bad, more lines have to be changed in Gnoga makefile, see attached patch:


patch_mf.diff
Description: Binary data

> 
> make all fails building tutorial 10 because -lsqlite3 is not present, as 
> expected. Earlier tutorials build OK.

Well sqlite3 is present as default on macOS.
Isn't there some path from your Xubuntu libs to add to the linker?
What is your target name (to add it in the supported ones)? Do make help.
Gnoga makefile foresees building it but only for Windows.
You can force to build it with:
make sqlite3

> 
> Trying to rebuild an existing application gives
> 
> gnoga.gpr:2:06: unknown project file: "lib_components.gpr"
> gnoga.gpr:2:06: imported by "/home/jrcarter/Code/gnoga/src/gnoga.gpr"
> gnoga.gpr:2:06: imported by "/home/jrcarter/Code/Devil/devil.gpr"
> gprbuild: "devil" processing failed

You need to add installed component GPR paths with GPR_PROJECT_PATH, do make 
help to take yours.

> 
> I note that after trying to build 1.3, checking out master and doing make 
> fails on gnoga-gui-plugin-pixi.adb with
> 
> gnoga-gui-plugin-pixi.adb:111:80: (style) this line is too long
> gnoga-gui-plugin-pixi.adb:115:80: (style) this line is too long
> gnoga-gui-plugin-pixi.adb:116:80: (style) this line is too long
> gnoga-gui-plugin-pixi.adb:122:80: (style) this line is too long
> gnoga-gui-plugin-pixi.adb:123:80: (style) this line is too long
> gnoga-gui-plugin-pixi.adb:899:12: ambiguous call to "Property"
> gnoga-gui-plugin-pixi.adb:899:12: possible interpretation at 
> gnoga-gui-plugin-pixi.ads:234
> gnoga-gui-plugin-pixi.adb:899:12: possible interpretation at 
> gnoga-gui-plugin-pixi.ads:234
> gnoga-gui-plugin-pixi.adb:899:54: "Image" not declared in "Element"
> gnoga-gui-plugin-pixi.adb:910:31: "Value" not declared in "Element"
> gnoga-gui-plugin-pixi.ads:47:80: (style) this line is too long
> gnoga-gui-plugin-pixi.ads:49:80: (style) this line is too long
> gnoga-gui-plugin-pixi.ads:50:80: (style) this line is too long
> gnoga-gui-plugin-pixi.ads:157:80: (style) this line is too long
> gnoga-gui-plugin-pixi.ads:193:80: (style) this line is too long
> gnoga-gui-plugin-pixi.ads:204:80: (style) this line is too long
> gnoga-gui-plugin-pixi.ads:228:80: (style) this line is too long
> gnoga-gui-plugin-pixi.ads:308:80: (style) this line is too long
> gnoga-gui-plugin-pixi.ads:309:80: (style) this line is too long
> gnoga-gui-plugin-pixi.ads:314:80: (style) this line is too long
> gnoga-gui-plugin-pixi.ads:318:80: (style) this line is too long
> gnoga-gui-plugin-pixi.ads:364:80: (style) this line is too long
> gnoga-gui-plugin-pixi.ads:377:80: (style) this line is too long
> gnoga-gui-plugin-pixi.ads:383:80: (style) this line is too long
> gnoga-gui

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeffrey R. Carter]

On 11/04/2017 10:32 AM, Pascal via Gnoga-list wrote:
> Version 1.3 was in beta since the 16th of July.
> You were the very first to report on it.
> Feedback is obviously needed good or bad as I can only make test with macOS 
> environment on my side.
> Version 1.3a has been cancelled until I understand what it was bad.

I have been sticking with the release version and upgrading when new releases 
were made.

> I need more information on what happened, can you please send attached full 
> log and changes you made?

I'm using Xubuntu 17.10, which provides GNAT 7.2.0. I'm not sure where the log 
is to attach. Starting from scratch:

$ git clone git://git.code.sf.net/p/gnoga/code gnoga2
Cloning into 'gnoga2'...
remote: Counting objects: 15923, done.
remote: Compressing objects: 100% (5815/5815), done.
remote: Total 15923 (delta 11199), reused 14125 (delta 9761)
Receiving objects: 100% (15923/15923), 28.73 MiB | 1.56 MiB/s, done.
Resolving deltas: 100% (11199/11199), done.
$ cd gnoga2/
$ git checkout dev_1.3
Branch dev_1.3 set up to track remote branch dev_1.3 from origin.
Switched to a new branch 'dev_1.3'
jrcarter@jrcarter-Inspiron-15:~/Code/gnoga2$ make all
...
ZBMCompile completed on 11/4/17 at 11:07 AM, elapsed time 0:00:01.645
gprbuild -p -XOS=unix -XTYPE=static -XBUILD=Debug -XV_MAJOR=1 -XV_MINOR=3 
-XV_PATCH=0 -XV_STATUS=Beta -aP../../lib/gnat -aP../../src -P zbtest
zbtest.gpr:36:06: unknown project file: "xmlada"
gprbuild: "zbtest" processing failed
Makefile:72: recipe for target 'all' failed
make[2]: *** [all] Error 4
make[2]: Leaving directory '/home/jrcarter/Code/gnoga2/deps/zanyblue/src/zbtest'
Makefile:113: recipe for target 'zbtest.app' failed
make[1]: *** [zbtest.app] Error 2
make[1]: Leaving directory '/home/jrcarter/Code/gnoga2/deps/zanyblue/src'
Makefile:144: recipe for target 'zanyblue' failed
make: *** [zanyblue] Error 2

Modifying Makefile as you suggested in your msg of 2017-11-01, make all gives 
the same error.

Modifying deps/zanyblue/src/Makefile to have

APPDIRS=zbmcompile zbinfo

make all fails building tutorial 10 because -lsqlite3 is not present, as 
expected. Earlier tutorials build OK.

Trying to rebuild an existing application gives

gnoga.gpr:2:06: unknown project file: "lib_components.gpr"
gnoga.gpr:2:06: imported by "/home/jrcarter/Code/gnoga/src/gnoga.gpr"
gnoga.gpr:2:06: imported by "/home/jrcarter/Code/Devil/devil.gpr"
gprbuild: "devil" processing failed

I note that after trying to build 1.3, checking out master and doing make fails 
on gnoga-gui-plugin-pixi.adb with

gnoga-gui-plugin-pixi.adb:111:80: (style) this line is too long
gnoga-gui-plugin-pixi.adb:115:80: (style) this line is too long
gnoga-gui-plugin-pixi.adb:116:80: (style) this line is too long
gnoga-gui-plugin-pixi.adb:122:80: (style) this line is too long
gnoga-gui-plugin-pixi.adb:123:80: (style) this line is too long
gnoga-gui-plugin-pixi.adb:899:12: ambiguous call to "Property"
gnoga-gui-plugin-pixi.adb:899:12: possible interpretation at 
gnoga-gui-plugin-pixi.ads:234
gnoga-gui-plugin-pixi.adb:899:12: possible interpretation at 
gnoga-gui-plugin-pixi.ads:234
gnoga-gui-plugin-pixi.adb:899:54: "Image" not declared in "Element"
gnoga-gui-plugin-pixi.adb:910:31: "Value" not declared in "Element"
gnoga-gui-plugin-pixi.ads:47:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:49:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:50:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:157:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:193:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:204:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:228:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:308:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:309:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:314:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:318:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:364:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:377:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:383:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:456:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:457:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:458:80: (style) this line is too long
gnoga-gui-plugin-pixi.ads:464:80: (style) this line is too long
gprbuild: *** compilation phase failed
Makefile:90: recipe for target 'gnoga' failed
make: *** [gnoga] Error 4

This succeeds on a fresh install.

HTH

-- 
Jeff Carter
"Sir Lancelot saves Sir Gallahad from almost certain temptation."
Monty Python & the Holy Grail
69



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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Thanks Jeremiah for reporting.

See some answers below.
But in a general case,I need more information on what happened, can you send 
attached full log?

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


> Le 3 nov. 2017 à 01:02, Jeremiah Breeden  a écrit 
> :
> 
> Right now there are a lot of issues compiling with the following setup:
> 
> Windows 10 64 bit
> mingw64 (GCC 7.2)
> "make all" command
> 
> Issues so far:
> 1.  fails to compile because it cannot make the ./lib directory.  When I 
> looked at the directory structure there existed a file named "lib" with no 
> extension.  Windows cannot have both a file and a directory named lib.  I 
> deleted the file to continue

Seems that starting with a fresh empty working directory is needed in this case 
then clone, checkout and make all.

> 
> 2.  zbcom fails to build due to warnings treated as errors.  I removed the -g 
> switch from zbcom.gpr to continue

What were the warnings?
What about -g switch?

> 
> 3.  zbcomile fails because it cannot create the bin folder in zanyblue.  I 
> manually added the binf file to continue

Maybe same as point 1.

> 
> 4.  zbtest failed to compile due to no xmlada library.  I stopped here.  
> Prior to 1.3 I was able to do make all with this setup no problem.  I'm 
> guessing xmlada is a new dependency?  Or perhaps the make file used to 
> ignore?  not sure what to do here.

XMLAda lib is a default lib for GNAT GPL. I missed that. As zbtest is not 
required for you, you can omit it:
Gnoga Makefile change:

# Zanyblue with DEBUG on
zanyblue:
-   cd deps/zanyblue/src && $(MAKE) BUILD=Debug
+   cd deps/zanyblue/src && $(MAKE) BUILD=Debug APPDIRS="zbmcompile zbinfo"
cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build install

> 
> Right now, using Gnoga with FSF GNAT on windows has a lot of speed bumps.  
> For now I am reverting back to 1.2 until I can figure it out.

Sorry for that, 1.3 is really worth while as it includes modal dialogs ;-)

> 
> Anyone else having similar problems?

Many feedbacks are really needed to improve portability across environments.

> 
> 
> On Wed, Nov 1, 2017 at 6:40 AM, Pascal via Gnoga-list 
>  wrote:
> Hello,
> 
> Version 1.3a has been released on SF GIT dev_1.3 branch.
> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/
> 
> See HISTORY for details.
> 
> This branch is now the default one.
> 
> Source code has been zipped (gnoga-1.3a.zip) available on:
> https://sourceforge.net/projects/gnoga/files/
> 
> Then new branch dev_1.4 has been created to collect new developments, see 
> TODO:
> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/TODO
> 
> Feel free to report detailed issues on this list or create tickets on SF:
> https://sourceforge.net/p/gnoga/mailman/
> https://sourceforge.net/p/gnoga/tickets/
> 
> 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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Thanks Jeff for reporting.

Version 1.3 was in beta since the 16th of July.
You were the very first to report on it.
Feedback is obviously needed good or bad as I can only make test with macOS 
environment on my side.
Version 1.3a has been cancelled until I understand what it was bad.

I need more information on what happened, can you please send attached full log 
and changes you made?

PS: I really enjoy Bertrand Meyer quote.

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


> Le 2 nov. 2017 à 20:27, Jeffrey R. Carter  a écrit :
> 
> On 11/02/2017 08:15 PM, Pascal via Gnoga-list wrote:
>> I remember you wrote that you made git pull.
>> That does not clean unused files that are obsolete.
>> I suggest you to start from a fresh new directory and then do a git clone 
>> and then a git checkout before make all.
> 
> A minor version release shouldn't require such drastic actions. Sounds as if 
> 1.3 is still beta.
> 
> -- 
> Jeff Carter
> "I've seen projects fail miserably for blindly
> applying the Agile catechism: we're Agile, we
> don't need to stop and think, we just go ahead
> and code!"
> Bertrand Meyer
> 150


--
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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Ugg...I must have been tired last night.

For #3 I meant zbcompile fails and that I manually added the bin folder

On Thu, Nov 2, 2017 at 8:02 PM, Jeremiah Breeden  wrote:

> Right now there are a lot of issues compiling with the following setup:
>
> Windows 10 64 bit
> mingw64 (GCC 7.2)
> "make all" command
>
> Issues so far:
> 1.  fails to compile because it cannot make the ./lib directory.  When I
> looked at the directory structure there existed a file named "lib" with no
> extension.  Windows cannot have both a file and a directory named lib.  I
> deleted the file to continue
>
> 2.  zbcom fails to build due to warnings treated as errors.  I removed the
> -g switch from zbcom.gpr to continue
>
> 3.  zbcomile fails because it cannot create the bin folder in zanyblue.  I
> manually added the binf file to continue
>
> 4.  zbtest failed to compile due to no xmlada library.  I stopped here.
> Prior to 1.3 I was able to do make all with this setup no problem.  I'm
> guessing xmlada is a new dependency?  Or perhaps the make file used to
> ignore?  not sure what to do here.
>
> Right now, using Gnoga with FSF GNAT on windows has a lot of speed bumps.
> For now I am reverting back to 1.2 until I can figure it out.
>
> Anyone else having similar problems?
>
>
> On Wed, Nov 1, 2017 at 6:40 AM, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> wrote:
>
>> Hello,
>>
>> Version 1.3a has been released on SF GIT dev_1.3 branch.
>> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/
>>
>> See HISTORY for details.
>>
>> This branch is now the default one.
>>
>> Source code has been zipped (gnoga-1.3a.zip) available on:
>> https://sourceforge.net/projects/gnoga/files/
>>
>> Then new branch dev_1.4 has been created to collect new developments, see
>> TODO:
>> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/TODO
>>
>> Feel free to report detailed issues on this list or create tickets on SF:
>> https://sourceforge.net/p/gnoga/mailman/
>> https://sourceforge.net/p/gnoga/tickets/
>>
>> 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
>>
>
>
--
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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Forgot to add I manually created the lib directory afterwards as well.

On Thu, Nov 2, 2017 at 8:02 PM, Jeremiah Breeden  wrote:

> 1.  fails to compile because it cannot make the ./lib directory.  When I
> looked at the directory structure there existed a file named "lib" with no
> extension.  Windows cannot have both a file and a directory named lib.  I
> deleted the file to continue
>
--
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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

I missed an earlier email.  Seems like the xml ada thing is already being
discussed.

On Thu, Nov 2, 2017 at 8:02 PM, Jeremiah Breeden  wrote:

> Right now there are a lot of issues compiling with the following setup:
>
> 
>
> 4.  zbtest failed to compile due to no xmlada library.  I stopped here.
> Prior to 1.3 I was able to do make all with this setup no problem.  I'm
> guessing xmlada is a new dependency?  Or perhaps the make file used to
> ignore?  not sure what to do here.
>
>
>
--
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] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Right now there are a lot of issues compiling with the following setup:

Windows 10 64 bit
mingw64 (GCC 7.2)
"make all" command

Issues so far:
1.  fails to compile because it cannot make the ./lib directory.  When I
looked at the directory structure there existed a file named "lib" with no
extension.  Windows cannot have both a file and a directory named lib.  I
deleted the file to continue

2.  zbcom fails to build due to warnings treated as errors.  I removed the
-g switch from zbcom.gpr to continue

3.  zbcomile fails because it cannot create the bin folder in zanyblue.  I
manually added the binf file to continue

4.  zbtest failed to compile due to no xmlada library.  I stopped here.
Prior to 1.3 I was able to do make all with this setup no problem.  I'm
guessing xmlada is a new dependency?  Or perhaps the make file used to
ignore?  not sure what to do here.

Right now, using Gnoga with FSF GNAT on windows has a lot of speed bumps.
For now I am reverting back to 1.2 until I can figure it out.

Anyone else having similar problems?


On Wed, Nov 1, 2017 at 6:40 AM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello,
>
> Version 1.3a has been released on SF GIT dev_1.3 branch.
> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/
>
> See HISTORY for details.
>
> This branch is now the default one.
>
> Source code has been zipped (gnoga-1.3a.zip) available on:
> https://sourceforge.net/projects/gnoga/files/
>
> Then new branch dev_1.4 has been created to collect new developments, see
> TODO:
> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/TODO
>
> Feel free to report detailed issues on this list or create tickets on SF:
> https://sourceforge.net/p/gnoga/mailman/
> https://sourceforge.net/p/gnoga/tickets/
>
> 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
>
--
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] Version 1.3a released and version 1.4-alpha created.

[Jeffrey R. Carter]

On 11/02/2017 08:15 PM, Pascal via Gnoga-list wrote:
> I remember you wrote that you made git pull.
> That does not clean unused files that are obsolete.
> I suggest you to start from a fresh new directory and then do a git clone and 
> then a git checkout before make all.

A minor version release shouldn't require such drastic actions. Sounds as if 
1.3 is still beta.

-- 
Jeff Carter
"I've seen projects fail miserably for blindly
applying the Agile catechism: we're Agile, we
don't need to stop and think, we just go ahead
and code!"
Bertrand Meyer
150


--
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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Hello Jeff,

It comes you've probably let some old ali files in read-only mode in your 
working directory.
You should have them deleted before.

Missing lib_components.gpr is more suspicious.

I remember you wrote that you made git pull.
That does not clean unused files that are obsolete.
I suggest you to start from a fresh new directory and then do a git clone and 
then a git checkout before make all.

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


> Le 1 nov. 2017 à 22:26, Jeffrey R. Carter  a écrit :
> 
> With that change, "make all" fails when building Snake with
> 
> Bind
>   [gprbind]  snake-main.bexch
>   [Ada]  snake-main.ali
> error: "gnat-sockets-connection_state_machine.adb" must be compiled
> error: 
> ("/home/jrcarter/Code/gnoga/lib/gnat-sockets-connection_state_machine.ali" is 
> obsolete and read-only)
> error: "gnat-sockets-server.adb" must be compiled
> error: ("/home/jrcarter/Code/gnoga/lib/gnat-sockets-server.ali" is obsolete 
> and read-only)
> error: "gnat-sockets-connection_state_machine-http_server.adb" must be 
> compiled
> error: 
> ("/home/jrcarter/Code/gnoga/lib/gnat-sockets-connection_state_machine-http_server.ali"
>  is obsolete and read-only)
> error: "gnat-sockets-connection_state_machine-big_endian.ads" must be compiled
> error: 
> ("/home/jrcarter/Code/gnoga/lib/gnat-sockets-connection_state_machine-big_endian.ali"
>  is obsolete and read-only)
> error: "gnat-sockets-connection_state_machine-big_endian-unsigneds.adb" must 
> be compiled
> error: 
> ("/home/jrcarter/Code/gnoga/lib/gnat-sockets-connection_state_machine-big_endian-unsigneds.ali"
>  is obsolete and read-only)
> error: "gnat-sockets-connection_state_machine-expected_sequence.adb" must be 
> compiled
> error: 
> ("/home/jrcarter/Code/gnoga/lib/gnat-sockets-connection_state_machine-expected_sequence.ali"
>  is obsolete and read-only)
> error: "gnat-sockets-connection_state_machine-terminated_strings.adb" must be 
> compiled
> error: 
> ("/home/jrcarter/Code/gnoga/lib/gnat-sockets-connection_state_machine-terminated_strings.ali"
>  is obsolete and read-only)
> gprbind: invocation of gnatbind failed
> gprbuild: unable to bind snake-main.adb
> Makefile:232: recipe for target 'snake' failed
> make: *** [snake] Error 4
> 
> Presuming I don't need Snake built to use Gnoga, I tried to build an existing 
> application and got
> 
> gnoga.gpr:2:06: unknown project file: "lib_components.gpr"
> gnoga.gpr:2:06: imported by "/home/jrcarter/Code/gnoga/src/gnoga.gpr"
> gnoga.gpr:2:06: imported by "/home/jrcarter/Code/Devil/devil.gpr"
> gprbuild: "devil" processing failed
> 
> -- 
> Jeff Carter
> "Monsieur Arthur King, who has the brain of a duck, you know."
> Monty Python & the Holy Grail
> 09


--
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] Version 1.3a released and version 1.4-alpha created.

[Jeffrey R. Carter]

On 11/01/2017 09:13 PM, Pascal via Gnoga-list wrote:
> You're right version 1.1 and 1.2 are on branch master then checkout is not 
> needed after git pull.
> If you think it's easier then branch dev_1.3 could be merged with master.
> But it would be more complex to make changes on 1.2.
> Though there weren't any changes on 1.1.
> What do you think?

It does seem to me that master should continue to be the current version.

> Thus, either you can get GNAT GPL or xmlada lib from libre AdaCore web site 
> or deactivate zbtest build with Gnoga Makefile change:
>
>  # Zanyblue with DEBUG on
>  zanyblue:
> - cd deps/zanyblue/src && $(MAKE) BUILD=Debug
> + cd deps/zanyblue/src && $(MAKE) BUILD=Debug APPDIRS="zbmcompile zbinfo"
>   cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build install
>
> Please let's know how it goes.

With that change, "make all" fails when building Snake with

Bind
   [gprbind]  snake-main.bexch
   [Ada]  snake-main.ali
error: "gnat-sockets-connection_state_machine.adb" must be compiled
error: 
("/home/jrcarter/Code/gnoga/lib/gnat-sockets-connection_state_machine.ali" is 
obsolete and read-only)
error: "gnat-sockets-server.adb" must be compiled
error: ("/home/jrcarter/Code/gnoga/lib/gnat-sockets-server.ali" is obsolete and 
read-only)
error: "gnat-sockets-connection_state_machine-http_server.adb" must be compiled
error: 
("/home/jrcarter/Code/gnoga/lib/gnat-sockets-connection_state_machine-http_server.ali"
 is obsolete and read-only)
error: "gnat-sockets-connection_state_machine-big_endian.ads" must be compiled
error: 
("/home/jrcarter/Code/gnoga/lib/gnat-sockets-connection_state_machine-big_endian.ali"
 is obsolete and read-only)
error: "gnat-sockets-connection_state_machine-big_endian-unsigneds.adb" must be 
compiled
error: 
("/home/jrcarter/Code/gnoga/lib/gnat-sockets-connection_state_machine-big_endian-unsigneds.ali"
 is obsolete and read-only)
error: "gnat-sockets-connection_state_machine-expected_sequence.adb" must be 
compiled
error: 
("/home/jrcarter/Code/gnoga/lib/gnat-sockets-connection_state_machine-expected_sequence.ali"
 is obsolete and read-only)
error: "gnat-sockets-connection_state_machine-terminated_strings.adb" must be 
compiled
error: 
("/home/jrcarter/Code/gnoga/lib/gnat-sockets-connection_state_machine-terminated_strings.ali"
 is obsolete and read-only)
gprbind: invocation of gnatbind failed
gprbuild: unable to bind snake-main.adb
Makefile:232: recipe for target 'snake' failed
make: *** [snake] Error 4

Presuming I don't need Snake built to use Gnoga, I tried to build an existing 
application and got

gnoga.gpr:2:06: unknown project file: "lib_components.gpr"
gnoga.gpr:2:06: imported by "/home/jrcarter/Code/gnoga/src/gnoga.gpr"
gnoga.gpr:2:06: imported by "/home/jrcarter/Code/Devil/devil.gpr"
gprbuild: "devil" processing failed

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09



--
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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Hello Jeff,

You're right version 1.1 and 1.2 are on branch master then checkout is not 
needed after git pull.
If you think it's easier then branch dev_1.3 could be merged with master.
But it would be more complex to make changes on 1.2.
Though there weren't any changes on 1.1.
What do you think?

Regarding make failure, it comes from xmlada lib which is available with GNAT 
GPL and not with your GNAT, I guess.
It's an old issue that I forgot from version 1.1.
David position was:
"I've modified zanyblue to separate the applications and tests, the tests rely 
on xmlada and other packages that Gnoga is designed specifically to exclude."

Thus, either you can get GNAT GPL or xmlada lib from libre AdaCore web site or 
deactivate zbtest build with Gnoga Makefile change:

 # Zanyblue with DEBUG on
 zanyblue:
-   cd deps/zanyblue/src && $(MAKE) BUILD=Debug
+   cd deps/zanyblue/src && $(MAKE) BUILD=Debug APPDIRS="zbmcompile zbinfo"
cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build install

Please let's know how it goes.

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


> Le 1 nov. 2017 à 20:06, Jeffrey R. Carter  a écrit :
> 
> On 11/01/2017 07:03 PM, Pascal via Gnoga-list wrote:
>> When you clone with GIT you have to checkout the wanted branch, for instance:
>> $ git checkout dev_1.3
>> or a particular label:
>> $ git checkout V1.3a
> 
> Perhaps I remember incorrectly, but I thought that 1.1 and 1.2 simply needed 
> a "git pull" to become the checked-out branch, and I expected the same for 
> 1.3.
> 
> Checking out V1.3a gives
> 
> $ git checkout V1.3a
> Note: checking out 'V1.3a'.
> 
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
> 
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
> 
>  git checkout -b 
> 
> HEAD is now at bb4b7329... Gnoga 1.3a released; TODO, HISTORY and TIPS 
> updated; Documentation_Dir obsolescence fixed and miscellaneous fixes.
> 
> and "make all" fails with
> 
> gprbuild -p -XOS=unix -XTYPE=static -XBUILD=Debug -XV_MAJOR=1 -XV_MINOR=3 
> -XV_PATCH=0 -XV_STATUS=Beta -aP../../lib/gnat -aP../../src -P zbtest
> zbtest.gpr:36:06: unknown project file: "xmlada"
> gprbuild: "zbtest" processing failed
> Makefile:72: recipe for target 'all' failed
> make[2]: *** [all] Error 4
> make[2]: Leaving directory 
> '/home/jrcarter/Code/gnoga/deps/zanyblue/src/zbtest'
> Makefile:113: recipe for target 'zbtest.app' failed
> make[1]: *** [zbtest.app] Error 2
> make[1]: Leaving directory '/home/jrcarter/Code/gnoga/deps/zanyblue/src'
> Makefile:144: recipe for target 'zanyblue' failed
> make: *** [zanyblue] Error 2
> 
> "git checkout dev_1.3" works better, but fails in the same way.
> 
> -- 
> Jeff Carter
> "Monsieur Arthur King, who has the brain of a duck, you know."
> Monty Python & the Holy Grail
> 09
> 
> 
> 
> --
> 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] Version 1.3a released and version 1.4-alpha created.

[Jeffrey R. Carter]

On 11/01/2017 07:03 PM, Pascal via Gnoga-list wrote:
> When you clone with GIT you have to checkout the wanted branch, for instance:
> $ git checkout dev_1.3
> or a particular label:
> $ git checkout V1.3a

Perhaps I remember incorrectly, but I thought that 1.1 and 1.2 simply needed a 
"git pull" to become the checked-out branch, and I expected the same for 1.3.

Checking out V1.3a gives

$ git checkout V1.3a
Note: checking out 'V1.3a'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b 

HEAD is now at bb4b7329... Gnoga 1.3a released; TODO, HISTORY and TIPS updated; 
Documentation_Dir obsolescence fixed and miscellaneous fixes.

and "make all" fails with

gprbuild -p -XOS=unix -XTYPE=static -XBUILD=Debug -XV_MAJOR=1 -XV_MINOR=3 
-XV_PATCH=0 -XV_STATUS=Beta -aP../../lib/gnat -aP../../src -P zbtest
zbtest.gpr:36:06: unknown project file: "xmlada"
gprbuild: "zbtest" processing failed
Makefile:72: recipe for target 'all' failed
make[2]: *** [all] Error 4
make[2]: Leaving directory '/home/jrcarter/Code/gnoga/deps/zanyblue/src/zbtest'
Makefile:113: recipe for target 'zbtest.app' failed
make[1]: *** [zbtest.app] Error 2
make[1]: Leaving directory '/home/jrcarter/Code/gnoga/deps/zanyblue/src'
Makefile:144: recipe for target 'zanyblue' failed
make: *** [zanyblue] Error 2

"git checkout dev_1.3" works better, but fails in the same way.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09



--
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] Version 1.3a released and version 1.4-alpha created.

[Pascal via Gnoga-list]

Hello Jeff,

Thanks to point out that.
I forgot to precise that the default branch dev_1.3 is set on SF web site GIT 
code page.

When you clone with GIT you have to checkout the wanted branch, for instance:
$ git checkout dev_1.3
or a particular label:
$ git checkout V1.3a

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


> Le 1 nov. 2017 à 11:57, Jeffrey R. Carter  a écrit :
> 
> On 11/01/2017 11:40 AM, Pascal via Gnoga-list wrote:
>> Version 1.3a has been released on SF GIT dev_1.3 branch.
>> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/
>> 
>> See HISTORY for details.
>> 
>> This branch is now the default one.
> 
> Not quite:
> 
> ~/Code/gnoga$ git pull
> Already up-to-date.
> ~/Code/gnoga$ git branch
> * master
> ~/Code/gnoga$ git describe
> V1.2b
> 
> -- 
> Jeff Carter
> "Monsieur Arthur King, who has the brain of a duck, you know."
> Monty Python & the Holy Grail
> 09


--
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] Version 1.3a released and version 1.4-alpha created.

[Jeffrey R. Carter]

On 11/01/2017 11:40 AM, Pascal via Gnoga-list wrote:
> Version 1.3a has been released on SF GIT dev_1.3 branch.
> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/
>
> See HISTORY for details.
>
> This branch is now the default one.

Not quite:

~/Code/gnoga$ git pull
Already up-to-date.
~/Code/gnoga$ git branch
* master
~/Code/gnoga$ git describe
V1.2b

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09


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