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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,6458d1ee91b224ec
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,UTF8
X-Received: by 10.180.92.202 with SMTP id co10mr856041wib.1.1360922618383;
        Fri, 15 Feb 2013 02:03:38 -0800 (PST)
Path: 
 g1ni12264wig.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!216.196.110.146.MISMATCH!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!news.meeh.mikalv.net!aioe.org!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Tue, 12 Feb 2013 00:13:20 +0100
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: chopping Ada source that have preprocessor symbols in them
References: <5111a9d5$0$6567$9b4e6d93@newsspool3.arcor-online.net>
 <85txpnm1vp.fsf@stephe-leake.org>
 <5114fb61$0$6561$9b4e6d93@newsspool4.arcor-online.net>
 <85ehgqkxnf.fsf@stephe-leake.org>
 <51168e7e$0$6566$9b4e6d93@newsspool3.arcor-online.net>
 <ly1ucps0pk.fsf@pushface.org>
In-Reply-To: <ly1ucps0pk.fsf@pushface.org>
Message-ID: <51197b0d$0$9510$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 12 Feb 2013 00:13:17 CET
NNTP-Posting-Host: d4b250ff.newsspool1.arcor-online.net
X-Trace: 
 DXC=8c?eG4Na35Kj7E:bke<5HFic==]BZ:afN4Fo<]lROoRAnkgeX?EC@@@2XbN1HO]fNMPCY\c7>ejVHGh<BMQQn1>H[TgQPnYVVaO
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: 2013-02-12T00:13:17+01:00
List-Id: <comp.lang.ada>

On 09.02.13 21:15, Simon Wright wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>
>> The problem is that running the chain of tools again and again is
>> prohibitively inefficient.  It boils down to recompiling the world
>> after each edit.
>
> You could try the gnatmake (and, I think, gprbuild) flag -m:

Promising, but there is a catch.

As Björn said, the compiler should ideally be able to refer to the
original source file as usual. Now, while switch -m does have the desired
effect when chaining the three steps gnatprep && gnatchop && gnatmake,
the compiler messages will in the end refer to the intermediate file
that gnatprep will have created. Not ideal, unless I can convince
the IDE that it should automatically substitute the original file's
name for the name of the intermediate file when inspecting the
compiler's diagnostics. A kludge, but maybe a possibility.

The alternative switch -gnatep would obviate the need for gnatprep
but will, alas, cancel the effect of switch -m, AFAICS. (In cases
when gnatchop will compute usable offsets.)