Re: Aggregate GPRs

[Simon Wright <simon@pushface.org>]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> I see from the documentation[1] that, for projects built through the
>> aggregate project, package Builder is ignored 
>
> The section you reference does not say this; did you find it elsewhere?
>
> It does say the specific attribute Global_Compilation_Switches is
> ignored in standard projects, since it is overridden by the value given
> in the aggregate project.

Just before section 2.8 (that might be 5.8 in your version???), it says

   "For projects that are built through the aggregate, the package
   Builder is ignored, except for the Executable attribute which
   specifies the name of the executables resulting from the link of the
   main programs, and for the Executable_Suffix."

>> (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!
>
> In GNAT 2015 gnat_ugn.info, Target and Runtime are listed in setcion
> 5.9.10.1 as Project Level Configuration attributes. So they are not in
> package Builder.

No, nor are they in my GPR; just as a demo, I have

   project Testbed is
      for Main use ("testbed.adb");
      for Object_Dir use ".build";
      for Source_Dirs use (".", "../test-common");
      for Exec_Dir use ".";
      for Target use "arm-eabi";
      for Runtime ("ada") use Testbed'Project_Dir & "../arduino-due";
      package Builder is
         ...

and

   aggregate project Agg is
      for Project_Files use ("testbed.gpr");
   end Agg;

resulting in

   $ gprbuild -P agg
   gcc -c -gnatqQafoy -gnatwaL.X testbed.adb
   testbed.adb:41:06: file "start_freertos_scheduler.ads" not found

because it's using the wrong compiler, the wrong RTS (and the wrong
options, but at least ignoring package Builder is documented).

> Section 5.9.10 says configuration attributes are "usually found only in
> configuration project files".

"usually"? Clearly some missing use-case documentation here!

> I'm fully aware that the documentation for gprbuild often differs from
> what gprbuild actually does, but did you put these attributes in a
> config project file in your testing?

The auto-generated auto.cgpr has a hair-raising amount of detail, so no,
I didn't.

But you are right that if I copy .build/auto.cgpr to ./default.cgpr the
correct compiler is chosen.

>> These features seem to me to reduce the usefulness of aggregate
>> projects to the point of uselessness. Does anyone have positive
>> experiences with them?
>
> I've only used aggregrate projects to specify project_path; I find
> that very useful.

I was trying to specify a scenario variable. The result was that
gprbuild used the native compiler rather than the target!