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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Aggregate GPRs
Date: Mon, 07 Sep 2015 12:50:07 +0100
Organization: A noiseless patient Spider
Message-ID: <ly8u8ixxcg.fsf@pushface.org>
References: <ly37z0zo40.fsf@pushface.org>
	<06ca8009-c7b6-45f4-b4b9-b6c036db31a6@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="bb6b88a1847fc8104d08994bcce59817";
	logging-data="12663"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/HUGGwPD5jku67abcb6sOKKgvpGGIWJEI="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin)
Cancel-Lock: sha1:cypxqu09Ywr0A3wqndL3cqWw120=
	sha1:bpVn8MSTEOSWMGCOeDH1ofrL9co=
Xref: news.eternal-september.org comp.lang.ada:27725
Date: 2015-09-07T12:50:07+01:00
List-Id: <comp.lang.ada>

Mark Lorenzen <mark.lorenzen@gmail.com> writes:

> On Sunday, August 30, 2015 at 7:24:01 PM UTC+2, Simon Wright wrote:
>> I see from the documentation[1] that, for projects built through the
>> aggregate project, package Builder is ignored (even if the aggregate
>> project doesn't have a package Builder?).
>> 
>> I've just found (with GPRBUILD GPL 2015) that the attributes Target and
>> Runtime are also ignored!
>
> I think this is reasonable. When aggregating several projects into an
> aggregate project, it is natural that they are build for the same
> target and same RTS. No?

No, I don't think so; what if you were building two sides of a
communications protocol to run on different hardware?

>From my point of view, you can't use aggregate GPRs for cross-builds
unless you're prepared to go through hoops to set up a configuration
GPR. Which could *not* be done except on the user's compilation platform
[unless of course you know different], so I'd have to write a
complicated set of instructions for users rather than providing a set of
GPRs that could be used out of the box.

>> These features seem to me to reduce the usefulness of aggregate projects
>> to the point of uselessness. Does anyone have positive experiences with
>> them?
>
> Yes. We use an aggregate project to set an environment variable
> (LDSCRIPT) that is used by the linker to locate the linker script. The
> value is derived from a scenario variable and it would thus not be
> easy to set it in the shell before invoking GPS or command-line
> tools. The aggregate project is thus a simple wrapper around the
> "real" project.

Which is exactly what I wanted to do, but couldn't.