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

#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. Ха, это странно. Кажется странным, что система сборки для языка, столь хорошо подходящего для системной / встроенной разработки, не поддерживает проекты с несколькими целями.