Aggregate GPRs

Aggregate GPRs

[Simon Wright]

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!

These features seem to me to reduce the usefulness of aggregate projects
to the point of uselessness. Does anyone have positive experiences with
them?

[1] http://docs.adacore.com/gprbuild-docs/html/share/gnat_project_manager.html#package-builder-in-aggregate-projects

Re: Aggregate GPRs

[Stephen Leake]

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.

> (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.

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

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?

> 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.

-- 
-- Stephe

Re: Aggregate GPRs

[Simon Wright]

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!

Re: Aggregate GPRs

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

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

That is, if I build with the standard project, .build/auto.cgpr has
the correct target, runtime values; if I copy it to ./default.cgpr, the
aggregate project uses the correct values.

Re: Aggregate GPRs

[Mark Lorenzen]

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?

> 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.

Regards,

Mark L

Re: Aggregate GPRs

[Simon Wright]

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.