#runtime #project #ada #gnat #gprbuild
#время выполнения #проект #ada #gnat #gprbuild
Вопрос:
Я работаю над несколькими библиотеками для кодирования 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;
И аналогичные проекты для Uno и Nano. Сборка 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
.
Итак, что здесь происходит? Такое поведение кажется непоследовательным, и я не смог найти ничего в документах об этом, поэтому я подозреваю ошибку. Но я подумал, что сначала спрошу здесь на случай, если я делаю что-то не так. Может быть, мне следует просто использовать дочерние проекты или расширение проекта?
Ответ №1:
Это не ошибка, это особенность :-).
Смотрите эту отклоненную проблему.
Есть две вещи:
-
Несколько параметров распознаются только в основном проекте, и если вы используете агрегированный проект, который является основным проектом.
-
Конструктор пакетов игнорируется в агрегированных проектах.
Мой вывод: агрегированные проекты не подходят ни для вашего варианта использования, ни для моего. Как я уже говорил в упомянутой выше проблеме, вернемся к Makefiles (или скриптам).
Частью замысла проекта является то, что агрегированные проекты должны совместно использовать код и компиляции: как сказано в 2.8.4 руководства,
Загрузка aggregate projects оптимизирована в GPRbuild, так что поиск всех файлов на диске выполняется только один раз (таким образом, сокращается количество системных вызовов и сокращается время компиляции, особенно в системах с исходными кодами на удаленных серверах). Как часть загрузки, GPRbuild вычисляет, как и где должен быть скомпилирован исходный файл, и даже если он находится несколько раз в агрегированных проектах, он будет скомпилирован только один раз.
Поскольку нет никакой двусмысленности в отношении того, какие переключатели следует использовать, файлы могут быть скомпилированы параллельно (с помощью обычного переключателя -j), и это может быть сделано при максимальном использовании процессоров (по сравнению с параллельным запуском нескольких команд GPRbuild).
Комментарии:
1. Ха, это странно. Кажется странным, что система сборки для языка, столь хорошо подходящего для системной / встроенной разработки, не поддерживает проекты с несколькими целями.