GPRbuild: атрибут `runtime` игнорируется в агрегированном проекте

Question

Я работаю над несколькими библиотеками для кодирования Arduinos в Ada. Каждая библиотека - это собственный проект, и у меня есть сводный проект, который объединяет библиотеки. Мне нужно указать время выполнения для каждого проекта, так как они работают на разных чипах. Так, например, у меня есть что-то вроде этого:

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;

И аналогичные проекты для Уно и Нано. Строительство arduino_due.gpr напрямую работает нормально. Он находит мое время выполнения в указанной папке, как и должно. Тем не менее, когда я строю agg.gpr, Я получил

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

Это происходит независимо от того, использую ли я абсолютный или относительный путь, а также происходит, когда относительный путь объединяется с Project'Project_Dir, Однако, если вместо использования Runtime Атрибут Я использую переключатель компилятора --RTS=... тогда это работает, но только если я использую относительный путь с префиксом Project'Project_Dir , Абсолютный путь или простой относительный путь приведет к ошибке gprbuild: invalid runtime directory runtimes/arduino_due_runtime,

Так что здесь происходит? Такое поведение кажется противоречивым, и я не смог найти в документации ничего по этому поводу, поэтому я подозреваю, что это ошибка. Но я решил сначала спросить здесь, если я делаю что-то не так. Может быть, я должен просто использовать дочерние проекты или расширение проекта?

Answer 1

Это не ошибка, это особенность:-).

Смотрите эту отклоненную проблему.

Есть две вещи:

• Несколько опций распознаются только в основном проекте, и если вы используете агрегатный проект, который является основным проектом.

• Package Builder игнорируется в агрегированных проектах.

Мой вывод: агрегатные проекты не подходят ни вашему варианту использования, ни моему. Как я уже говорил в проблеме, упомянутой выше, вернемся к Makefiles (или скриптам).

---

Частью замысла проекта является то, что агрегатные проекты должны совместно использовать код и компиляции: как указано в 2.8.4 руководства,

Загрузка агрегатных проектов оптимизирована в GPRbuild, так что все файлы ищутся только один раз на диске (таким образом, сокращается количество системных вызовов и сокращается время компиляции, особенно в системах с источниками на удаленных серверах). В рамках загрузки GPRbuild вычисляет, как и где должен быть скомпилирован исходный файл, и даже если он находится несколько раз в агрегированных проектах, он будет скомпилирован только один раз.

Поскольку нет никакой двусмысленности относительно того, какие ключи следует использовать, файлы можно компилировать параллельно (через обычный ключ -j), и это можно сделать при максимальном использовании процессоров (по сравнению с параллельным запуском нескольких команд GPRbuild).