From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Building Matreshka on Windows
Date: Fri, 4 Nov 2016 09:57:05 +0100
Organization: A noiseless patient Spider
Message-ID: <nvhig8$e23$1@dont-email.me>
References: <3c41f737-a1d9-40a5-aea3-08c4b61baaa8@googlegroups.com>
 <nverrs$1rb1$1@gioia.aioe.org>
 <ddb479d7-eaae-40c3-b5e1-267df5f98d65@googlegroups.com>
 <nvfni5$1agt$1@gioia.aioe.org>
 <753a3a53-4c3a-4c6f-9f9b-b7d1e5c5f24e@googlegroups.com>
 <nvg62q$4dp$1@gioia.aioe.org>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 4 Nov 2016 08:56:40 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="af1e9377846db2a2caf97a297d2765f9";
	logging-data="14403"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18n8UX5KR+fLjbeoAxDhqjIGAgA9UoCT0Y="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.4.0
In-Reply-To: <nvg62q$4dp$1@gioia.aioe.org>
Cancel-Lock: sha1:lYI/tiA0RfUcii+PTcNWzx8L53E=
Xref: news.eternal-september.org comp.lang.ada:32238
Date: 2016-11-04T09:57:05+01:00
List-Id: <comp.lang.ada>

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