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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Received: by 2002:a0c:adef:: with SMTP id x44mr891793qvc.153.1562287844385;
        Thu, 04 Jul 2019 17:50:44 -0700 (PDT)
X-Received: by 2002:a9d:39a6:: with SMTP id y35mr661954otb.81.1562287844109;
 Thu, 04 Jul 2019 17:50:44 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!news.muarf.org!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!m24no7600198qtm.0!news-out.google.com!s58ni291qts.0!nntp.google.com!m24no7600191qtm.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Thu, 4 Jul 2019 17:50:43 -0700 (PDT)
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=137.103.119.68;
 posting-account=ShYTIAoAAABytvcS76ZrG9GdaV-nXYKy
NNTP-Posting-Host: 137.103.119.68
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <82b1413f-8dfb-4b1c-9a8d-da6398bac965@googlegroups.com>
Subject: aggregate gpr project paths
From: sbelmont700@gmail.com
Injection-Date: Fri, 05 Jul 2019 00:50:44 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: reader01.eternal-september.org comp.lang.ada:56815
Date: 2019-07-04T17:50:43-07:00
List-Id: <comp.lang.ada>

Hi,

Does anyone know (or at least surmise) what the rules are regarding the Pro=
ject_Path attribute when one aggregate gpr project file builds another?

Rules as written, it says:

"Each aggregate project has its own Project_Path (thus if agg1.gpr includes=
 agg2.gpr, they can potentially both have a different Project_Path)...the p=
roject path for agg2.gpr is not influenced by the attribute agg1=E2=80=99Pr=
oject_Path, nor is agg1 influenced by agg2=E2=80=99Project_Path."

Ok, so agg1 and agg2 each get their own Project_Path, both completly separa=
te, not influenced by each other, and never the two shall meet.  Fine.

So I try it, using something like this:

aggregate project a is
  for project_path use ("dir1");
  for project_files use ("b.gpr");
end a;

aggregate project b is
  for project_path use ("dir2");
  for project_files use ("default.gpr");
end b;

And expect that, given the documentation, default.gpr should only be able t=
o with in gpr files from dir2.  But this is not the case; default.gpr can O=
NLY see dir1, and not dir2.  Cranking up the verbosity (-vP2) gives the err=
or message "'for Project_Path' has no effect except in root aggregate" when=
 parsing b.gpr, which implies an exact opposite behavior from that describe=
d: b actually inherits the Project_Path from a, can NOT have a different on=
e, and is directly influenced by it.  Indeed, if I change a to have both di=
r1 and dir2 (with nothing specified in b), default can see both directories=
.

Does anyone know what the expected behavior actually is, or ought to be?  I=
 can't even untangle it to the point where I could call it a bug or not.  I=
f it is the case where b inherits the path from a, is there any standard wa=
y to reference it or append to it?

GPRBUILD Community 2019 (20190517) (x86_64-pc-linux-gnu)

-sb