Re: [Gnoga-list] Is it reasonable to request project file changes for some environment configurations?
Hello Jeremiah,
Unfortunately, I can't help you so much as I work with macOS.
But it sounds strange to me that this kind of issue is not handle internally by
gnatmake or gprbuild.
Maybe a bug of that side.
Or else a smart trick in Gnat docs or on Internet.
Any idea from other Windows users?
Regards, Pascal.
http://blady.pagesperso-orange.fr
> Le 16 sept. 2017 à 01:26, Jeremiah Breeden a
> écrit :
>
> Just wanted to touch base again. Is this something that I can generate a
> ticket for (I will if so) or is it too constrained to a particular setup? I
> can't test on mac or linux to see if there are any impacs, so I this might be
> a concern.
>
> As far as I know there aren't a lot of available windows 64 bit
> configurations that allow for the building of Gnoga. mingw64 is the only one
> I got to work and I had to really man handle gprbuild to get it to work.
>
> On Tue, Aug 29, 2017 at 11:56 AM, Jeremiah Breeden
> wrote:
> So I finally got a windows 10 non GPL gnoga environment build and working (at
> least so far). However, in order to build gnoga I had to make some changes
> to a couple of the GPR files or else the "make install" command would fail
> horribly.
>
> For some reason both tools.gpr and zbmcompile.gpr would fail to install at
> all at first. They are both unique in that instead of installing a library,
> they install executables into /bin. So I am assuming that is the reason
> those two failed while the others installed fine.
>
> The error in question was something like:
>
> /some_path/gnoga_make does not exist (it was there, I checked to make sure)
>
> I added a .exe extension to the parts that specified the executable name:
>
> tools.gpr
> *
>package Builder is
> for Executable ("gnoga_make-main.adb") use "gnoga_make";
> for Executable ("gnoga_doc-main.adb") use "gnoga_doc";
>end Builder;
>
> *
>
> became:
> *
>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;
>
> *
>
> zbmcompile.gpr
> *
>package Builder is
> for Executable ("zbmcompile-main.adb") use "zbmcompile";
>end Builder;
>
> *
>
> became:
> *
>package Builder is
> for Executable ("zbmcompile-main.adb") use "zbmcompile.exe";
>end Builder;
>
> *
>
>
> I realize that this is a fix specific for FSF gnat compilation of gnoga on
> windows for mingw64, but was curious if it was still reasonable to ask that
> the library be updated with these changes or if that was just out of scope.
> Obviously someone would want to test on a linux distro to ensure nothing gets
> broken. I don't have one to test on.
>
>
> --
> 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] Is it reasonable to request project file changes for some environment configurations?
Just wanted to touch base again. Is this something that I can generate a
ticket for (I will if so) or is it too constrained to a particular setup?
I can't test on mac or linux to see if there are any impacs, so I this
might be a concern.
As far as I know there aren't a lot of available windows 64 bit
configurations that allow for the building of Gnoga. mingw64 is the only
one I got to work and I had to really man handle gprbuild to get it to work.
On Tue, Aug 29, 2017 at 11:56 AM, Jeremiah Breeden <
jeremiah.bree...@gmail.com> wrote:
> So I finally got a windows 10 non GPL gnoga environment build and working
> (at least so far). However, in order to build gnoga I had to make some
> changes to a couple of the GPR files or else the "make install" command
> would fail horribly.
>
> For some reason both tools.gpr and zbmcompile.gpr would fail to install at
> all at first. They are both unique in that instead of installing a
> library, they install executables into /bin. So I am assuming that is the
> reason those two failed while the others installed fine.
>
> The error in question was something like:
>
> /some_path/gnoga_make does not exist (it was there, I checked to make sure)
>
> I added a .exe extension to the parts that specified the executable name:
>
> tools.gpr
> *
>
>package Builder is
> for Executable ("gnoga_make-main.adb") use "gnoga_make";
> for Executable ("gnoga_doc-main.adb") use "gnoga_doc";
>end Builder;
>
> *
>
> became:
> *
>
>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;
>
> *
>
> zbmcompile.gpr
> *
>
>package Builder is
> for Executable ("zbmcompile-main.adb") use "zbmcompile";
>end Builder;
>
> *
>
> became:
> *
>
>package Builder is
> for Executable ("zbmcompile-main.adb") use "zbmcompile.exe";
>end Builder;
>
> *
>
>
> I realize that this is a fix specific for FSF gnat compilation of gnoga on
> windows for mingw64, but was curious if it was still reasonable to ask that
> the library be updated with these changes or if that was just out of
> scope. Obviously someone would want to test on a linux distro to ensure
> nothing gets broken. I don't have one to test on.
>
>
--
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
[Gnoga-list] Is it reasonable to request project file changes for some environment configurations?
So I finally got a windows 10 non GPL gnoga environment build and working
(at least so far). However, in order to build gnoga I had to make some
changes to a couple of the GPR files or else the "make install" command
would fail horribly.
For some reason both tools.gpr and zbmcompile.gpr would fail to install at
all at first. They are both unique in that instead of installing a
library, they install executables into /bin. So I am assuming that is the
reason those two failed while the others installed fine.
The error in question was something like:
/some_path/gnoga_make does not exist (it was there, I checked to make sure)
I added a .exe extension to the parts that specified the executable name:
tools.gpr
*
package Builder is
for Executable ("gnoga_make-main.adb") use "gnoga_make";
for Executable ("gnoga_doc-main.adb") use "gnoga_doc";
end Builder;
*
became:
*
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;
*
zbmcompile.gpr
*
package Builder is
for Executable ("zbmcompile-main.adb") use "zbmcompile";
end Builder;
*
became:
*
package Builder is
for Executable ("zbmcompile-main.adb") use "zbmcompile.exe";
end Builder;
*
I realize that this is a fix specific for FSF gnat compilation of gnoga on
windows for mingw64, but was curious if it was still reasonable to ask that
the library be updated with these changes or if that was just out of
scope. Obviously someone would want to test on a linux distro to ensure
nothing gets broken. I don't have one to test on.
--
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
