Building Matreshka on Windows

Building Matreshka on Windows

[Shark8]

I recently came across Matreshka on this wikipedia page -- https://en.wikibooks.org/wiki/Ada_Programming/Libraries/Database -- when searching for FireBird bindings to Ada... Ada bindings to FireBirs? Whatever.

Anyway, the user-guide is pretty unhelpful when on a Windows machine -- http://forge.ada-ru.org/matreshka/wiki/Guide -- essentially requiring the whole unix-like environment... so my questions are thus: has anyone gotten it to build on Windows? has anyone gotten it to build WITHOUT Cygwin, MSYS, etc?

PS -- I'd much rather not use Cygwin et al; it adds another layer of tools and idiosyncrasies to the environment.

PPS -- Why do people think "make" is a good way to build/install anyway? (I tried running it through Borland's make, but no joy -- what else do you expect from a tool developed on/with/for C?)

Re: Building Matreshka on Windows

[Dmitry A. Kazakov]

On 02/11/2016 22:29, Shark8 wrote:

> PPS -- Why do people think "make" is a good way to build/install
> anyway? (I tried running it through Borland's make,

I used to write make files generator for Borland's make, nmake, GNU 
make, have a shirt and cap.

> but no joy -- what
> else do you expect from a tool developed on/with/for C?)

Ada, Watson!

BTW, gprbuild can C. Granted, gprbuild is a big step back from gnatmake, 
but still miles ahead of make.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Building Matreshka on Windows

[Olivier Henley]

On Thursday, November 3, 2016 at 4:18:07 AM UTC-4, Dmitry A. Kazakov wrote:
> BTW, gprbuild can C. Granted, gprbuild is a big step back from gnatmake, 
> but still miles ahead of make.

Why do say gprbuild is a big step back from gnatmake? I don't have enough knowledge of both to evaluate your saying.

Thx.

Re: Building Matreshka on Windows

[Dmitry A. Kazakov]

On 03/11/2016 16:32, Olivier Henley wrote:
> On Thursday, November 3, 2016 at 4:18:07 AM UTC-4, Dmitry A. Kazakov wrote:
>> BTW, gprbuild can C. Granted, gprbuild is a big step back from gnatmake,
>> but still miles ahead of make.
>
> Why do say gprbuild is a big step back from gnatmake? I don't have
> enough knowledge of both to evaluate your saying.

Because in my opinion it is built upon an inferior technology. It uses 
XML, it is not self-contained (has a mess of semi-hidden supplementary 
files spread all around the system). It is very easy and common to have 
gprbuild not working where gnatmake never had any problem. The biggest 
danger is turning it into yet another "configure" / CMake.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Building Matreshka on Windows

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 03/11/2016 16:32, Olivier Henley wrote:
>> On Thursday, November 3, 2016 at 4:18:07 AM UTC-4, Dmitry A. Kazakov wrote:
>>> BTW, gprbuild can C. Granted, gprbuild is a big step back from gnatmake,
>>> but still miles ahead of make.
>>
>> Why do say gprbuild is a big step back from gnatmake? I don't have
>> enough knowledge of both to evaluate your saying.
>
> Because in my opinion it is built upon an inferior technology. It uses
> XML, it is not self-contained (has a mess of semi-hidden supplementary
> files spread all around the system). It is very easy and common to
> have gprbuild not working where gnatmake never had any problem. The
> biggest danger is turning it into yet another "configure" / CMake.

Unless you go out of your way, the configuration files are all under
$prefix/share/gprconfig/

When things work, all is fine. When they don't, it can be tricky; the
way the configuration files specify commands to run and grepping the
output for particular patterns is challenging:

On the Mac, GCC 5 and 6 generate shared libraries with names like
libgnat-6.dylib; GCC 4, names like libgnat-4.8.dylib. gnatls reports
itself as e.g. GNATLS 6.1.0. The original share/gprconfig/compilers.xml
file looked for the first 2 fields of the version; libgnat-6.1.dylib
wasn't found. The fix was (cut back not to bore you)

     <version>
       <external>${PREFIX}gnatls -v --version</external>
-      <grep regexp="^GNATLS.+?(\d+(\.\d+)?)" group="1"></grep>
+      <grep regexp="^GNATLS.+?(\d+)" group="1"></grep>
     </version>

I'm very pleased that, since GPRBUILD 2016, I can use e.g.

   for Target use "arm-eabi";
   for Runtime ("ada") use "ravenscar-sfp-stm32f4";

in the GPR instead of having to specify on the command line.

Re: Building Matreshka on Windows

[G.B.]

On 03.11.16 18:50, Simon Wright wrote:


> The fix was (cut back not to bore you)
>
>      <version>
>        <external>${PREFIX}gnatls -v --version</external>
> -      <grep regexp="^GNATLS.+?(\d+(\.\d+)?)" group="1"></grep>
> +      <grep regexp="^GNATLS.+?(\d+)" group="1"></grep>
>      </version>

Two things I find puzzling when I see this setup:

1 - why would compiler writers parse version strings using
     REs that can fail in ways that I'd be tempted to call
      classic when their core business actually depends on
     well working parsers?

2 - what makes compiler writers not use their languages'
     powers for communicating the information between processes
     in a structured way, with ease?

Business angst?


After a few years of seeing version identifiers change in
seemingly arbitrary ways, I am convinced that the technically
relevant information should be communicated using some
protocol to be endorsed by all parties involved.
Making version identifiers reflect hacks rarely works
for all parties.

One of the few micro formats that seem to work without AI is,
I guess, ISO date strings. The "ISO" part should ring a bell
or two.


> I'm very pleased that, since GPRBUILD 2016, I can use e.g.
>
>    for Target use "arm-eabi";
>    for Runtime ("ada") use "ravenscar-sfp-stm32f4";
>
> in the GPR instead of having to specify on the command line.
>



-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: Building Matreshka on Windows

[Simon Wright]

"G.B." <bauhaus@futureapps.invalid> writes:

> 1 - why would compiler writers parse version strings using
>     REs that can fail in ways that I'd be tempted to call
>      classic when their core business actually depends on
>     well working parsers?

The input formats to be processed by this RE are very limited, and under
AdaCore's control:

   (whatever GNAT Pro reports)
   GNATLS GPL 2016 (20160515-49)
   GNATLS 4.8.1

and it's not as though the RE processing is done by shelling out to run
grep (you can tell this because gprconfig runs on Windows).

Re: Building Matreshka on Windows

[G.B.]

On 04.11.16 09:55, Simon Wright wrote:
> The input formats to be processed by this RE are very limited, and under
> AdaCore's control

I was hoping that the formats are controlled, and few, but given the
generic nature of GPRBuild, won't similar declarations of REs be used
for "guessing" versions of tools not under AdaCore's control?  Like,
what if those version numbers will be reflecting Git tags applied by
third parties, like "v6.1-exp_BH-20160428A"?

On the plus side, it might feel like an easy job when one needs
to integrate a patched tool by adjusting REs. TTBOMK, correct REs
aren't that easy, though.

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: Building Matreshka on Windows

[Olivier Henley]

On Thursday, November 3, 2016 at 12:10:49 PM UTC-4, Dmitry A. Kazakov wrote:

> Because in my opinion it is built upon an inferior technology. It uses 
> XML, it is not self-contained (has a mess of semi-hidden supplementary 
> files spread all around the system). It is very easy and common to have 
> gprbuild not working where gnatmake never had any problem. The biggest 
> danger is turning it into yet another "configure" / CMake.

Why did they move from gnatmake then?

Re: Building Matreshka on Windows

[Dmitry A. Kazakov]

On 2016-11-03 19:02, Olivier Henley wrote:
> On Thursday, November 3, 2016 at 12:10:49 PM UTC-4, Dmitry A. Kazakov wrote:
>
>> Because in my opinion it is built upon an inferior technology. It uses
>> XML, it is not self-contained (has a mess of semi-hidden supplementary
>> files spread all around the system). It is very easy and common to have
>> gprbuild not working where gnatmake never had any problem. The biggest
>> danger is turning it into yet another "configure" / CMake.
>
> Why did they move from gnatmake then?

Who knows? Why GPS uses Python scripts instead of Ada?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Building Matreshka on Windows

[gautier_niouzes]

> Why GPS uses Python scripts instead of Ada?

That's for producing some 50 lines of error messages with a loud "SyntaxError" at the end, each time you start GPS. Perfect for impressing newcomers ;-)
_________________________ 
Gautier's Ada programming 
http://gautiersblog.blogspot.com/search/label/Ada 
NB: follow the above link for a valid e-mail address 

Re: Building Matreshka on Windows

[Dmitry A. Kazakov]

On 03/11/2016 23:39, gautier_niouzes@hotmail.com wrote:
>> Why GPS uses Python scripts instead of Ada?
>
> That's for producing some 50 lines of error messages with a loud
> "SyntaxError" at the end, each time you start GPS. Perfect for
> impressing newcomers ;-)

BTW errors, I wished GNAT would stop right at the first error and kept 
any warnings silent until no errors came.

Amazing how compilation continuation survived long since the death of 
OS/360 batch jobs on the stack of punched cards...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Building Matreshka on Windows

[G.B.]

On 03.11.16 21:18, Dmitry A. Kazakov wrote:
> On 2016-11-03 19:02, Olivier Henley wrote:
>> On Thursday, November 3, 2016 at 12:10:49 PM UTC-4, Dmitry A. Kazakov wrote:
>>
>>> Because in my opinion it is built upon an inferior technology. It uses
>>> XML, it is not self-contained (has a mess of semi-hidden supplementary
>>> files spread all around the system). It is very easy and common to have
>>> gprbuild not working where gnatmake never had any problem. The biggest
>>> danger is turning it into yet another "configure" / CMake.
>>
>> Why did they move from gnatmake then?
>
> Who knows?

A guess: gnatmake was designed for running the programs that translate
Ada source, compiling, binding, linking (gcc, gnatbind, gnatlink).
gprbuild is designed for running tools in multi-language projects.
How will integrating the multi-language tools proceed?

Multiple languages might imply the absence of organizational power
that strongly suggests how things be done. One that could force a
design for all languages matching the quality and usability of
gnatmake for Ada alone (or adamake for the AdaMagic line of tools).
The next best thing then is a project tool working like Make and
shell, relying on diverse forms of text, output by the tools for any
of those languages: gprbuild. The diverse tools can keep their
idiosyncrasies, thus reducing commercial effort and creating
opportunities for project management specialists. (Extending Gautier's
observation, this meets expectations of anyone coming from any other
language.)

Better suited to the task of configuring software translation will be
a typed, declarative language for handling rules and constants, I'd
think. A language that "knows" about multiple languages like
gnatmake knows about Ada. So, it wouldn't be either Ada or Python.

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: Building Matreshka on Windows

[Dmitry A. Kazakov]

On 04/11/2016 09:57, G.B. wrote:
[...]
> Better suited to the task of configuring software translation will be
> a typed, declarative language for handling rules and constants, I'd
> think. A language that "knows" about multiple languages like
> gnatmake knows about Ada. So, it wouldn't be either Ada or Python.

And this is the key point. Should it be a language? Really? If AdaCore 
knows these object languages (Ada, C, C++, Brainf*ck etc), why do they 
need a language to express that knowledge? Why do they need to 
communicate that knowledge to the poor end user? As a programmer I have 
no interest whatsoever in this knowledge. Why don't they let me alone?

Note this same question arises with handling Ada projects. You could try 
to use a language like GNU make to maintain an Ada project. Or you could 
have a non-language tool like gnatmake or AdaGIDE to handle that. What 
works better?

You might say they wanted it be open-ended so that I could add the 
Whitespace language to the list. The answer is no. I am not interested 
in doing this and the percentage of people who potentially may differ 
and would willingly become programmers of the configuration language 
does not pay off the miseries the huge majority of "normal" people have.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Building Matreshka on Windows

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 04/11/2016 09:57, G.B. wrote:
> [...]
>> Better suited to the task of configuring software translation will be
>> a typed, declarative language for handling rules and constants, I'd
>> think. A language that "knows" about multiple languages like gnatmake
>> knows about Ada. So, it wouldn't be either Ada or Python.
>
> And this is the key point. Should it be a language? Really? If AdaCore
> knows these object languages (Ada, C, C++, Brainf*ck etc), why do they
> need a language to express that knowledge? Why do they need to
> communicate that knowledge to the poor end user? As a programmer I
> have no interest whatsoever in this knowledge. Why don't they let me
> alone?

I just don't understand what makes you say this. If you are happy with
gnatmake without GPRs, carry on and use it, with all the mess of -A*
swithces that you will certainly need a makefile or other script to
remember for you. gprbuild will work just as well, except of course that
you do have to have a project file. Why on earth would you need to look
at $prefix/share/gprconfig?

> Note this same question arises with handling Ada projects. You could
> try to use a language like GNU make to maintain an Ada project. Or you
> could have a non-language tool like gnatmake or AdaGIDE to handle
> that. What works better?

gprbuild, of course.

> You might say they wanted it be open-ended so that I could add the
> Whitespace language to the list. The answer is no. I am not interested
> in doing this and the percentage of people who potentially may differ
> and would willingly become programmers of the configuration language
> does not pay off the miseries the huge majority of "normal" people
> have.

I think the people who have problems such as you hint at with gprbuild
are not "normal".

Of course, one might think that people who want to program in Ada aren't
normal, either ...

Re: Building Matreshka on Windows

[Dmitry A. Kazakov]

On 2016-11-04 14:28, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> On 04/11/2016 09:57, G.B. wrote:
>> [...]
>>> Better suited to the task of configuring software translation will be
>>> a typed, declarative language for handling rules and constants, I'd
>>> think. A language that "knows" about multiple languages like gnatmake
>>> knows about Ada. So, it wouldn't be either Ada or Python.
>>
>> And this is the key point. Should it be a language? Really? If AdaCore
>> knows these object languages (Ada, C, C++, Brainf*ck etc), why do they
>> need a language to express that knowledge? Why do they need to
>> communicate that knowledge to the poor end user? As a programmer I
>> have no interest whatsoever in this knowledge. Why don't they let me
>> alone?
>
> I just don't understand what makes you say this. If you are happy with
> gnatmake without GPRs, carry on and use it, with all the mess of -A*
> swithces that you will certainly need a makefile or other script to
> remember for you. gprbuild will work just as well, except of course that
> you do have to have a project file. Why on earth would you need to look
> at $prefix/share/gprconfig?

You misunderstood the discussion. It was not GPR I complained about.

GPR is a language that describes an object language(s) project. I have 
little against it. At least it is has Ada-like syntax.

The discussion was about another language that would describe rules how 
to interpret a GPR file when it refers to some object language X (e.g. 
Ada or C). Roughly it is the language gprconfig uses.

My point was that this knowledge better be an integral part of gprbuild 
as it was of gnatmake. Georg suggested that somebody outside AdaCore 
could interested in keeping it elsewhere as grpbuild attempts to do.

>> Note this same question arises with handling Ada projects. You could
>> try to use a language like GNU make to maintain an Ada project. Or you
>> could have a non-language tool like gnatmake or AdaGIDE to handle
>> that. What works better?
>
> gprbuild, of course.

That is too.

> I think the people who have problems such as you hint at with gprbuild
> are not "normal".

People enjoying playing with gprconfig are definitely not exactly "normal".

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Building Matreshka on Windows

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 2016-11-04 14:28, Simon Wright wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> I just don't understand what makes you say this.

> You misunderstood the discussion. It was not GPR I complained about.

I did. Sorry.

> People enjoying playing with gprconfig are definitely not exactly
> "normal".

I never said I enjoyed it!

I was once congratulated by an AdaCore person for having managed to find
a gprconfig problem :)

Re: Building Matreshka on Windows

[Jeffrey R. Carter]

On 11/04/2016 06:28 AM, Simon Wright wrote:
>
> I just don't understand what makes you say this. If you are happy with
> gnatmake without GPRs, carry on and use it, with all the mess of -A*
> swithces that you will certainly need a makefile or other script to
> remember for you. gprbuild will work just as well, except of course that
> you do have to have a project file. Why on earth would you need to look
> at $prefix/share/gprconfig?

Every Ada compiler includes a tool for building a system based on the dependency 
information in the code. This information is one of Ada's major strengths. One 
has to learn the parameters to this tool, of course, but then building becomes 
one line, easily stored somewhere, such as a script.

So what does a program such as gprbuild buy you? You have to tell gnatmake where 
to find other things used in the system (-A*), but you do the same with 
gprbuild, in the form of paths in the withed projects. You have to supply the 
compiler switches, but you do the same with gprbuild, in the Switches 
declarations. You don't have to write the one-line script, but instead write a 
many-line project file.

Personally, I don't see that gprbuild adds any value; in fact, it seems to 
subtract value: You supply the same information and have to have the same 
knowledge, but you have to know the syntax of a project file as well, so the 
effort is increased. For this reason, I never voluntarily use gprbuild for my 
projects (which are always all Ada), and don't understand why anyone would think 
it an advantage to do so.

(Similar arguments apply against make.)

-- 
Jeff Carter
"If I could find a sheriff who so offends the citizens of Rock
Ridge that his very appearance would drive them out of town ...
but where would I find such a man? Why am I asking you?"
Blazing Saddles
37

Re: Building Matreshka on Windows

[Simon Wright]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:

> So what does a program such as gprbuild buy you? You have to tell
> gnatmake where to find other things used in the system (-A*), but you
> do the same with gprbuild, in the form of paths in the withed
> projects.

But at least that's a problem solved locally in the withed projects
(which can use relative paths).

Re: Building Matreshka on Windows

[Jacob Sparre Andersen]

Jeffrey R. Carter wrote:

[about all Ada projects]

> Every Ada compiler includes a tool for building a system based on the
> dependency information in the code. This information is one of Ada's
> major strengths. One has to learn the parameters to this tool, of
> course, but then building becomes one line, easily stored somewhere,
> such as a script.

Yes.  But don't you need to have two versions of that script, one for
Microsoft hosted compilers, and one for Unix hosted compilers?  Using
GNAT project files, you can typically get away with having only one.

> So what does a program such as gprbuild buy you?

If your projects only contain Ada sources - nothing that "gnatmake"
didn't have as well.

Since I typically work on multi-language projects (Ada,
Mercurial/Subversion, Macks, C), "gprbuild" makes a big difference for
me.

But I'm not at all fond of "gprconfig".  I'm in the middle of figuring
out how I can avoid "gprconfig", and provide ready to use ".cgpr" files
instead of providing XML files for "gprconfig", which have to be
installed before the project can be built.

Greetings,

Jacob
-- 
"Then, after a second or so, nothing continued to happen."

Re: Building Matreshka on Windows

[Simon Wright]

Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:

> But I'm not at all fond of "gprconfig".  I'm in the middle of figuring
> out how I can avoid "gprconfig", and provide ready to use ".cgpr"
> files instead of providing XML files for "gprconfig", which have to be
> installed before the project can be built.

They don't have to be "installed", at any rate not in the default
location. gprbuild has a --db switch:

  --db dir Parse dir as an additional knowledge base
  --db-    Do not load the standard knowledge base

Re: Building Matreshka on Windows

[Jacob Sparre Andersen]

Simon Wright <simon@pushface.org> writes:

> They don't have to be "installed", at any rate not in the default
> location. gprbuild has a --db switch:

Thanks!  Hadn't noticed that.

Greetings,

Jacob
-- 
»You know the world has gone crazy when the best rapper is a
 white guy, the best golfer is a black guy, the swiss hold
 the America's cup, France is accusing the U.S. of
 arrogance, and Germany doesn't want to go to war«

Re: Building Matreshka on Windows

[Maxim Reznik]

среда, 2 ноября 2016 г., 23:29:17 UTC+2 пользователь Shark8 написал:
> I recently came across Matreshka on this wikipedia page -- https://en.wikibooks.org/wiki/Ada_Programming/Libraries/Database -- when searching for FireBird bindings to Ada... Ada bindings to FireBirs? Whatever.
> 
> Anyway, the user-guide is pretty unhelpful when on a Windows machine -- http://forge.ada-ru.org/matreshka/wiki/Guide -- essentially requiring the whole unix-like environment... so my questions are thus: has anyone gotten it to build on Windows? has anyone gotten it to build WITHOUT Cygwin, MSYS, etc?
> 

You don't need Cygwin nor MSYS to compile matreshka. Just two packages make and coreutils (together less then 10 Mb in size, url in the guide). Just install these two pieces of software. That's all you need to start compilation.

So, yes - it works on windows without any problem. yes - it works WITHOUT Cygwin and MSYS.

What build driver do you prefer? maven, NuGet, chocolately, Web PI or PowerShell? ;)

> PS -- I'd much rather not use Cygwin et al; it adds another layer of tools and idiosyncrasies to the environment.
> 
> PPS -- Why do people think "make" is a good way to build/install anyway? (I tried running it through Borland's make, but no joy -- what else do you expect from a tool developed on/with/for C?)

Re: Building Matreshka on Windows

[Shark8]

On Tuesday, November 29, 2016 at 8:22:48 AM UTC-7, Maxim Reznik wrote:
> среда, 2 ноября 2016 г., 23:29:17 UTC+2 пользователь Shark8 написал:
> > I recently came across Matreshka on this wikipedia page -- https://en.wikibooks.org/wiki/Ada_Programming/Libraries/Database -- when searching for FireBird bindings to Ada... Ada bindings to FireBirs? Whatever.
> > 
> > Anyway, the user-guide is pretty unhelpful when on a Windows machine -- http://forge.ada-ru.org/matreshka/wiki/Guide -- essentially requiring the whole unix-like environment... so my questions are thus: has anyone gotten it to build on Windows? has anyone gotten it to build WITHOUT Cygwin, MSYS, etc?
> > 
> 
> You don't need Cygwin nor MSYS to compile matreshka. Just two packages make and coreutils (together less then 10 Mb in size, url in the guide). Just install these two pieces of software. That's all you need to start compilation.

Thank you for the info.

> So, yes - it works on windows without any problem. yes - it works WITHOUT Cygwin and MSYS.

Here's the output of attempting to run make (after installing GNU make and coreutils):

C:\Programming\Libraries\Matreshka>make
make reconfig
make[1]: Entering directory `C:/Programming/Libraries/Matreshka'
gnatmake -p -j0  -Pgnat/tools_configure.gpr
object directory "C:\Programming\Libraries\Matreshka\gnat\..\.objs\configure\" created
gcc -c -g -gnat12 -gnato -fstack-check configure-driver.adb
gcc -c -g -gnat12 -gnato -fstack-check configure.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-architecture.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-instantiate.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-internals.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-rtl_version.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-tests.ads
gcc -c -g -gnat12 -gnato -fstack-check configure-tests-asis.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-tests-firebird.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-tests-gprbuild.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-tests-install.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-tests-installation_directories.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-tests-modules.ads
gcc -c -g -gnat12 -gnato -fstack-check configure-tests-modules-amf.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-tests-mysql.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-tests-oci.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-tests-operating_system.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-tests-postgresql.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-tests-sqlite3.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-tests-valgrind.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-version.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-builder.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-abstract_tests.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-pkg_config.adb
gcc -c -g -gnat12 -gnato -fstack-check configure-component_switches.adb
gprbind configure-driver.bexch
gnatbind configure-driver.ali
gcc -c b__configure-driver.adb
gcc configure-driver.o -o configure.exe
./configure
[os        ] detecting target operating system: Windows
[gprbuild  ] looking for GPRbuild: C:\Programming\GNAT\2016\bin\gprbuild.exe
[gprbuild  ] checking GPRbuild version: ok
[asis      ] checking whether ASIS library is available: no
[modules   ] checking whether to build AMF module: no
[mysql     ] checking whether to build MySQL module: no (mysql_config not found)

configure.exe: (info) MySQL driver module is disabled
[oci       ] checking whether to build Oracle module: no (not found)
configure.exe: (info) Oracle driver module is disabled
[postgresql] checking whether to build PostgreSQL module: no (pg_config not foun
d)
configure.exe: (info) PostgreSQL driver module is disabled
[sqlite3   ] checking whether to build SQLite3 module: no (pkg-config not found)

configure.exe: (info) SQLite3 driver module is disabled
[firebird  ] checking whether to build Firebird module: yes (try default)
[firebird  ] checking whether Firebird library is usable: no
configure.exe: (info) Firebird driver module is disabled
configure.exe: VALGRIND =>
configure.exe: HAS_FIREBIRD =>
configure.exe: MYSQL_LIBRARY_OPTIONS =>
configure.exe: INSTALL => C:/Program Files (x86)/Coreutils/bin/install.exe
configure.exe: GPRDIR => /usr/local/lib/gnat
configure.exe: GPRBUILD => C:/Programming/GNAT/2016/bin/gprbuild.exe
configure.exe: HAS_SQLITE3 =>
configure.exe: OPERATING_SYSTEM => Windows
configure.exe: FIREBIRD_LIBRARY_OPTIONS =>
configure.exe: HAS_MYSQL =>
configure.exe: VERSION => 0.7.0
configure.exe: ARCHITECTURE => x86
configure.exe: BINDIR => /usr/local/bin
configure.exe: LIBDIR => /usr/local/lib
configure.exe: HAS_ASIS =>
configure.exe: HAS_GPRBUILD2014 =>
configure.exe: HAS_POSTGRESQL =>
configure.exe: OCI_LIBRARY_OPTIONS =>
configure.exe: HAS_OCI =>
configure.exe: PREFIX => /usr/local
configure.exe: POSTGRESQL_LIBRARY_OPTIONS =>
configure.exe: HAS_VALGRIND =>
configure.exe: SQLITE3_LIBRARY_OPTIONS =>
configure.exe: HAS_WORKING_MYSQL_SERVER =>
configure.exe: RTL_VERSION_SUFFIX => -2016
configure.exe: ENABLE_AMF =>
configure.exe: creating Makefile.config
configure.exe: creating gnat/install/matreshka_config.gpr
configure.exe: creating gnat/matreshka_config.gpr
configure.exe: creating source/league/matreshka-config.ads
make[1]: Leaving directory `C:/Programming/Libraries/Matreshka'
make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4217b3)

C:\Programming\Libraries\Matreshka>make install
make -f Makefile.install
make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4217b3)
make: *** [install] Error 255


> What build driver do you prefer? maven, NuGet, chocolately, Web PI or PowerShell? ;)

It doesn't exist. (Yet.) ;)
Of those you listed PowerShell is, IMO, the best... but that's not really saying a lot. (GPRBuild is usable, in the way that C is, but we *really* ought to have a better project language.)

Re: Building Matreshka on Windows

[Maxim Reznik]

среда, 30 ноября 2016 г., 1:49:13 UTC+2 пользователь Shark8 написал:
> C:\Programming\Libraries\Matreshka>make install
> make -f Makefile.install
> make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4217b3)
> make: *** [install] Error 255
> 
> 

It seems your make is unable to start make. Could you add path to make.exe into PATH environment on the system level (/My Computer/Properties/Advanced/Environment Variables/PATH=). Restart shell to apply new PATH setting and try again.

I see also that configure.exe doesn't find firebird automatically. Try to specify firebird directory explicitly:

make config
configure.exe --with-firebird-libdir="C:\Program Files\Firebird\Firebird_3_0"
make

> > What build driver do you prefer? maven, NuGet, chocolately, Web PI or PowerShell? ;)
> 
> It doesn't exist. (Yet.) ;)
> Of those you listed PowerShell is, IMO, the best... but that's not really saying a lot. (GPRBuild is usable, in the way that C is, but we *really* ought to have a better project language.)