Методы ускорения времени сборки в проекте с использованием битбокса?

Я работаю над проектом, который имеет множество рецептов битбокса и занимает много времени - до 13 часов в некоторых случаях. Я новичок в битботь, и я прошу о каком-то способе:

  • проверить, какие пакеты требуют больше для сборки.
  • проверить очень длинные зависимости (я уже использовал bitbake -g)
  • проверьте, есть ли какие-либо циклические зависимости и как их решить.
  • проверьте, есть ли рецепты, которые не используются и как безопасно удалить их.

или любые предложения по использованию любых инструментов для лучшего управления и понимания рецептов.

Или любые методы/способы ускорения процесса сборки в целом.

Оба предложения и точные методы приветствуются.

Дата EDIT 07/08/2013:

Нашел этот полезный инструмент для отслеживания зависимостей

https://github.com/scottellis/oe-deptools

Описание:

./oey.py -h

Usage: ./oey.py [options] [package]

Displays OE build dependencies for a given package or recipe.
Uses the pn-depends.dot file for its raw data.
Generate a pn-depends.dot file by running bitbake -g <recipe>.

Options:
-h      Show this help message and exit
-v      Show error messages such as recursive dependencies
-r      Show reverse dependencies, i.e. packages dependent on package
-f      Flat output instead of default tree output
-d <depth>      Maximum depth to follow dependencies, default and max is 10
-s      Show child package dependencies that are already listed
        as direct parent dependencies.

Provide a package name from the generated pn-depends.dot file.
Run the program without a package name to get a list of
available package names.

Ответы

Ответ 1

Это очень широкий вопрос!

Во-первых, вот краткое описание того, как проверять производительность сборки и зависимости при использовании проекта openembedded/yocto. Это отвечает на первую часть вопроса.

Какие пакеты занимают больше времени?

Используйте buildstats с помощью инструмента pybootchartgui, создайте диаграмму сборки.

Подробнее:

Установите USER_CLASSES += "buildstats" в $BUILDIR/conf/local.conf файл. Это приведет к сбою подробных данных о производительности в $BUILDDIR/tmp/buildstats/<DATE>. Затем используйте pybootchartgui.py script (в poky/scripts/pybootchartgui) для создания диаграммы. Это поможет вам локализовать возможные узкие места в сборке. Конечно, если у вас есть много рецептов, чтобы испечь, ваш график будет огромным. Чтобы удалить некоторый шум используйте опцию командной строки -m MINTIME.

Например:

poky/scripts/pybootchartgui/pybootchartgui.py -m 600 $BUILDDIR/tmp/buildstats/201312310904

будет отображать только задачи (do_compile, do_fetch и т.д.), которые занимают больше времени чем 10 минут (600 секунд) для запуска.

Как проверить зависимости пакетов?

Чтобы изучить зависимости конкретного пакета, используйте depexp утилита. Например, для изучения зависимостей eglibc используйте:

bitbake -g -u depexp eglibc

Это даст лучшее понимание того, что каждый рецепт зависит от как при запуске, так и во время компиляции.

Как проверить, есть ли какие-либо циклические зависимости и как их решить?

bitbake автоматически определяет круговые зависимости и выводит сообщение об ошибке, когда такое происходит. Сообщение об ошибке содержит имя пакетов, вызывающих эту циклическую зависимость.

Как проверить, есть ли рецепты, которые не используются, и как их безопасно удалить?

bitbake автоматически вычисляет зависимости и не будет создавать пакеты, которые не нужны вашей цели. Если вы обнаружили в своем изображении некоторые нежелательные пакеты, и вы хотите их удалить:

  • используйте bitbake -g -u depexp <TARGET>, чтобы проверить, как пакет втягивается
  • изменить необходимые рецепты в вашем слое (например, создав bbappend), чтобы устранить зависимость вручную

Улучшение общей производительности сборки

Наконец, некоторые советы о том, как улучшить общую производительность сборки. Это отвечает на вторую часть вопроса.

  • Очистите свои зависимости (bitbake -g -u depexp <TARGET> - ваш друг). Строительство меньше материала занимает меньше времени.
  • Bitbake может автоматически кэшировать выходные данные сборки и использовать ее для будущие сборки, этот кеш называется "кэшем разделяемого состояния" и управляемый переменной SSTATE_DIR в local.conf.
  • Задайте переменные BB_NUMBER_THREADS и PARALLEL_MAKE в local.conf для соответствия вашим машинные ресурсы. Эти переменные контролируют, сколько задач выполняется параллельно и сколько процессов "make" должно выполняться параллельно (-j ) соответственно.
  • Поместите каталог "build" на свой собственный диск.
  • Используйте файловую систему без файловой системы ext4 и с этим монтированием options: noatime,barrier=0,commit=6000. ПРЕДУПРЕЖДЕНИЕ. Это делает ваш hdd ненадежны в случае потерь мощности. Не храните ничего из значение на этом hdd.
  • создание изображений с пакетами -dev и/или -dbg увеличивает do_rootfs время задачи значительно. Убедитесь, что вы включили их (см. EXTRA_IMAGE_FEATURES в local.conf) только, если это необходимо.
  • openembedded и yocto поддерживают icecream (распределенная компиляция). См. Класс icecc и этот пост.
  • Купить более быструю машину;)

Литература:

Yocto Build Performance Wiki

Инструменты графического интерфейса Bitbake

Ответ 2

Я пробовал распределенный способ компиляции несколько лет назад, но конфигурация окружения сервера не настолько гибка для работы агента CI, и сборка не подходит для мути-людей.

Я пробовал анализировать с временем сборки buildstats, и нашел, что время сборки почти стоит всех путем компиляции 3-го партийного компонента с открытым исходным кодом, который я вообще не изменял.

Таким образом, самый простой и эффективный способ - использовать "sstate-cache", чтобы избежать повторной сборки немодифицированных компонентов.

То, как я использую в своей работе, - это пространство времени для торговли

  • Скомпилируйте весь проект bitbake, вы можете найти много файлов .tgz в разделе "build/sstate-cache"

  • Добавьте и скопируйте все эти файлы в git для отслеживания изменений файла

  • Скомпилируйте весь проект еще раз, не очистив его

  • cd в свой статус "build/sstate-cache", git и обнаружил файлы, которые были изменены, удалили и зафиксировали на git

  • Затем очистите проект без .tgzs в разделе "sstate-cache", "Торговля пространства для времени" выполнена

Список "немодифицированных" файлов может быть изменен в соответствии с вашим собственным проектом.

Сокращение времени сборки для меня составляет от 1 часа до 10 минут

Надеюсь, это было бы полезно