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

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

0 голосов
/ 13 марта 2019

Я работаю над несколькими библиотеками для кодирования 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 Ответ

3 голосов
/ 13 марта 2019

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

См. этот отклоненный вопрос .

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

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

  • Компоновщик пакетов игнорируется в агрегированных проектах.

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

<Ч />

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

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

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

...