CODEWITHSUNDEEP
runtimeprojectadagnatgprbuild
Rodeo
Rodeo

Reputation: 171

GPRbuild: `runtime` attribute ignored in aggregated project

I am working on a few libraries for coding Arduinos in Ada. Each library is its own project, and I have an aggregate project that aggregates the libraries. I need to specify the runtime for each project since they are running on different chips. So for example I have something like this:

aggregate project Agg is

   for Project_Files use ("due/arduino_due.gpr",
                          "uno/arduino_uno.gpr",
                          "nano/arduino_nano.gpr");
   -- ...
end Agg;

library project Arduino_Due is
   -- Library_Dir, _Name, and _Kind attributes ...
   -- Target attribute ...
   for Runtime ("Ada") use "../runtimes/arduino_due_runtime";

   package Compiler is
      -- Driver and Switches attributes ...
   end Compiler;

And similar projects for the Uno and Nano. Building arduino_due.gpr directly works fine. It finds my runtime in the specified folder as it should. However, when I build agg.gpr, I get

fatal error, run-time library not installed correctly
cannot locate file system.ads

This occurs whether I use an absolute path or a relative path, and also occurs when the relative path is concatenated with Project'Project_Dir. However, if rather than using the Runtime attribute I use the compiler switch --RTS=..., then it works, but only if I use a relative path that is prefixed with Project'Project_Dir. An absolute path or a plain relative path will result in the error gprbuild: invalid runtime directory runtimes/arduino_due_runtime.

So what's going on here? This behavior seems inconsistent and I couldn't find anything in the docs about it so I suspect a bug. But I thought I'd ask here first in case I'm doing something wrong. Maybe I should just be using child projects, or project extension?

Upvotes: 1

Views: 320

Answers (1)

Simon Wright
Simon Wright

Reputation: 25501

This isn’t a bug, it’s a feature :-).

See this rejected issue.

There are two things:

  • Several options are only recognised in the main project, and if you use an aggregate project that is the main project.

  • Package Builder is ignored in aggregated projects.

My conclusion: aggregate projects don’t suit your use case, or mine. As I said in the issue noted above, back to Makefiles (or scripts).

Part of the design intent is that aggregate projects should share code and compilations: as 2.8.4 of the manual says,

The loading of aggregate projects is optimized in GPRbuild, so that all files are searched for only once on the disk (thus reducing the number of system calls and yielding faster compilation times, especially on systems with sources on remote servers). As part of the loading, GPRbuild computes how and where a source file should be compiled, and even if it is located several times in the aggregated projects it will be compiled only once.

Since there is no ambiguity as to which switches should be used, files can be compiled in parallel (through the usual -j switch) and this can be done while maximizing the use of CPUs (compared to launching multiple GPRbuild commands in parallel).

Upvotes: 3

Related Questions