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
X-Google-Thread: 103376,e36020a4e7d24836
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!feeder.news-service.com!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: How to leave .ali files in original library?
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: <slrninfg27.kmk.localhost@example.org>
 <87zkp4uhjl.fsf@ludovic-brenta.org> <slrningqqj.27q.localhost@example.org>
 <m2mxl3v5vf.fsf@pushface.org> <slrningsuj.27q.localhost@example.org>
 <eebf3b04-6c56-4192-a0e9-958ac126e428@l2g2000prg.googlegroups.com>
 <ilbfgo$hto$1@munin.nbi.dk> <slrninjp97.5q5.localhost@example.org>
 <df7b99d9-74e6-4e1a-bd1a-2cbc8faf7367@q14g2000vbf.googlegroups.com>
Date: Fri, 11 Mar 2011 16:07:29 +0100
Message-ID: <1j528pbtwh3jw$.1jqmz5gdvxxab$.dlg@40tude.net>
NNTP-Posting-Date: 11 Mar 2011 16:07:24 CET
NNTP-Posting-Host: 2b4e4a88.newsspool4.arcor-online.net
X-Trace: 
 DXC=AWMfW59OKT0=FQB?mjjV504IUK<Cl32<14Fo<]lROoR18kF<OcfhCO;K6El3@Cfi\=[6LHn;2LCV>[<mhadbfdU;Ab`T`Zb<Z`?>YeR[4Ggf?0
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:19059
Date: 2011-03-11T16:07:24+01:00
List-Id: <comp.lang.ada>

On Fri, 11 Mar 2011 01:16:21 -0800 (PST), Ludovic Brenta wrote:

> localhost@example.org wrote on comp.lang.ada:
>>> I can't speak for the OP, but the obvious reason is that they cause
>>> vendor> lock-in. If any significant amount of your project's functionality
>>> is tied up in .GPR files, then that functionality is not portable to
>>> another Ada compiler. (.GPR files are not Ada!).
>>
>> Of course you're right but I'm only writing very small apps trying to learn
>> Ada at this point. But in principle my objection is what you said and that's
>> why I said I try not to learn non-transferrable bits because it's a waste of
>> time in my opinion.
> 
> But the command-line switches of GCC and your Makefiles tailored for
> GCC are also non-transferable.  Other people have mentioned the
> proprietary build systems of Rational Apex and Janus/Ada; ObjectAda
> also has a different one.  So, your argument is valid in theory but
> moot in practice because it applies equally to all Ada toolchains and
> is not a differentiator.

Actually we could make one step forward and define a
compiler/linker/environment abstraction of an Ada project in ARM. That
would make the gpr file (or, better, an Ada program managing the project)
independent on the target. E.g. instead of "-g", we would write
Project.Debug_Information := True;

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