Библиотека сайта rus-linux.net
Проект Yocto
Глава 23 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: The Yocto Project
Автор: Elizabeth Flanagan
Перевод: А.Панин
Планировщик BitBake
После того, как система BitBake произвела разбор файлов конфигурации и создала хранилище данных, ей необходимо произвести разбор рецептов, требующихся для создания образа, и сформировать цепочку сборки. Эта операция является одним из наиболее существенных усовершенствований системы BitBake. Изначально система BitBake получала приоритеты сборки из рецепта. Если в рамках рецепта была заданна переменная DEPENDS, предпринималась попытка установления того, какие программные компоненты следует собрать для того, чтобы выполнить заданные этой переменной требования. В том случае, если выполнение задачи завершалось неудачей из-за того, что для сборки не хватало какого-либо предварительного условия, задача просто убиралась для последующего повторного выполнения. Этот подход имел очевидные недостатки, связанные и с производительностью, и с надежностью.
Так как предварительно формируемой цепочки зависимостей не создавалось, порядок выполнения задач устанавливался непосредственно во время сборки. Это обстоятельство ограничивало возможности системы BitBake однопоточным режимом сборки. Для того, чтобы продемонстрировать, насколько непроизводительной может оказаться сборка образов с помощью BitBake в однопоточном режиме, следует упомянуть о том, что при сборке образа самого малого размера "core-image-minimal" на стандартной машине разработчика в 2011 году (Intel Core i7 с 16 ГБ оперативной памяти DDR3) потребуется около трех или четырех часов для сборки полного набора инструментов кросскомпиляции и применения их для создания пакетов, которые впоследствии будут использоваться для создания образа. Для сравнения, сборка на той же машине с переменными BB_NUMBER_THREADS со значением 14 и PARALLEL_MAKE со значением "-j 12" занимает от 30 до 40 минут. Как можно представить, работа в однопоточном режиме без предварительного формирования последовательности выполнения задач с использованием более медленного аппаратного обеспечения с меньшим объемом оперативной памяти, большое количество которой может быть занято копиями всего хранилища данных, потребует значительного большего времени.
Зависимости
DEPENDS, являются чем-либо, что нам требуется предварительно предоставить для того, чтобы сборочная система Poky смогла собрать требуемый пакет, в то время, как зависимости времени исполнения, задаваемые с помощью переменной RDEPENDS, требуют от образа установки заданных с помощью переменной RDEPENDS пакетов наряду с запрашиваемым пакетом. Возьмем, например, пакет с названием task-core-boot. Если мы рассмотрим рецепт этого пакета, расположенный по пути
meta/recipes-core/tasks/task-core-boot.bb
мы обнаружим две установленные переменные BitBake: RDEPENDS и DEPENDS. Система BitBake использует эти два поля в процессе создания цепочки зависимостей.
task-core-boot.bb, демонстрирующий использование переменных DEPENDS и RDEPENDS:
DEPENDS = "virtual/kernel" ... RDEPENDS_task-core-boot = "\ base-files \ base-passwd \ busybox \ initscripts \ ...
Пакеты не являются единственными элементами, зависимости которых отслеживаются средствами BitBake. Задачи также имеют свои зависимости. В рамках очереди выполнения сборки BitBake мы выделяем четыре типа задач: внутренне-зависимые задачи, зависимые на основе значения переменной DEPENDS задачи, зависимые на основе значения переменной RDEPENDS задачи, а также зависимые от задач других пакетов задачи.
Внутренне-зависимые задачи устанавливаются в рамках рецепта и позволяют добавить задачу перед и/или после другой задачи. Например, мы можем добавить задачу с названием do_deploy в рецепт путем добавления строки addtask deploy before do_build after do_compile. Эта строка позволит добавить зависимость для запуска задачи do_deploy перед запуском задачи do_build, но после завершения выполнения задачи do_compile. Зависящие от значений переменных DEPENDS и RDEPENDS задачи являются задачами, выполняющимися после обозначенной задачи. Например, если мы хотим выполнить задачу do_deploy для пакета после выполнения задачи do_install для пакетов, заданных переменными DEPENDS или RDEPENDS, наш рецепт будет включать строку do_deploy[deptask] = 'do_install' или do_deploy[rdeptask] = 'do_install'. В случае задач, зависимых от задач других пакетов, если мы хотим чтобы заданная задача зависела от задачи другого пакета, мы добавим строку, изменив приведенный выше пример использования функции do_deploy следующим образом: do_deploy[depends] = "<название целевого пакета>:do_install".
Далее: Очередь выполнения сборки