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.8.4 with SMTP id n4mr890030wia.0.1360696752112;
        Tue, 12 Feb 2013 11:19:12 -0800 (PST)
Path: 
 g1ni7165wig.0!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Tue, 12 Feb 2013 20:18:51 +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>
 <51197b0d$0$9510$9b4e6d93@newsspool1.arcor-online.net>
 <20130212170452.5c125ebe@hactar.xn--rombobjrn-67a.se>
In-Reply-To: <20130212170452.5c125ebe@hactar.xn--rombobjrn-67a.se>
X-Enigmail-Version: 1.5
Message-ID: <511a9598$0$6638$9b4e6d93@newsspool2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 12 Feb 2013 20:18:48 CET
NNTP-Posting-Host: 782923db.newsspool2.arcor-online.net
X-Trace: 
 DXC=X3HLUE6Dh9?TQL:hoD@>T?A9EHlD;3Yc24Fo<]lROoR18kF<OcfhCO;UH1g8W5ZBk5nc\616M64>:Lh>_cHTX3j=OoG`ReQG9\=
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: 2013-02-12T20:18:48+01:00
List-Id: <comp.lang.ada>

On 12.02.13 17:04, Björn Persson wrote:
> Georg Bauhaus wrote:
>> 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.
> 
> I haven't tried it but according to the GNAT User's Guide, if you pass
> -r to both Gnatprep and Gnatchop, then compiler messages and debug
> information will refer to the original file.

The process is actually spoiled at this stage, since -r will
either mean referring to an intermediate file (viz gnatprep's output),
or will not work because -gnatep leads to incorrect offsets.
I usually pass -r -w -c to gnatchop, which works fine except when
preprocessing is involved.

Maybe some insane trickery with pragma Source_File_Name
will work.