Глава 13. Переменные
В этой главе перечислены и описаны основные переменные, используемые системой сборки OE.
A
Расширение поля ABI1 канонического имени GNU для архитектуры (например, “eabi”). Расширения ABI задаются во включаемых файлах для машин. Например, файл meta/conf/machine/include/arm/arch-arm.inc задает расширение ABIEXTENSION = “eabi”.
Задает необходимость создания на выходе пустых пакетов, которые BitBake по умолчанию не создает. Принятое по умолчанию поведение может создавать проблемы в тех случаях, когда RDEPENDS или другое жесткое требование во время работы указывает необходимость пакета.
Как и в других переменных управления пакетами требуется суффикс в виде имени пакета, как показано ниже.
ALLOW_EMPTY_${PN} = "1"
ALLOW_EMPTY_${PN}-dev = "1"
ALLOW_EMPTY_${PN}-staticdev = "1"
Перечисляет команды в пакете, которым нужна схема вариативного именования. Иногда одна команда предоставляется несколькими пакетами и в таких случаях системе сборки OE приходиться использовать систему вариантов для создания разных имен двоичных файлов, чтобы команды могли существовать совместно.
При использовании этой переменной указывается список команд пакета, которые применяются также в другом пакете, как показано ниже. Например, если пакет busybox имеет 4 таких команды, можно указать ALTERNATIVE_busybox = “sh sed test bracket”. Дополнительная информация о вариантах именования приведена в параграфе 6.141. update-alternatives.bbclass.
Применяется системой вариантов (alternative) для отображения дублированных команд на реальные файлы. Например, если команда bracket, поддерживаемая пакетом busybox, дублируется в другом пакете, нужно использовать переменную ALTERNATIVE_LINK_NAME для указания реального местоположения файла.
ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/["
В этом примере двоичный файл команды bracket ([) из busybox размещается в /usr/bin/. Если переменная ALTERNATIVE_LINK_NAME не задана, используется ${bindir}/name. (см. 6.141. update-alternatives.bbclass).
Применяется системой вариантов для установки приоритета дублированных команд. Переменная позволяет создать единственный принятый по умолчанию вариант, независимо от команды или пакета, а также принятые по умолчанию варианты для конкретных пакетов (6.141. update-alternatives.bbclass). Варианты синтаксиса даны ниже.
ALTERNATIVE_PRIORITY = "priority" ALTERNATIVE_PRIORITY[name] = "priority" ALTERNATIVE_PRIORITY_pkg[name] = "priority"
Применяется системой вариантов для создания используемого по умолчанию местоположения для дубликатов команд. Переменная позволяет создать единственный принятый по умолчанию вариант, независимо от команды или пакета, а также принятые по умолчанию варианты для конкретных пакетов (6.141. update-alternatives.bbclass). Варианты синтаксиса даны ниже.
ALTERNATIVE_TARGET = "target" ALTERNATIVE_TARGET[name] = "target" ALTERNATIVE_TARGET_pkg[name] = "target"
Если переменная ALTERNATIVE_TARGET не определена, наследуется значение из ALTERNATIVE_LINK_NAME.
При совпадении ALTERNATIVE_LINK_NAME и ALTERNATIVE_TARGET к цели для ALTERNATIVE_TARGET добавляется “.{BPN}“. Если указанный файл не переименован, система вариантов переименует его, чтобы избежать необходимости переименования вариантов в задаче do_install, сохраняя при необходимости поддержку команды.
Переопределяет список добавленных строк для каждой цели, указанной с LABELS
(использование переменной рассмотрено в описании класса grub-efi).
Сокращенная команда и аргументы для работы ar.
При использовании с классом archiver определяет тип информации, использованной для создания архива. Эту переменную можно использовать для создания архивов исправленных (patched) и оригинальных исходных кодов, настроенных кодов и т. п. С помощью описанных ниже флагов.
ARCHIVER_MODE[src] = “original”
Используются оригинальные (неупакованные) исходные файлы.
ARCHIVER_MODE[src] = “patched”
Используются исправленные (patched) исходные файлы (принято по умолчанию).
ARCHIVER_MODE[src] = “configured”
Используются настроенные исходные файлы.
ARCHIVER_MODE[diff] = “1”
Используются различия (patch) между do_unpack и do_patch.
ARCHIVER_MODE[diff-exclude] ?= “file file …”
Список файлов и каталогов для исключения из diff.
ARCHIVER_MODE[dumpdata] = “1”
Используются данные окружения.
ARCHIVER_MODE[recipe] = “1”
Используются файлы заданий и включаемые файлы.
ARCHIVER_MODE[srpm] = “1”
Используются файлы RPM.
Информация об использовании переменной приведена в файле meta/classes/archiver.bbclass дерева исходных кодов.
Сокращенная команда и аргументы для работы ассемблера.
Список имен заданий (PN values), которые BitBake не будет пытаться собрать, предполагая, что они уже собраны. В OpenEmbedded-Core переменная ASSUME_PROVIDED задает естественные инструменты, которые не нужно собирать. Примером служит задание git-native, его указание позволяет применять Git хоста без сборки git-native.
Предоставляет дополнительные данные о провайдере общих библиотек, которые дополняют или переопределяют информацию, автоматически предоставляемую системой. Элементы разделяются пробелами.
Например, приведенная ниже форма добавляет провайдера shlib с именем shlibname в packagename с необязательным указанием версии.
shlibname:packagename[_version]
Следующий пример добавляет общую библиотеку libEGL.so.1 как предоставляемую пакетом libegl-implementation.
ASSUME_SHLIBS = "libEGL.so.1:libegl-implementation"
Почтовый адрес для контактов с исходным автором или авторами для передачи правок и сообщений об ошибках.
При наследовании класса debian (принято по умолчанию) переменная задает пакеты, которые следует проверять на предмет библиотек и переименовывать в соответствии с правилами Debian. По умолчанию принято значение ${PACKAGES}, которое включает класс debian для всех пакетов, явно создаваемых заданием.
Включает создание автоматического меню для загрузчика syslinux. Переменная должна устанавливаться в задании, класс syslinux проверяет ее.
Когда для переменной SRCREV установлено значение данной переменной, это задает использование последнего выпуска исходных кодов из репозитория. Если используется SRCREV = “${AUTOREV}” для поиска последней версии программы, нужно убедиться, что PV содержит ${SRCPV}. Предположим, что имеется задание для ядра, наследующее класс kernel и применяется приведенный выше оператор. В этом случае ${SRCPV} не попадет автоматически в PV
и
нужно изменить PV в задании для включения ${SRCPV}.
Дополнительные сведения приведены в разделе Automatically Incrementing a Binary Package Revision Number [2].
AVAILTUNES
Список определенных настроек CPU и ABI, доступных для системы сборки OE. С конкретной конфигурацией машины могут быть совместимы не все настройки и могут возникать несовместимости с разными библиотеками в конфигурации Multilib. Настройки добавляются с использованием оператора BitBake += в конец списка через пробел (см. раздел Basic Syntax [4]).
B
Каталог внутри каталога сборки, куда система сборки OE помещает объекты, созданные в процессе сборки задания. По умолчанию этот каталог совпадает с каталогом S,
определяемым
как
S = "${WORKDIR}/${BP}"
Можно разделить каталог S
и
каталог, указанный переменной B. Большинство заданий, применяющих автоматические инструменты поддерживают такое разделение. По умолчанию система сборки использует отдельные каталоги для gcc и некоторых заданий для ядра.
Перечисляет «лишь рекомендуемые» (recommended-only) пакеты, которые не устанавливаются. К таким пакетам относятся указанные через переменную RRECOMMENDS. Можно предотвратить установку любого из таких пакетов, указав его в переменной BAD_RECOMMENDATIONS.
BAD_RECOMMENDATIONS = "package_namepackage_namepackage_name..."
Эту переменную можно задать глобально в файле local.conf или присоединить к заданию для конкретного образа, используя переопределение имени задания, как показано ниже.
BAD_RECOMMENDATIONS_pn-target_image= "package_name"
Важно отметить, что при отказе от установки пакетов с помощью этой переменной и наличии зависимости от них других пакетов (указанных в переменной RDEPENDS для задания), система сборки OE будет игнорировать запрос и установит пакеты для предотвращения нарушений в зависимостях.
Переменная поддерживается только при наличии менеджеров пакетов IPK и RPM, но не поддерживается для DEB.
См. также описания переменных NO_RECOMMENDATIONS и PACKAGE_EXCLUDE.
Имя каталоги библиотек для настройки CPU или ABI, которое применяется лишь в контексте Multilib (см. раздел Combining Multiple Versions of Library Files into One Image [2]). Переменная определяется во включаемых файлах машины в дереве исходного кода. Если Multilib не используется, переменная имеет значение lib.
Задает базу для сетевого каталога, применяемого во всех задания (по умолчанию ${TMPDIR}/work).
Задает список разделенных пробелами хостов, которые сборщику разрешено использовать для получения нужных исходных кодов. Ниже рассмотрены некоторые аспекты использования этой переменной.
- Список хостов применяется лишь в при установке
BB_NO_NETWORK= “0” или не заданной переменной. - Ограниченно поддерживаются шаблоны для начальной части имени хоста. Например, приведенная ниже строка будет соответствовать
git.gnu.org,ftp.gnu.org
и
foo.git.gnu.org.BB_ALLOWED_NETWORKS = "*.gnu.org"
Символ
*
работает
только в начальной частиимени,
отделенной точкой от остального имени
и не допускается его использование в
других местах. Например, можно указать
*.foo.bar,
но*aa.foo.barне будет работать. - Зеркала, не указанные в списке хостов, будут пропускаться с указанием в отладочном выводе.
- Попытка доступа в сети, не указанную в списке, завершится отказом.
Использование BB_ALLOWED_NETWORKS вместе с переменной PREMIRRORS
очень в
полезно. Добавление хоста PREMIRRORS
позволяет
получать исходные коды с этого хоста и
предотвращает ошибки, возникающие когда
неразрешенный хост указан в SRC_URI. Это связано с тем, что сборщик не пытается использовать хосты из SRC_URI после успешной выборки на основе PREMIRRORS.
Определяет обработку в BitBake ситуаций, когда файл дополнения (.bbappend) не имеет соответствующего задания (.bb). Такое часто возникает при рассинхронизации уровней (например, oe-core нужно задания, для которого старой версии уже нет, а другой уровень еще не обновлен с новой версией задания). По умолчанию в такой ситуации возникает критическая ошибка и это обеспечивает наиболее безопасный вариант. Поведение можно изменить указав для переменной BB_DANGLINGAPPENDS_WARNONLY значение “1”, “yes” или “true” в файле local.conf каталога сборки.
Отслеживает доступное пространство и inode при сборке, позволяя контроль по этим параметрам (по умолчанию отключен). Переменная задается в форме BB_DISKMON_DIRS = “<action>,<dir>,<threshold> […]”, где
<action>
ABORT – незамедлительное прерывание сборки при превышении порога.
STOPTASKS – остановка сборки после завершения текущих задач в случае превышения порога.
WARN – вывод предупреждения и продолжение сборки. Последующие предупреждения выдаются в соответствии с переменной BB_DISKMON_WARNINTERVAL, которая должна быть определена.
<dir>
Любые каталоги для мониторинга, разделенные пробелами. Если каталоги расположены на одном устройстве, отслеживается лишь первый.
<threshold>
Минимальное пространство на диске или/и минимальное число inode. Можно применять суффиксы G (Гбайт), M (Мбайт), K (Кбайт, принято по умолчанию). Не следует использовать GB, MB или KB.
BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
Первый пример работает только при установке переменной BB_DISKMON_WARNINTERVAL и заставляет систему сборки немедленно прерывать процесс, если свободное пространство в ${TMPDIR} становится меньше 1 Гбайта или число inode ниже 100 Кбайт. Поскольку указаны 2 каталога, система сборки будет выдавать предупреждение при снижении свободного места в ${SSTATE_DIR} меньше 1 Гбайт или inode меньше 100 Кбайт. Следующие предупреждения будут выдаваться с интервалами, заданными BB_DISKMON_WARNINTERVAL.
Второй пример будет останавливать сборку по завершении задач, когда свободное место в ${TMPDIR} станет меньше 1 Гбайт. Число inode не отслеживается.
Третий пример задает немедленное прерывание сборки при числе свободных inode в ${TMPDIR} меньше 100 Кбайт без отслеживания свободного места в каталоге.
Задает интервал предупреждений о нехватке места на диске и свободных inode. Для использования переменной нужно задать BB_DISKMON_DIRS с действием WARN. В процессе сборки при снижении свободного места будут выдаваться предупреждения с заданным интервалом. Если при установке BB_DISKMON_DIRS = “WARN” интервал не указан, используется BB_DISKMON_WARNINTERVAL = “50M,5K”. При задании переменной в файле конфигурации применяется форма BB_DISKMON_WARNINTERVAL = “<disk_space_interval>,<disk_inode_interval>”.
<disk_space_interval>
Интервал свободного пространства в G (Гбайт), M (Мбайт) или K (Кбайт). Не используйте GB, MB или KB.
<disk_inode_interval>
Интервал свободных inode в G (Гбайт), M (Мбайт) или K (Кбайт). Не используйте GB, MB или KB.
BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
BB_DISKMON_WARNINTERVAL = "50M,5K"
Эти переменные заставляют BitBake выдавать предупреждения каждый раз, когда свободное место в каталоге ${SSTATE_DIR}50 Мбайт или число свободных inode – на 5 Кбайт. Предупреждения будут выдаваться после того, как свободное место станет меньше 1 Гбайт или число свободных inode – меньше 100 Кбайт.
снижается на
Заставляет систему сборки размещать архивы репозиториев исходного кода (например, Git), включая метаданные, в каталоге DL_DIR. Для повышения производительности система сборки OE п умолчанию не сохраняет такие архивы.
Переменная устанавливается в файле local.conf каталога сборки.
Максимальное число задач, которые BitBake следует запускать параллельно. Система сборки OE автоматически устанавливает для этой переменной число ядре на хосте сборки. Например, в системе с 2-ядерным процессором и поддержкой hyper-threading по умолчанию задается BB_NUMBER_THREADS = “4”. Для 1-процессорных систем не следует переопределять эту переменную. Оптимизация скорости сборки описана в Speeding Up a Build [2].
Указывает время (в секундах), по истечение которого сервер BitBake выключается при отсутствии активности. Например, в файле local.conf можно указать 20-секундное ожидание в виде BB_SERVER_TIMEOUT = “20”. Для постоянной работы сервера следует установить BB_SERVER_TIMEOUT = “-1”.
Позволяет расширить задание для сборки вариантов программ. Существуют распространенные варианты заданий, такие как «естественные» (например, quilt-native, копирующее Quilt для работы на системе сборки), «кросс-» (например, gcc-cross для создания на сборочной машине программ для работы на целевой платформе MACHINE), nativesdk для машины SDK вместо MACHINE и mulitlib в форме multilib:multilib_name. Для сборки разных вариантов задания с минимальным количеством кода обычно просто добавляются в задание приведенные ниже строки.
BBCLASSEXTEND =+ "native nativesdk"
BBCLASSEXTEND =+ "multilib:multilib_name"
Механизм BBCLASSEXTEND создает варианты задания, переписывая значения переменных и применяя переопределения, такие как _class-native. Например, для создания естественного (native) варианта задания переменная DEPENDS в задании foo переписывает как DEPENDS для foo-native.
Даже при использовании BBCLASSEXTEND
задание, что вносит некоторые ограничения. Например, невозможно включить разные файлы в зависимости от варианта, поскольку оператор include обрабатывается в процессе разбора задания.
анализируется однократно
Список имен настроенных уровней, используемых для поиска других переменных BBFILE_*. Обычно каждый уровень добавляет свое имя в конце этой переменной в своем файле conf/layer.conf.
Переменная, которая преобразуется для сопоставления с файлами из переменной BBFILES в определенном слое. Эта переменная используется в файле conf/layer.conf и должна иметь суффикс с именем конкретного слоя (например, BBFILE_PATTERN_emenlow).
Задает уровень приоритета для файлов заданий уровня. Эта переменная полезна в случаях, когда одноименные задания указаны в разных уровнях. Установка переменной позволяет задать приоритет заданий своего уровня, позволяя сделать его предпочтительным по сравнению с другими. Предпочтения, задаваемые этой переменной взаимодействуют с версиями заданий (переменная PV). Например, уровень, имеющий задание с более высоким значением PV, может иметь меньшее значение BBFILE_PRIORITY и быть менее предпочтительным.
Большее значение BBFILE_PRIORITY означает более высокий приоритет. Если переменная не задана, ее значение устанавливается на основе зависимостей уровня (см. LAYERDEPENDS). Если уровень не имеет зависимостей и приоритет не задан, определяется минимальным заданным приоритетом + 1 (т. е. 1, если приоритет не задан).
С помощью команды bitbake-layers show-layers можно посмотреть все настроенные уровни с их приоритетами.
Разделенный пробелами список файлов заданий, который BitBake использует для сборки программ. При указании файлов заданий можно применять синтаксис Python glob.
Активирует содержимое при наличии идентифицированных уровней, которые задаются коллекциями, определенными в них. Переменная используется для исключения файлов .bbappend, для которых соответствующие файлы .bb размещены на уровне, пытающемся изменить другие уровни, но не желающем задавать жесткую зависимость от этих уровней. Переменная BBFILES_DYNAMIC задается в форме collection_name:filename_pattern. Пример указывает имена двух коллекций и два шаблона имен файлов.
BBFILES_DYNAMIC += " \
clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \
core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \
"
Другой пример показывает сообщение об ошибке при обнаружении непригодной записи и разбор прерывается.
ERROR: BBFILES_DYNAMIC entries must be of the form <collection name>:<filename pattern>, not:
/work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
/work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
Управляет отображением журнала сборки программой BitBake при возникновении отказов.
При установленной переменной BBINCLUDELOGS задает максимальное число строк из журнала задачи для отображения в случаях отказа. По умолчанию журнал выводится целиком.
Список уровней, включаемых в сборку. Переменная указывается в файле bblayers.conf каталога сборки. Например,
BBLAYERS = " \
/home/scottrif/poky/meta \
/home/scottrif/poky/meta-poky \
/home/scottrif/poky/meta-yocto-bsp \
/home/scottrif/poky/meta-mykernel \
"
Здесь включены 4 уровня, один из которых (meta-mykernel).
является пользовательским
Управляет исключением файлов заданий и дополнений из обработки BitBake, «пряча» ненужные файлы. BitBake игнорирует задания и дополнения, соответствующие выражениям маски. Значение переменной передается компилятору регулярных выражений Python, в маске применяется синтаксис Python Regular Expression (re). Сравнение выполняется для полных путей к файлам. Приведенный ниже пример обеспечивает игнорирование BitBake всех заданий и дополнений в каталоге meta-ti/recipes-misc/.
BBMASK = "meta-ti/recipes-misc/"
Если нужно скрыть множество каталогов или заданий, можно указать несколько фрагментов регулярных выражений, как показано ниже.
BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/"
BBMASK += "/meta-oe/recipes-support/"
BBMASK += "/meta-foo/.*/openldap"
BBMASK += "opencv.*\.bbappend"
BBMASK += "lzma"
Для исключения каталога следует указывать символ / в конце имени.
Позволяет BitBake выполнить сборку со множеством конфигураций и указывает каждую конфигурацию (multiconfig). С помощью этой переменной можно задать BitBake сборку нескольких целей, каждая из которых имеет свою конфигурацию. Переменная задается в файле conf/local.conf,
например,BBMULTIFONFIG = “configA configB configC”. Каждый конфигурационный файл должен размещаться в каталоге сборки внутри каталога
conf/multiconfig (например, build_directory/conf/multiconfig/configA.conf). Использование переменной в среде с поддержкой сборки нескольких конфигураций описано в разделе Building Images for Multiple Targets Using Multiple Configurations [2].
Применяется BitBake для поиска файлов .bbclass и файлов конфигурации подобно системной переменной PATH.
При использовании BitBake извне каталога сборки нужно обеспечить, чтобы переменная BBPATH указывала сборочный каталог. Установка выполняется так же, как для других переменных среды и переменная должна быть задана до начала работы BitBake.
$ BBPATH = "build_directory" $ export BBPATH $ bitbaketarget
При определении в среде BitBake переменная BBSERVER указывает удаленный сервер BitBake. Переменная экспортируется в среду BitBake как показано ниже.
export BBSERVER=localhost:$port"
По умолчанию BBSERVER присутствует также в BB_HASHBASE_WHITELIST,
поэтому
переменная BBSERVER исключена из расчета контрольной суммы и данных зависимостей.
При наследовании класса binconfig-disabled эта переменная указывает двоичные сценарии настройки, которые следует отключить в пользу запроса информации с помощью pkg-config. Класс binconfig-disabled будет изменять указанные сценарии для возврата ошибки, позволяющего найти и заменить вызовы таких сценариев. При добавлении нескольких сценариев они разделяются пробелами, как показано ниже для задания libpng.
BINCONFIG = "${bindir}/libpng-config ${bindir}/libpng16-config"
При наследовании класса binconfig эта переменная задает шаблон для сценариев конфигурации, которые нужно редактировать. При редактировании изменяются пути, заданные во время компиляции, чтобы они были пригодны для установки в sysroot и могли использоваться процессами сборки других заданий. Переменная использует шаблоны оболочки при сопоставлении имен, похожие на fnmatch и glob. Информацию о работе переменной можно найти в файле meta/classes/binconfig.bbclass дерева исходных кодов, а также в параграфе 6.7. binconfig.bbclass.
Базовое имя и версия задания без дополнительных суффиксов (-native, lib64-
и
т. п.).BP имеет вид ${BPN}-${PV}.
Это вариант переменной PN с удаленными общими префиксами и суффиксами, такими как nativesdk-, -cross, -native, а также lib64- и lib32-. Точный список удаляемых префиксов и суффиксов задается переменными MLPREFIX и SPECIAL_PKGSUFFIX.
Задает идентификатор URL сайта отслеживания ошибок для задания. Система сборки OE не использует эту переменную, она служит лишь указателем для разработчиков в случае необходимости сообщить об ошибке.
Указывает архитектуру хоста сборки (например, i686). Система сборки OE устанавливает переменную по выводу команды uname.
Задает зависящие от архитектуры флаги ассемблера для хоста сборки (по умолчанию “”).
Задает зависящие от архитектуры флаги компилятора C для хоста сборки (по умолчанию “”).
Задает команду компоновки, используемую хостом сборки в случае применения для компоновки компилятора C. По умолчанию BUILD_CCLD указывает GCC и передает в качестве аргумента значение BUILD_CC_ARCH.
Задает флаги, передаваемые компилятору C при сборке для сборочного хоста. При сборке в контексте -native по умолчанию используется значение CFLAGS.
Задает флаги, передаваемые препроцессору C (т. е. компиляторам C и C++). При сборке в контексте -native по умолчанию используется значение CPPFLAGS.
Задает флаги, передаваемые компилятору C++ при сборке для сборочного хоста. При сборке в контексте -native по умолчанию используется значение CXXFLAGS.
Задает флаги, передаваемые компилятору Fortran для хоста сборки. По умолчанию переменная указывает Gfortran и передает значение BUILD_CC_ARCH.
Задает флаги команду компоновщика для хоста сборки. По умолчанию переменная указывает компоновщик GNU (ld) и передает значение BUILD_LD_ARCH.
Задает зависящие от архитектуры флаги компоновщика для хоста сборки (по умолчанию “”).
Задает флаги, передаваемые компоновщику при сборке для сборочного хоста. При сборке в контексте -native по умолчанию используется значение LDFLAGS.
Задает флаги оптимизации, передаваемые компилятору C при сборке для сборочного хоста или SDK через заданные по умолчанию значения переменных BUILD_CFLAGS и BUILDSDK_CFLAGS. По умолчанию переменная BUILD_OPTIMIZATION имеет значение -O2 -pipe.
Указывает операционную систему сборочного хоста (например, linux). Система сборки OE устанавливает переменную по первому слову вывода команды uname, преобразованному в нижний регистр.
Префикс двоичного файла инструментария для естественных заданий. Система сборки OE использует значение переменной TARGET_PREFIX при сборке естественных заданий.
Указывает команду для вырезания отладочных символов из файлов, созданных для сборочного хоста (по умолчанию ${BUILD_PREFIX}strip).
Задает систему (включая архитектуру и ОС), используемую при сборке для сборочного хоста (задания native). Система сборки OE автоматически назначает эту переменную на основе значений BUILD_ARCH, BUILD_VENDOR и BUILD_OS (это значение не требуется менять).
Задает имя производителя для использования при сборке для сборочного хоста (по умолчанию “”).
Указывает местоположение каталога сборки, который можно задать опосредованно через сценарий oe-init-build-env, указав путь в команде запуска сценария. Если сценарий запущен без указания каталога сборки, по умолчанию BUILDDIR будет применять текущий каталог.
При наследовании класса buildhistory управляет фиксацией вывода истории сборки в локальном репозитории Git. При значении 1 этот локальный репозиторий будет поддерживаться автоматически классом buildhistory с фиксацией при каждой сборке изменений в каждом каталоге верхнего уровня вывода истории сборки (images, packages, sdk). Это позволяет отслеживать историю сборки. По умолчанию класс buildhistory не фиксирует вывод истории сборки в локальном репозитории Git, т. е. BUILDHISTORY_COMMIT ?= “0”.
При наследовании класса buildhistory
указываетGit. Чтобы переменная работала, нужно установить
автора для каждой фиксации BUILDHISTORY_COMMIT = “1”. Git требует в переменной BUILDHISTORY_COMMIT_AUTHOR
значение
в формате email@host. Использование недействительного адреса или хоста не ведет к ошибке. По умолчанию класс buildhistory задает BUILDHISTORY_COMMIT_AUTHOR ?= “buildhistory <buildhistory@${DISTRO}>”
При наследовании класса buildhistory эта переменная задает каталог для хранения данных истории сборки. По умолчанию устанавливается BUILDHISTORY_DIR ?= “${TOPDIR}/buildhistory”.
При наследовании класса buildhistory эта переменная задает включенные функции истории сборки (см. Maintaining Build Output Quality [2]). Свойства указываются в форме разделенного пробелами списка элементов:
- image – анализ содержимого образов, включая список установленных пакетов;
- package – анализ содержимого отдельных пакетов;
- sdk – анализ содержимого SDK;
- task – сохранение подписей выходных файлов задач sstate (по одному файлу на задачу с контрольной суммой SHA-256 для каждого подготовленного файла).
По умолчанию класс buildhistory устанавливает BUILDHISTORY_FEATURES ?= “image package sdk”.
При наследовании класса buildhistory переменная задает список путей к файлам, копируемым из образа в каталог истории сборки каталога image-files в каталоге для образа, чтобы можно было отследить содержимое каждого файла. По умолчанию копируются /etc/passwd и /etc/group, что позволяет контролировать изменения пользователей и групп. Можно включить в список любой файл. Задание некорректного пути в переменной не ведет к ошибке, поэтому можно указать даже не всегда присутствующие файлы. По умолчанию класс buildhistory устанавливает BUILDHISTORY_IMAGE_FILES ?= “/etc/passwd /etc/group”.
При наследовании класса buildhistory переменная может задавать удаленный репозиторий, в который история сборки выталкивает (push) изменения Git. Для работы переменной BUILDHISTORY_PUSH_REPO нужно установить BUILDHISTORY_COMMIT = “1”. Репозиторий должен соответствовать заданному удаленному адресу, понятному Git, или удаленному имени, установленному вручную с использованием git в локальном репозитории. По умолчанию класс
remotebuildhistory устанавливает BUILDHISTORY_PUSH_REPO ?= “”.
Указывает флаги для передачи компилятору C при сборке для SDK. При сборке в контексте nativesdk- переменная CFLAGS получает значение этой переменной по умолчанию.
Указывает флаги для передачи препроцессору C (для компиляторов C и C++) при сборке для SDK. При сборке в контексте nativesdk- переменная CPPFLAGS
получает
значение этой переменной по умолчанию.
Указывает флаги для передачи компилятору C++ при сборке для SDK. При сборке в контексте nativesdk- переменная CXXFLAGS получает значение этой переменной по умолчанию.
Указывает флаги для передачи компоновщику при сборке для SDK. При сборке в контексте nativesdk- переменная LDFLAGS получает значение этой переменной по умолчанию.
Указывает местоположение каталога со статистикой сборки при включенном и используемом классе buildstats. По умолчанию BUILDSTATS_BASE имеет значение ${TMPDIR}/buildstats/.
Управляет для задания BusyBox расщеплением выходного файла на 2 части, одна из который выполняет функции, требующие setuid, а другая делает все остальное (где не требуется
rootsetuid).
root
BUSYBOX_SPLIT_SUID по умолчанию имеет значение 1, обеспечивающее на выходе два исполняемых файла. Установка значения 0 отменяет расщепление выходного файла.
C
Задает каталог, используемый BitBake для хранения кэшированных метаданных чтобы не анализировать их при каждом запуске BitBake.
Сокращенная команда и аргументы для запуска компилятора C.
Задает флаги для передачи компилятору C. Переменная экспортируется в окружение и доступна программам, собираемым на этапе компиляции. Принятая по умолчанию инициализация CFLAGS зависит от собираемого объекта:
TARGET_CFLAGSпри сборке для целевой платформы;BUILD_CFLAGSпри сборке для сборочного хоста (-native);BUILDSDK_CFLAGSпри сборке для SDK (nativesdk-).
Внутренняя переменная, задающая переопределение класса, который следует применять (например, class-target, class-native и т. п.). Классы, использующие эту переменную (например, native, nativesdk и т. п.), устанавливают подходящее значение. Переменная CLASSOVERRIDE получает используемое по умолчанию значение class-target из файла bitbake.conf.
Приведенное ниже переопределение позволяет установить дополнительные файлы, но только при сборке для целевой платформы.
do_install_append_class-target() {
install my-extra-file ${D}${sysconfdir}
}
Ниже приведен пример, где переменная FOO получает значение native при сборке для сборочного хоста и other – остальных случаях
FOO_class-native = "native"
FOO = "other"
Базовым механизмом использования CLASSOVERRIDE является просто включение в принятое по умолчанию значение OVERRIDES.
При установке в задании значения 1 для этой переменной команда make clean не будет работать для собираемой программы, поэтому система сборки OE не будет пытаться запустить ее при выполнении задачи do_configure.
Указывает список аппаратных свойств, включенных в MACHINE_FEATURES и DISTRO_FEATURES. Это определяет список свойств, которыми имеет смысл управлять на уровне конфигурации машины и дистрибутива. Например, свойство bluetooth требует аппаратной поддержки, но является также опцией дистрибутива.
Указывает каталог meta/files/common-licenses в дереве исходных кодов, где хранятся файлы базовых лицензий.
Регулярное выражение, указывающее один или несколько хостов (естественное задание) или целей (неестественное задание), с которыми задание совместимо. Выражение сопоставляется с HOST_SYS. Переменную можно использовать для предотвращения сборки заданий для несовместимых классов систем. Особенно полезно это при сборке ядер. Переменная также помогает ускорить синтаксический анализ, поскольку система сборки будет пропускать несовместимые задания.
Регулярное выражение, указывающее одну или несколько целевых машин, совместимых с заданием. Выражение сравнивается с MACHINEOVERRIDES. Можно использовать эту переменню для предотвращения сборки кода для машин, которые не совместимы с заданием. Особенно полезно это при сборке ядер. Переменная также помогает повысить скорость анализа, поскольку система сборки будет пропускать несовместимые с машиной задания.
Задает шаблоны сопоставления при установке списка дополнительных пакетов для всех пакетов, явно или неявно включенных в образ. Переменная использует шаблоны соответствия имен Unix (fnmatch), похожие на шаблоны преобразования путей Unix (glob).
Результирующий список пакетов связан с элементом, который может быть добавлен в IMAGE_FEATURES.Примером может служить элемент dev-pkgs при добавлении которого в IMAGE_FEATURES будут устанавливаться пакеты -dev (заголовки и другие файлы для разработки) для каждого пакета в образе.
Для добавления указанного шаблоном свойства служит флаг переменной и значение шаблона, например, COMPLEMENTARY_GLOB[dev-pkgs] = ‘*-dev’.
Сохраняет компоненты sysroot для каждого задания. Система сборки OE использует переменную при создании зависимых от задания каталогов sysroot для других заданий. По умолчанию установлено “${STAGING_DIR}-components” (т. е. “${TMPDIR}/sysroots-components“).
Отслеживает версию файла local.conf. Значение увеличивается при каждом изменении совместимости build/conf/.
Указывает редактируемые или настраиваемые файлы в пакете. Если система PMS2 применяется для управления пакетами на целевой платформе, возможна замена конфигурационных файлов после установки пакета, что может быть нежелательно. Иными словами, в пакете могут быть редактируемые файлы, которые не следует менять при обновлении пакета. Переменная CONFFILES позволяет указать эти файлы и PMS не будет обновлять их.
Для использования переменной CONFFILES имя пакета переопределяется в указанием результирующего пакета. Затем указывается список разделенных пробелами файлов, например, CONFFILES_${PN} += “${sysconfdir}/file1 ${sysconfdir}/file2 ${sysconfdir}/file3”
Переменные CONFFILES и FILES связаны между собой и файлы из CONFFILES должны быть подмножеством файлов из FILES,
поскольку.
они являются частью пакета
При указании путей в переменной CONFFILES хорошим тоном является использование подходящих переменных. Например, следует указывать ${sysconfdir} вместо /etc
или
${bindir} вместо /usr/bin. Список этих переменных приведен в начале файла meta/conf/bitbake.conf в дереве исходных кодов.
Задает файлы для initramfs. Система сборки OE получает и использует эту переменную ядра Kconfig, как переменную окружения, которая по умолчанию имеет пустое значение (“”).
CONFIG_INITRAMFS_SOURCE может указывать один архив cpio (.cpio) initramfs. Файл cpio должен включать архив файловой системы для использования в качестве образа initramfs. Каталоги должны включать схему файловой системы для включения в образ initramfs, а файлы – записи в соответствии с форматом, описанным программой
или список разделенных пробелами
каталогов и файлов для сборки образаusr/gen_init_cpio в дереве ядра.
Если задано множество каталогов и файлов, образ initramfs будет включать из. Информация о создании initramfs приведена в разделе Building an Initial RAM Filesystem (initramfs) Image [2].
Список файлов, содержащих результаты теста autoconf,
относящиесяAutotools при настройке конфигурации (
к текущей сборке. Переменная используется
утилитами configure).
Минимальные аргументы для GNU configure.
При наследовании класса distro_features_check эта переменная указывает свойства дистрибутива, которые будут вызывать конфликты при сборке образа. Иными словами, при включении свойства в CONFLICT_DISTRO_FEATURES и DISTRO_FEATURES в одной конфигурации будет возникать ошибка.
Список разделенных пробелами лицензий для исключения источников, архивируемых классом archiver.
Если
лицензия из переменной LICENSE включена в COPYLEFT_LICENSE_EXCLUDE,
ее
источник не будет архивироваться.
Переменная
имеет более высокий приоритет по
сравнению с COPYLEFT_LICENSE_INCLUDE.
Принятое по умолчанию значение “CLOSED Proprietary” устанавливается классом copyleft_filter, который наследуется классом archiver.
Список разделенных пробелами лицензий для включения источников, архивируемых классом archiver. Если лицензия из переменной LICENSE включена в COPYLEFT_LICENSE_INCLUDE, ее источник будет архивироваться. Принятое по умолчанию значение задается классом copyleft_filter, наследуемым классом archiver,
и содержит GPL*, LGPL* и AGPL*.
Список заданий для исключения источников, архивируемых классом archiver. Переменная переопределяет включение и исключение лицензий через COPYLEFT_LICENSE_INCLUDE и COPYLEFT_LICENSE_EXCLUDE. Принятое по умолчанию значение “” указывает отсутствие явного исключения заданий и устанавливается классом copyleft_filter, который наследуется классом archiver.
Список заданий для включения источников, архивируемых классом archiver. Переменная переопределяет включение и исключение лицензий через COPYLEFT_LICENSE_INCLUDE и COPYLEFT_LICENSE_EXCLUDE. Принятое по умолчанию значение “” указывает отсутствие явного включения заданий и устанавливается классом copyleft_filter, который наследуется классом archiver.
Список разделенных пробелами типов заданий для включения в архив исходных кодов, создаваемый классом archiver. Задания могут иметь тип target, native, nativesdk, cross, crosssdk
и
cross-canadian. По умолчанию применяется тип target* и для COPYLEFT_RECIPE_TYPES оно устанавливается классом copyleft_filter,
который
наследуется классомarchiver.
При установке значения 1 для этой переменной и COPY_LIC_MANIFEST система сборки OE копирует в образ файлы лицензий из каталога /usr/share/common-licenses
для. Файлы лицензий помещаются в образ при его сборке.
каждого пакета
COPY_LIC_DIRS не предлагает путь добавления лицензий для вновь устанавливаемых пакетов в образах с файловой системой read-only, которая не разрешает запись (см. описание LICENSE_CREATE_PACKAGE).Providing License Text [2].
Дополнительная информация о предоставлении
текстов лицензий приведена в разделе
При установке значения 1 система сборки OE копирует манифест лицензии в файл образа /usr/share/common-licenses/license.manifest в процессе сборки.
COPY_LIC_MANIFEST не предлагает для вновь устанавливаемых в образ пакетов путь добавления лицензий, который может лучше подходить для файловых систем без возможности записи read-only), не позволяющих вносить изменения (см. описание переменной LICENSE_CREATE_PACKAGE). Providing License Text [2].
Сведения о предоставлении текстов
лицензий приведены также в разделе
Задает список пакетов для добавления в образ. Переменную следует включать лишь в файл local.conf каталога сборки. Эта переменная заменила ранее применявшуюся переменную POKY_EXTRA_INSTALL.
Задает родительский каталог уровня метаданных OpenEmbedded-Core (meta).
Список файлов из каталога COREBASE,
которые
следует скопировать, если они не относятся
к уровням, указанным в bblayers.conf. Переменная предназначена для копирования метаданных из системы сборки OE в расширяемый SDK. Явное указание копируемых файлов из COREBASE требуется потому, что этот каталог обычно содержит каталоги сборки и другие файлы, которые не нужны в eSDK.
Сокращенная команда и аргументы для запуска препроцессора C.
Задает флаги для передачи препроцессору C (для компиляторов C и C++). Переменная экспортируется в окружение и доступна программам, собираемым на этапе компиляции. Принятая по умолчанию инициализация CPPFLAGS зависит от собираемого объекта:
TARGET_CPPFLAGSпри сборке для целевой платформы;BUILD_CPPFLAGSпри сборке для сборочного хоста (-native);BUILDSDK_CPPFLAGSпри сборке для SDK (nativesdk-).
Префикс двоичных файлов инструментария для целевой платформы (совпадает со значением TARGET_PREFIX). Система сборки OE устанавливает CROSS_COMPILEлишь в определенном контексте (например, при сборке заданий для ядра или модулей ядра).
Каталог для хранения файлов, выбранных в системе CVS.
Сокращенная команда и аргументы для запуска компилятора C++.
Задает флаги для передачи компилятору C++. Переменная экспортируется в окружение и доступна программам, собираемым на этапе компиляции. Принятая по умолчанию инициализация CXXFLAGS зависит от собираемого объекта:
TARGET_CXXFLAGSпри сборке для целевой платформы;BUILD_CXXFLAGSпри сборке для сборочного хоста (-native);BUILDSDK_CXXFLAGSпри сборке для SDK (nativesdk-).
D
Каталог назначения в каталоге сборки, куда устанавливаются компоненты задачей do_install
(по умолчанию ${WORKDIR}/image). Задачи, читающие каталог или записывающие в него, следует запускать в fakeroot [1].
Дата начала сборки в формате YMD (например, 20150209 для 9 февраля 2015 г.).
Дата и время начала текущей сборки в формате, пригодном для временных меток.
При
наследовании класса debian
(принятоDebian для отдельного пакета. При установке переменной должно применяться имя пакета, например, DEBIAN_NOAUTONAME_fontconfig-utils = “1”.
по умолчанию) переменная задает отмену
переименования библиотек в стиле
При наследовании класса debian (принято по умолчанию) переменная позволяет переопределить имя библиотеки для отдельного пакета. Такое переопределение происходит редко и при установке переменной должно применяться имя пакета, например, DEBIANNAME_${PN} = “dbus-1”.
Задает сборку пакетов с отладочной информацией. Это влияет на значение SELECTED_OPTIMIZATION.
Опции для передачи в TARGET_CFLAGS и CFLAGS при компиляции системы с отладкой. По умолчанию переменная имеет значение -O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe.
Задает незначительное смещение при выборе приоритета для задания. Чаще всего для переменной устанавливают значение -1 в заданиях для development-версий программ. Это ведет к сборке по умолчанию стабильной версии задания при отсутствии PREFERRED_VERSION. Смещение от DEFAULT_PREFERENCE невелико и часто переопределяется BBFILE_PRIORITY,
если.
эта переменная различается в двух
уровнях, содержащих разные версии одного
задания
Используемые по умолчанию настройки CPU и ABI для системы сборки OE. Переменная DEFAULTTUNE помогает определить TUNE_FEATURES. Принятые по умолчанию настройки явно или неявно задаются машиной (MACHINE), однако их можно переопределить с помощью значений переменной AVAILTUNES.
Список зависимостей при сборке задания. Это зависимости от других заданий (например, заголовков и общих библиотек). Например, задание foo может включать зависимость DEPENDS = “bar”. Это означает, что все файлы, установленные заданием bar, будут доступны в подходящей промежуточной системе sysroot, указанной переменными STAGING_DIR*, при выполнении задачи do_configure для foo. Этот механизм реализуется за счет зависимости do_configure от do_populate_sysroot для каждого задания, указанного в DEPENDS, через объявление [deptask] в классе base.
Иногда нужно явно указать, например, STAGING_DIR_HOST. Стандартные классы и связанные со сборкой переменные настраиваются для автоматического использования подходящей промежуточной системы sysroot.
Другим примером может служить применение DEPENDS для добавления утилит, работающих на сборочном хосте в процессе сборки. Например, задание codegen может включать DEPENDS = “codegen-native”.
Дополнительная информация приведена в описании класса native class и переменной EXTRANATIVEPATH.
- DEPENDS содержит список имен заданий, точнее – список имен PROVIDES, обычно совпадающих с именами заданий. Включение в DEPENDS имен пакетов, таких как foo-dev, не имеет смысла. Вместо этого следует указать foo, поскольку это приведет к включению всех пакетов, составляющих foo, включая foo-dev.
- Задание, указывающее в DEPENDS другое задание, само по себе не добавляет зависимость между этими заданиями при работе. Однако, как указано в разделе Automatically Added Runtime Dependencies [1], зависимости при работе часто добавляются автоматически, поэтому для большинства заданий достаточно указать DEPENDS.
- DEPENDS зачастую требуется даже для заданий, устанавливающих ранее собранные компоненты. Например, если libfoo является ранее скомпилированной библиотекой, которая связана с libbar, тогда привязка к libfoo
требует наличия libfoo и libbar в sysroot. Без зависимости от libbar в переменной DEPENDS задания, устанавливающего libfoo, другие задания не смогут ссылаться на libfoo.
Информация о зависимостях при работе приведена в описании переменной RDEPENDS, а также в разделах Tasks и Dependencies [4].
Указывает базовую область, куда система сборки OE помещает образы, пакеты, SDK и другие выходные файлы, предназначенные для внешнего использования. По умолчанию этот каталог размещается в каталоге сборки как ${TMPDIR}/deploy. Структура каталога сборки описана в разделе 5.2. Каталог сборки build/, а содержимое каталога развертывания рассмотрено в разделах Images, Package Feeds, и Application Development SDK [1].
Указывает область, используемую системой сборки OE для размещения пакетов Debian, готовых для развертывания вне системы сборки. Переменная применяется лишь при наличии в PACKAGE_CLASSES значения package_deb. Конфигурационный файл BitBake изначально определяет DEPLOY_DIR_DEB как каталог DEPLOY_DIR_DEB = “${DEPLOY_DIR}/deb”
Класс package_deb использует DEPLOY_DIR_DEB для обеспечения записи задачей do_package_write_deb пакетов Debian в корректный каталог (см. раздел Package Feeds [1]).
Указывает область, используемую системой сборки OE для размещения и связанных с ними файлов, готовых для развертывания вне системы сборки. Переменная является машинозависимой, поскольку содержит ${MACHINE}. По умолчанию этот каталог размещается в каталоге сборки как ${DEPLOY_DIR}/images/${MACHINE}/.
Информация о структуре каталога сборки приведена в разделе 5.2. Каталог сборки build/, а содержимое каталога развертывания описано в разделах Images и Application Development SDK [1].
Указывает область, используемую системой сборки OE для размещения пакетов IPK, готовых для развертывания вне системы сборки. Переменная применяется лишь при наличии в PACKAGE_CLASSES значения package_ipk. Конфигурационный файл BitBake изначально определяет эту переменную как DEPLOY_DIR_IPK = “${DEPLOY_DIR}/ipk”
Класс package_ipk использует DEPLOY_DIR_IPK для обеспечения записи задачей do_package_write_ipk пакетов IPK в корректный каталог (см. раздел Package Feeds [1]).
Указывает область, используемую системой сборки OE для размещения пакетов RPM, готовых для развертывания вне системы сборки. Переменная применяется лишь при наличии в PACKAGE_CLASSES значения package_rpm. Конфигурационный файл BitBake изначально определяет эту переменную как DEPLOY_DIR_RPM = “${DEPLOY_DIR}/rpm”
Класс package_rpm использует DEPLOY_DIR_RPM для обеспечения записи задачей do_package_write_rpm t пакетов RPM в корректный каталог (см. раздел Package Feeds [1]).
Указывает область, которую система сборки OE использует для размещения архивов, готовых для внешнего использования. Переменная применяется при наличии в переменной PACKAGE_CLASSES строки package_tar. Конфигурационный файл BitBake изначально определяет эту переменную как подкаталог в DEPLOY_DIRDEPLOY_DIR_TAR = “${DEPLOY_DIR}/tar”. Класс
- package_tar использует переменную DEPLOY_DIR_TAR для гарантии того, что задача do_package_write_tar
будет TAR в подходящий каталог. Дополнительная информация о процессе упаковки приведена в разделе Package Feeds [1].
записывать пакеты
При наследовании класса deploy эта переменная указывает временную рабочую область для разворачиваемых файлов, установленную в классе deploy как DEPLOYDIR = “${WORKDIR}/deploy-${PN}”. Заданиям, наследующим класс deploy,
следует
копировать разворачиваемые файлы в
DEPLOYDIR, а класс затем скопирует их в DEPLOY_DIR_IMAGE.
Описание пакета, используемое менеджерами пакетов. Если значение DESCRIPTION не задано, автоматически принимается значение переменной SUMMARY.
Короткое имя для дистрибутива. Длинные имена задаются переменной DISTRO_NAME.
Переменная DISTRO соответствует файлу конфигурации (.conf) дистрибутива, корневое имя которого совпадает со значением переменной. Например, файл конфигурации дистрибутива Poky называется poky.conf и размещается в каталоге meta-poky/conf/distro дерева исходных кодов. В этом файле переменная задана как DISTRO = “poky”.
Конфигурационные файлы дистрибутивов размещаются в каталоге conf/distro метаданных с конфигурацией дистрибутива. Значение DISTRO должно быть без пробелов и обычно указывается строчными буквами. Если переменная DISTRO пуста, используется заданное по умолчанию значение, которое указано в файле meta/conf/distro/defaultsetup.conf дерева исходных кодов.
Задает кодовое имя для собираемого дистрибутива.
Задает список определяемых дистрибутивом приложений, которые включаются во все образы. Эта переменная работает через packagegroup-base, поэтому на деле применяется только к наиболее функциональным образам, включающим группу packagegroup-base. Переменная указывается в файле конфигурации дистрибутива .conf.
DISTRO_EXTRA_RRECOMMENDS
Задает список специфических для дистрибутива приложений, добавляемых по все образы при наличии пакетов (пакеты могут отсутствовать или быть пустыми, например, модули ядра). Пакеты из списка устанавливаются автоматически, но их можно удалить.
Поддержка программ, которую нужно включить в дистрибутив, задаваемая в конфигурационном файле. В большинстве случаев наличие или отсутствие свойства в DISTRO_FEATURES передается в соответствующую опцию сценария настройки при выполнении задачи do_configure для заданий, которые могут поддерживать это свойство. Например, указание x11 в DISTRO_FEATURES приведет к возможности включения поддержки X11 для каждой собираемой программы. Другими примерами служат поддержка Bluetooth и NFS. Более полный список включенных в YP свойств (возможностей) представлен в параграфе 12.2. Свойства дистрибутива.
Свойства для добавления в DISTRO_FEATURES при отсутствии в DISTRO_FEATURES_BACKFILL_CONSIDERED. Переменная указывается в файле meta/conf/bitbake.conf и не предназначена для настройки пользователем. Лучше просто указать переменную для свойств, включаемых во все конфигурации дистрибутива (параграф 12.4. Отключение автоматически добавляемых свойств).
DISTRO_FEATURES_BACKFILL_CONSIDERED
Свойства из переменной DISTRO_FEATURES_BACKFILL, которые не следует включать (добавлять в DISTRO_FEATURES) при сборке (параграф 12.4. Отключение автоматически добавляемых свойств).
Вспомогательная переменная со списком принятых по умолчанию свойств дистрибутива за исключением свойств, относящихся к библиотеке C (libc).
При создании пользовательского дистрибутива может оказаться полезной возможность многократного использования заданных по умолчанию опций DISTRO_FEATURES без необходимости переписывать весь набор. Это можно сделать, указав в конфигурационном файле дистрибутива DISTRO_FEATURES ?= “${DISTRO_FEATURES_DEFAULT} myfeature”.
Задает список свойств, которые при их наличии в DISTRO_FEATURES следует включать в сборку заданий native. Эти свойства дополняют список свойств, отфильтрованных переменой DISTRO_FEATURES_NATIVE.
DISTRO_FEATURES_FILTER_NATIVESDK
Задает список свойств, которые при их наличии в DISTRO_FEATURES следует включать в сборку заданий nativesdk. Эти свойства дополняют список свойств, отфильтрованных переменой DISTRO_FEATURES_NATIVESDK.
Задает список свойств, которые следует включать в DISTRO_FEATURES при сборке естественных заданий. Эти свойства дополняют список свойств, отфильтрованных переменой DISTRO_FEATURES_FILTER_NATIVE.
Задает список свойств, которые следует включать в DISTRO_FEATURES при сборке заданий nativesdk. Эти свойства дополняют список свойств, отфильтрованных переменой DISTRO_FEATURES_FILTER_NATIVESDK.
Длинное имя дистрибутива (короткое задает переменная DISTRO).
Переменная DISTRO_NAME соответствует файлу конфигурации (.conf) дистрибутива, корневое имя которого совпадает со значением переменной. Например, файл конфигурации дистрибутива Poky называется poky.conf и размещается в каталоге meta-poky/conf/distro дерева исходных кодов. В этом файле poky.conf переменная DISTRO_NAME задана как DISTRO_NAME = “Poky (Yocto Project Reference Distro)”.
Конфигурационные файлы дистрибутивов размещаются в каталоге conf/distro метаданных с конфигурацией дистрибутива. Если переменная DISTRO_NAME пуста, используется заданное по умолчанию значение, которое указано в файле meta/conf/distro/defaultsetup.conf дерева исходных кодов.
Версия дистрибутива.
Список разделенных двоеточиями переопределений для текущего дистрибутива. По умолчанию список включает значение DISTRO. Можно расширить DISTROOVERRIDES для добавления переопределений, применяемых к дистрибутиву. Базовым механизмом для DISTROOVERRIDES является включение в принятое по умолчанию значение OVERRIDES.
Основной каталог загрузок, используемый процессом сборки для хранения загруженных файлов. По умолчанию DL_DIR принимает файлы, подходящие для «зеркалирования» всего, кроме репозиториев Git. Если нужны архивы репозиториев Git, следует использовать переменную BB_GENERATE_MIRROR_TARBALLS.
Каталог загрузки DL_DIR указывается в файле conf/local.conf. Каталог поддерживает себя и не нужно его трогать. По умолчанию загрузки выполняются в каталог сборки. Если нужно использовать другой каталог, следует убрать символ комментария в строке #DL_DIR ?= “${TOPDIR}/downloads”.
При первой сборке система загружает множество архивов исходного кода из разных проектов, что может продолжаться достаточно долго. Архивы сохраняются в каталоге, указанном DL_DIR и система сборки ищет там архивы исходных кодов. При очистке или повторной сборке можно сохранить каталог загрузки для ускорения процесса.
Этот каталог можно использовать для разных сборок, выполняемых на хосте разработки. Дополнительная информация о загрузке архивов исходного кода при работе через прокси или межсетевой экран приведена в параграфе 15.12. Работа через межсетевой экран, а также на странице Working Behind a Network Proxy.
При наследовании класса compress_doc эта переменная задает правила сжатия, используемые системой сборки OE для страниц man и info. По умолчанию применяется компрессия gz (gzip), но можно выбрать xz или bz2. Информация об использовании этой переменной и правилах приведена в комментариях в файле meta/classes/compress_doc.bbclass.
E
При сборке загружаемых образов (типы hddimg, iso, wic.vmdk в IMAGE_FSTYPES), переменная указывает применяемый загрузчик EFI. По умолчанию используется grub-efi, но можно задать systemd-boot (см. параграфы 6.130. systemd-boot.bbclass и 6.53. image-live.bbclass).
ENABLE_BINARY_LOCALE_GENERATION
Переменная, задающая варианты locale для glibc, которые создаются при сборке (полезно для платформ с ОЗУ, не превышающим 64 Мбайт).
При использовании с классом report-error задает путь, используемый для хранения отладочных файлов, созданных инструментом отчетов об ошибках, для централизованного хранения сведений об ошибках сборки. По умолчанию переменная имеет значение ${LOG_DIR}/error-report, которое можно изменить в файле local.conf с помощью строки ERR_REPORT_DIR = “path“.
Задает проверки качества, об отказах которых системой сборки OE будут выдаваться сообщения об ошибках. Переменная задается в конфигурации дистрибутива, список проверок приведен в параграфе 6.56. insane.bbclass.
Запускает распознаватель общих библиотек в системе сборки OE для исключения пакета целиком при сканировании общих библиотек. Функциональность распознавателя общих библиотек частично определяется внутренней функцией package_do_shlibs, которая является частью задачи do_package task. Следует знать, что распознаватель общих библиотек может неявно определять некоторые зависимости между пакетами.
Переменная EXCLUDE_FROM_SHLIBS похожа на PRIVATE_LIBS, которая исключает отдельные библиотеки, а не весь пакет. Переменная устанавливается для конкретного пакета в форме EXCLUDE_FROM_SHLIBS = “1”.
Указывает BitBake исключить задание из сборки world (т. е. bitbake). При сборках world программа BitBake находит, анализирует и собирает все задания, найденные в каждом уровне, указанном в файле
worldbblayers.conf. Для исключения задания следует установить в этой переменной значение 1 в задании.
Добавленные в EXCLUDE_FROM_WORLD могут все-таки включаться в сборку world для выполнения зависимостей других заданий. Включение в EXCLUDE_FROM_WORLD лишь блокирует явное включение задания в сборку.
применяется с файлами и именами путей для создания префикса версии задания на основе значения PE. Если для задания установлено значение PE больше 0, переменная EXTENDPE принимает это значение (т. е. при PE = “1” EXTENDPE становится “1_”). Если переменная PE в задании не установлена (принято по умолчанию) или равна 0, EXTENDPE получает значение “”. Дополнительные сведения приведены в описании переменной STAMP.
Полная спецификация версии пакета, как она указана в финальных пакетах, создаваемых заданием. Значение переменной обычно служит для исправления зависимостей при работе от конкретной версии другого пакета в том же задании.
RDEPENDS_${PN}-additional-module = "${PN} (= ${EXTENDPKGV})"
Отношения зависимости нужны для того, чтобы менеджер пакетов обновлял эти пакеты в режиме блокировки.
Установленная переменная показывает инструменты, не включенные в дерево исходных кодов. Инструменты, доступные в дереве, обычно являются предпочтительными, но установка этой переменной позволяет системе сборки OE отдать предпочтение внешним инструментам. Использование переменной рассмотрено в параграфе 6.66. kernel-yocto.bbclass.
При наследовании класса externalsrc эта переменная указывает каталог исходных кодов за пределами системы сборки OE. При установке этой переменной она задает значение переменной S, используемой системой OE для указания распакованного исходного кода. Информация о классе externalsrc
приведена
в параграфе 6.34. externalsrc.bbclass, аBuilding Software from an External Source [2].
использование переменной описано в
разделе
При наследовании класса externalsrc эта переменная указывает каталог, в котором собирается исходный код задания, находящийся вне системы сборки OE. При установке этой переменной она задает значение переменной B,
используемойOE для указания сборочного каталога. Информация о классе
системой externalsrc
приведена
в параграфе 6.34. externalsrc.bbclass, аBuilding Software from an External Source [2].
использование переменной описано в
разделе
Для заданий, наследующих класс autotools, эта переменная позволяет задать дополнительные опции команды autoreconf,
выполняемой
задачей do_configure
(по–exclude=autopoint).
умолчанию
Список разделенных пробелами дополнительных возможностей для включения в образ. Обычно эта переменная указывается в файле local.conf сборочного каталога. Возможно ее указание и в других файлах, но делать этого не следует. Для включения базовых возможностей образа служит переменная IMAGE_FEATURES.
Ниже приведены примеры некоторых дополнительных возможностей.
dbg-pkgs
Добавляет пакеты -dbg для отлаживания и профилирования.
debug-tweaks
Делает образ пригодны для отладки, например, позволяя вход в систему пользователя root без пароля и включая запись в системный журнал событий после установки. Дополнительная информация представлена в описаниях свойств allow-empty-password и post-install-logging в параграфе 12.3. Свойства образа.
dev-pkgs
Добавляет в образ пакеты разработки -dev.
read-only-rootfs
Создает образ, корневая система которого доступна только для чтения (см. раздел Creating a Read-Only Root Filesystem [2]).
tools-debug
Добавляет средства отладки, такие как gdb и strace.
tools-sdk
Добавляет служебные пакеты, такие как gcc, make, pkgconfig и т. п.
tools-testapps
Добавляет средства тестирования, такие как ts_print, aplay, arecord и т. п.
Полный список возможностей, включенных в выпуск YP, представлен в параграфе 12.3. Свойства образа.
Пример настройки свойств образа с помощью этой переменной приведен в разделе Customizing Images Using Custom IMAGE_FEATURES and EXTRA_IMAGE_FEATURES [2].
Задает опции команды создания образа, указанной в IMAGE_CMD. При установке этой переменной используется переопределение соответствующего типа образа, например, EXTRA_IMAGECMD_ext3 ?= “-i 4096”.
Список заданий для сборки, которые не предоставляют пакетов, устанавливаемых в корневую файловую систему.
Иногда для сборки финального образа нужны задания, которые не требуются в корневой файловой системе. Переменная EXTRA_IMAGEDEPENDS позволяет указать эти задания для выполнения зависимостей. Типичные примером является требование иметь загрузчик в конфигурации машины.
Добавление пакетов в корневую систему управляется переменными *RDEPENDS и *RRECOMMENDS.
Список каталогов в ${STAGING_BINDIR_NATIVE},
добавляемых
в начало переменной окружения PATH. Например, для добавления в путь поиска каталогов “${STAGING_BINDIR_NATIVE}/foo:${STAGING_BINDIR_NATIVE}/bar:” можно указать EXTRANATIVEPATH = “foo bar”.
Опции CMake (см. параграф 6.17. cmake.bbclass).
Опции сценария configure.
Передача
опций зависит от переменнойPACKAGECONFIG_CONFARGS.
Опции GNU make. Поскольку переменная EXTRA_OEMAKE по умолчанию пуста, ее требуется установить в соответствии с нужными опциями GNU. Переменные PARALLEL_MAKE и PARALLEL_MAKEINST также используют EXTRA_OEMAKE для передачи требуемых флагов.
При наследовании класса scons эта переменная задает дополнительные параметры конфигурации, которые нужно передать команде scons.
При наследовании класса extrausers эта переменная представляет пользовательские и групповые операции на уровне образа. Это более глобальный метод предоставления конфигурации пользователей и групп по сравнению с использованием класса useradd, который связывает конфигурации пользователей и групп с конкретным заданиям.
Набор команд, которые можно представить с помощью EXTRA_USERS_PARAMS,
приведен
в описании класса extrausers. Эти команды отображаются на одноименные команды Unix, как показано ниже.
# EXTRA_USERS_PARAMS = "\
# useradd -p '' tester; \
# groupadd developers; \
# userdel nobody; \
# groupdel -g video; \
# groupmod -g 1020 developers; \
# usermod -s /bin/sh tester; \
# "
F
Определяет пакеты для включения в образ, когда соответствующее свойство включено в переменную IMAGE_FEATURES. При установке значения переменной FEATURE_PACKAGES следует указывать суффикс в виде имени свойства, например,
FEATURE_PACKAGES_widget = "package1package2"
В этом примере при наличии свойства widget в IMAGE_FEATURES
в
образ будут добавлены пакетыpackage1 и package2. Пакеты, устанавливаемые свойствами через переменную FEATURE_PACKAGES,
зачастую. Несмотря на схожесть имен, не следует путать переменную
являются группамиFEATURE_PACKAGES с группами пакетов, встречающимися в документации.
Указывает базовый идентификатор (URL) сервера и местоположение на нем метаданных и пакетов, требуемых OPKG для поддержки управления пакетами IPK в процессе работы. Переменная задается в файле local.conf,
например,FEED_DEPLOYDIR_BASE_URI = “http://192.168.7.1/BOARD-dir”. Здесь предполагается, что пакеты обслуживаются по протоколу HTTP, а базы данных хранятся на сервере в каталоге
BOARD-dir. В этом случае система сборки OE будет создавать набор конфигурационных файлов для целевой платформы, которые подойдут для указанного хранилища.
Список файлов и каталогов, помещенных в пакет. Пакеты, созданные заданием перечисляются в переменной PACKAGES. Для использования переменной FILES имя пакета переопределяется с указанием результирующего пакета. Затем указывается список разделенных пробелами файлов или путей, указывающих файлы, включенные в результирующий пакет.
FILES_${PN} += "${bindir}/mydir1 ${bindir}/mydir2/myfile"
- При указании файлов и путей можно применять синтаксис Python
glob. - При указании путей в переменной
FILESхорошим тоном является использование подходящих переменных. Например, следует указывать${sysconfdir}вместо/etc
или
${bindir}вместо/usr/bin. Список этих переменных приведен в начале файлаmeta/conf/bitbake.confв дереве исходных кодов, где также представлены принятые по умолчанию значения различных переменныхFILES_*.
Если некоторые из файлов в FILES являются редактируемыми и их не следует переписывать в процессе обновления пакета системой PMS, можно указать эти файлы, чтобы PMS не переписывала их (см. описание переменной CONFFILES).
Задает спецификацию файлов для сопоставления с SOLIBSDEV. Иными словами, FILES_SOLIBSDEV определяет полный путь к символьным ссылкам на общие библиотеки для целевой платформы. Переменная задается в файле bitbake.conf как FILES_SOLIBSDEV ?= “${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}”.
Расширяет путь поиска OE для файлов и исправлений при обработке файлов заданий и добавлений. Используются принятые по умолчанию каталоги, используемые BitBake, определяются переменной FILESPATH,. Лучше делать это с помощью переменной
которая может быть расширена с помощью
FILESEXTRAPATHSFILESEXTRAPATHS из файла .bbappend file и помещать пути в начало, как показано ниже.
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
В этом примере система сборки смотрит сначала в каталоге, имя которого совпадает с именем соответствующего файла добавления.
При использовании FILESEXTRAPATHS(
обязательно указывайте оператор
незамедлительного расширения :=). Это гарантирует, что BitBake будет вычислять THISDIR в момент обнаружения директивы, а не позднее, когда расширение может привести в каталог, где нет нужных файлов.
Включайте двоеточие в конце строки при ее добавлении пути в начало. Это нужно для того, чтобы указать BitBake расширение пути путем вставки каталогов в начало пути поиска.
Ниже приведен еще один вариант использования.
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
В этом примере система сборки расширяет переменную FILESPATH для включения файлов из того же каталога, что и соответствующий файл добавления. Выражение FILESEXTRAPATHS_prepend := “path_1:path_2:path_3:” добавляет 3 пути.
В другом примере показано, как можно расширить путь поиска и включить зависящее от MACHINE
переопределение, полезное
на уровне
Этот оператор присутствует в файле linux-yocto-dev.bbappend, который имеется в YP Source Repositories (раздел meta-intel/common/recipes-kernel/linux). Здесь в зависимости от машины изменяется специальное определение PACKAGE_ARCH для множества машин meta-intel.
Для уровней, поддерживающих один пакет BSP, переопределение может задаваться значением MACHINE.
Добавление пути в начало через файлы .bbappend позволяет расширять путь с помощью множества файлов дополнения, находящихся на разных уровнях но относящихся к одному заданию.
Подмножество OVERRIDES,
используемоеOE для создания
системой сборки FILESPATH. Переменная использует переопределение для автоматического расширения FILESPATH
(пример работы приведен в описании FILESPATH,
аConditional Syntax (Overrides) [4]). По умолчанию переменная задается в форме FILESOVERRIDES = “${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}”. Переменную не следует редактировать вручную. Значения совпадают с ожидаемыми переопределениями и используются системой сборки ожидаемым способом.
более подробная информация о
переопределениях - в разделе
Принятый по умолчанию набор каталогов, в котором система сборки OE ищет исправления и файлы. В процессе сборки BitBake просматривает каждый каталог из FILESPATH в указанном порядке для поиска файлов и исправления, заданных каждым URI file:// в операторах SRC_URI задания. Используемое по умолчанию значение переменной FILESPATH определено в файле base.bbclass каталога meta/classes в дереве исходных кодов.
FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \
"${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
Переменная FILESPATH расширяется автоматически с использованием переопределений из переменной FILESOVERRIDES.
- Не следует редактировать переменную
FILESPATHвручную. Если нужно задать поиск файлов в каталогах, отличающихся от принятых по умолчанию, расширьтеFILESPATHс помощьюFILESEXTRAPATHS. - Принятые по умолчанию каталоги
FILESPATHне отображаются на каталоги пользовательских уровней, где используются файлы добавления (.bbappend). Если нужно искать файлы или исправления, указанные в файлах добавления, следует расширить переменнуюFILESPATHс помощьюFILESEXTRAPATHS.
Такое поведение системы поиска может быть полезно во многих случаях. В качестве примера может служить приведенная ниже структура каталогов с общей и машино-зависимой конфигурацией.
files/defconfig
files/MACHINEA/defconfig
files/MACHINEB/defconfig
В этом примере оператор SRC_URI содержит file://defconfig. С учетом сказанного можно установить MACHINE = MACHINEA и заставить систему сборки использовать файлы из каталога files/MACHINEA, а установка MACHINE = MACHINEB приведет к использованию файлов из files/MACHINEB. Для остальных машин система сборки будет использовать файлы из files/defconfig.
Дополнительная информации о внесении изменений в исходные коды приведена в разделах Patching [1] и Patching Code [2], а также в параграфе 7.1.19. do_patch.
Позволяет задать свою таблицу настроек прав доступа к файлу как часть конфигурации процесса подготовки пакетов. Например, при потребности в согласованном наборе прав доступа для групп и пользователей в рамках проекта лучше устанавливать эти права в пакетах, но это возможно не всегда. По умолчанию система сборки OE использует файл fs-perms.txt из каталога meta/files в дереве кодов. При создании своей таблицы разрешений следует поместить ее на свой уровень или уровень дистрибутива.
Переменная определяется в файле conf/local.conf каталога сборки и указывает пользовательский файл fs-perms.txt. Можно задать несколько таблиц доступа. Пути к файлам должны быть определены в переменной BBPATH. Рекомендации по созданию таблицы прав даны в файле fs-perms.txt.
При наследовании класса fontcache задает зависимости при работе от шрифтовых пакетов. По умолчанию FONT_EXTRA_RDEPENDS имеет значение “fontconfig-utils”.
При наследовании класса fontcache указывает пакеты, содержащие файлы шрифтов, которые нужно кэшировать в Fontconfig. По умолчанию класс fontcache предполагает шрифты в основном задании пакета (${PN}). Эта переменная нужна для случаев, когда шрифты размещаются не в основном пакете.
Значение 1 форсирует удаление пакетов, указанных в ROOTFS_RO_UNNEEDED,
при создании корневой файловой системы.
Опции, передаваемые в TARGET_CFLAGS и CFLAGS при компиляции оптимизированной системы (по умолчанию -O2 -pipe ${DEBUG_FLAGS}).
G
Включает поддержку PIE3 для компилятора GCC. Включение PIE в GCC осложняет организацию атак ROP4. По умолчанию в файле security_flags.inc указано GCCPIE ?= “–enable-default-pie”.
Задает принятый по умолчанию компилятор GNU C (GCC). По умолчанию в файле meta/conf/distro/include/tcmode-default.inc задано GCCVERSION ?= “8.%”. Можно указать другую версию в файле local.conf.
Сокращенная команда и аргументы для запуска отладчика GNU (gdb).
Каталог для хранения локальной копии репозитория Git при его клонировании.
Задает список языковых файлов GLIBC, если не нужны все такие файлы (занимает много времени). При удалении языка en_US.UTF-8 следует должным образом установить переменную IMAGE_LINGUAS. По умолчанию создаются файлы для всех языков. Значение GLIBC_GENERATE_LOCALES можно указать в файле local.conf как GLIBC_GENERATE_LOCALES = “en_GB.UTF-8 en_US.UTF-8″.
При наследовании класса useradd эта переменная указывает, какие параметры для пакета следует передать команде groupadd, если нужно добавить группу при установке пакета. Например, для задания dbus указывается GROUPADD_PARAM_${PN} = “-r netdev”
Информация о стандартной команде Linux groupadd доступна по ссылке http://linux.die.net/man/8/groupadd.
При наследовании класса useradd эта переменная указывает, какие параметры для пакета следует передать команде groupmems, если нужно изменить состав группы при установке пакета.
Информация о стандартной команде Linux groupmems доступна по ссылке http://linux.die.net/man/8/groupmems.
Указывает режим работы загрузчика GRUB5. Установите для этой переменной значение 1 в файле local.conf или файле конфигурации дистрибутива для включения графического режима и консоли serial. Использование переменной рассмотрено в описании класса grub-efi.
Опции для добавления в конфигурацию загрузчика GRUB, разделенные точкой с запятой (;). Переменная не обязательна, ее использование переменной рассмотрено в описании класса grub-efi.
Задает время ожидания перед выбором заданной по умолчанию метки default LABEL загрузчике GRUB. Переменная не обязательна, ее использование переменной рассмотрено в описании класса grub-efi.
При наследовании класса gtk-immodules-cache эта переменная указывает пакеты, содержащие устанавливаемые модули ввода GTK+, когда они не находятся в основном пакете.
H
Web-сайт, на котором можно найти дополнительную информацию о собираемой заданием программе.
Имя целевой архитектуры, которое обычно совпадает с TARGET_ARCH. Система сборки OE поддерживает множество вариантов архитектуры, включая arm, i586, x86_64, powerpc, powerpc64, mips, mipsel.
Указывает зависящие от архитектуры флаги, передаваемые компилятору C. Принятая по умолчанию инициализация HOST_CC_ARCH зависит от цели сборки:
TARGET_CC_ARCHпри сборке для целевой платформы;BUILD_CC_ARCHпри сборке для сборочного хоста (-native);BUILDSDK_CC_ARCHпри сборке для SDK (nativesdk-).
Задает имя целевой операционной системы, которое обычно совпадает с TARGET_OS. Для переменной можно установить значение linux в системах на основе glibc и linux-musl в системах на основе musl. Для платформ ARM/EABI возможны также значения linux-gnueabi и linux-musleabi.
Задает префикс для инструментов кросс-компиляции. HOST_PREFIX обычно совпадает с TARGET_PREFIX.
Задает систему, включая архитектуру и ОС, для которой выполняется сборка в контексте текущего задания. Система сборки OE автоматически устанавливает эту переменную на основе значений HOST_ARCH, HOST_VENDOR и HOST_OS. Например, для естественного задания на 32-битовой машине x86 с ОС Linux переменная будет иметь значение i686-linux, а для задания на платформе little-endian MIPS с ОС Linux – mipsel-linux. Менять переменную не нужно.
Список разделенных пробелами инструментов, которые можно вызывать на хосте сборки из сборочных задач. Использование этого фильтра помогает снизить вероятность нарушения работы сборочного хоста. Если заданный в переменной инструмент не найден, система сборки OE выдает ошибку и сборка не начинается.
Список разделенных пробелами инструментов, которые можно вызывать на хосте сборки из сборочных задач. Использование этого фильтра помогает снизить вероятность нарушения работы сборочного хоста. В отличие от инструментов HOSTTOOLS
системаOE не выдает ошибку при отсутствии указанного в
сборки HOSTTOOLS_NONFATAL.
Таким.
образом, эта переменная указывает
необязательные инструменты хоста
Задает имя производителя целевого хоста. HOST_VENDOR обычно совпадает с TARGET_VENDOR.
I
Управляет работой icecc (Icecream), рассмотренной в параграфе 6.49. icecc.bbclass. Установка в файле local.conf ICECC_DISABLED ??= “1” отключает функцию, ICECC_DISABLED = “” – включает.
Указывает пользовательский сценарий icecc-create-env, используется классом icecc и устанавливается в файле local.conf. Если сценарий не указан, система сборки OE использует принятый по умолчанию сценарий из задания icecc-create-env.bb, который является измененной версией сценария из состава icecc.
Опции, передаваемые команде make в задаче do_compile для параллельной компиляции. Эта переменная обычно имеет форму -j x, где x указывает максимальное число параллельных потоков. Опция влияет на все машины в сети сборки, где работает демон iceccd. При поддержке машинами множества ядер определение максимального числа потоков может потребовать некоторых экспериментов для учета скорости машин, задержек в сети, доступной памяти и текущей загрузки машин. Поэтому, в отличие от переменной PARALLEL_MAKE, для
установки ICECC_PARALLEL_MAKE нет строгих правил.
При отсутствии ICECC_PARALLEL_MAKE система сборки не будет определять и задавать число используемых ядер, как это делается для PARALLEL_MAKE.
Путь к исполняемому файлу icecc, задаваемый в файле local.conf. Если путь не задан, класс icecc пытается найти icecc с помощью команды which.
Указывает пользовательские классы, для который не следует использовать распределенную компиляцию Icecream. Переменная используется классом icecc и устанавливается в файле local.conf. Все указанные переменной классы будут компилироваться локально.
Указывает пользовательские задания, которые не нужно учитывать в распределенной компиляции Icecream. Переменная используется классом icecc и устанавливается в файле local.conf. Все указанные переменной пакеты будут компилироваться локально.
Указывает пользовательские задания с пустой переменной PARALLEL_MAKE,
дляIcecream. Переменная используется классом
которых нужно принудительно использовать
параллельную удаленную компиляции с
использованием системы распределенной
компиляции icecc
и
может указываться в файлеlocal.conf.
Базовое имя выходных файлов образа, по умолчанию совпадающее с именем задания (${PN}).
Список разделенных пробелами файлов, установленных в корневой раздел пр подготовке образа с использованием Wic и подключаемым модулем bootimg-partition. По умолчанию файлы устанавливаются с теми же именами, которые были у исходных файлов. Для изменения имен их следует отделять от исходных имен точкой с запятой (;). Исходные файлы должны размещаться в DEPLOY_DIR_IMAGE. Ниже приведены два примера.
IMAGE_BOOT_FILES = "u-boot.img uImage;kernel"
IMAGE_BOOT_FILES = "u-boot.${UBOOT_SUFFIX} ${KERNEL_IMAGETYPE}"
Кроме того, исходные файлы можно указать с помощью шаблона glob. В этом случае целевой файл должен иметь такое же имя, как и базовое имя в пути к исходному файлу. Для установки файлов в целевой системе их имена передаются после точки с запятой (;), как показано в приведенных ниже примерах.
IMAGE_BOOT_FILES = "bcm2835-bootfiles/*"
IMAGE_BOOT_FILES = "bcm2835-bootfiles/*;boot/"
Первый пример устанавливает все файлы из ${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles в корневой раздел целевой системы, а второй устанавливает те же файлы в каталог boot внутри целевого раздела.
Информация о работе с Wic приведена в разделе Creating Partitioned Images Using Wic [2], а Глава 9. Справочник по OpenEmbedded Kickstart (.wks) содержит описание Wic.
Список классов, которые нужно наследовать всем образам. Обычно эта переменная служит для задания классов, регистрирующих разные типы образов, которые создает система сборки OE. По умолчанию используется IMAGE_CLASSES = image_types,
но
можно установить другое значение в
файле local.conf или в конфигурационном файле дистрибутива (см. meta/classes/image_types.bbclass в каталоге исходных кодов).
Задает команду создания файла образа определенного типа, соответствующего значению IMAGE_FSTYPES (например, ext3, btrfs
и). При установке переменной следует использовать переопределение для связанного типа, как показано ниже.
т. п.
IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} \
--faketime --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \
${EXTRA_IMAGECMD}"
Обычно эту переменную не требуется устанавливать, если не добавляется поддержка нового типа образов. Примеры установки этой переменной можно найти в файле meta/classes/image_types.bbclass.
Задает один или несколько файлов с пользовательскими таблицами устройств, которые передаются команде makedevs как часть создания образа. Эти файлы указывают базовые узлы устройства, которые следует создать в иерархии /dev внутри образа. Если переменная не указана, используется файл files/device_table-minimal.txt is used, найденный в пути BBPATH. Пример таблицы устройств имеется в файле meta/files/device_table-minimal.txt.
Основной список свойств (возможностей) для включения в образ. Обычно эта переменная указывается в задании для образа. Можно указать переменную в файле local.conf в каталоге сборки, но лучше так не поступать.
Для добавления возможностей за пределами задания для образа служит переменная EXTRA_IMAGE_FEATURES.
Список возможностей, включенных в выпуск YP, представлен в параграфе 12.3. Свойства образа. Пример настройки образа с помощью этой переменной приведен в разделе Customizing Images Using Custom IMAGE_FEATURES and EXTRA_IMAGE_FEATURES [2].
Задает формат, применяемый системой сборки OE при создании корневой файловой системы. Например, для создания файлов систем, использующих форматы .ext3 и .tar.bz2
служитIMAGE_FSTYPES = “ext3 tar.bz2”.
Полный список поддерживаемых форматов приведен в описании переменной IMAGE_TYPES.
- Если задание для образа использует строку inherit image и в нем установлена переменная
IMAGE_FSTYPES,ее значение должно быть установлено до строки inherit image. - Способ обработки этой переменной в системе сборки OE не позволяет обновлять ее содержимое с помощью
_appendили_prepend
и
требует использования оператора+=для добавления опций вIMAGE_FSTYPES.
Используется в заданиях для указания пакетов, устанавливаемых в образ с помощью класса image.
Переменную. Имеются вспомогательные классы (например,
следует применять осторожно, чтобы не
возникло проблем с порядком установкиcore-image),
принимающие списки, используемые с
IMAGE_FEATURES,
и
включающие элементы в автоматически
создаваемые записи IMAGE_INSTALL в дополнение к имеющимся.
При использовании переменной лучше всего ее задавать, как показано ниже.
IMAGE_INSTALL_append = " package-name"
Не забывайте указывать пробел перед именем пакета.
- При работе с образом
core-image-minimal-initramfsне используйте переменнуюIMAGE_INSTALLдля задания устанавливаемых пакетов. В этом случае нужна переменнаяPACKAGE_INSTALL, которая позволяет заданию initramfs использовать фиксированный набор приложений, на который не влияет переменнаяIMAGE_INSTALL. Информация о создании initramfs приведена в разделе Building an Initial RAM Filesystem (initramfs) Image [2]. - Использование переменной
IMAGE_INSTALLсBitBake
оператором+=
в
файле/conf/local.conffile или иных файлах задания для образе не рекомендуется, поскольку применение этого оператора может приводить к проблемам с порядком установки. Классаcore-image.bbclassустанавливает дляIMAGE_INSTALLпринятое по умолчанию значение с помощью оператора?=, использование+=для переменнойIMAGE_INSTALLв файлеconf/local.confприводит к неожиданному поведению. Кроме того, та же операция из задания для образа может завершаться отказом в зависимости от ситуации. В обоих случаях поведение будет отличаться от ожидаемого пользователем для оператора
+=.
Задает список языков (locale) для включения в образ при создании корневой файловой системы. Система сборки OE автоматически разделяет языковые файлы по отдельным пакетам. Назначение переменной IMAGE_LINGUAS гарантирует включение языковых пакетов во все пакеты, выбранные для инсталляции в образ. Переменная задается в форме IMAGE_LINGUAS = “pt-br de-de”. Пример показывает установку языковых файлов для бразильского португальского и немецкого языка для включенных в образ пакетов (т. е. *-locale-pt-br и *-locale-de-de, а для некоторых пакетов *-locale-pt и *-locale-de, поскольку часть пакетов обеспечивает файлы языков без учета страны). Генерация языковых файлов GLIBC рассмотрена в описании переменной GLIBC_GENERATE_LOCALES.
Файл манифеста для образа, перечисляющий все установленные пакеты (по одной строке на пакет) в форме packagename packagearch version. Класс image определяет файл манифеста как IMAGE_MANIFEST = “${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest”. Местоположение выводится из переменных DEPLOY_DIR_IMAGE и IMAGE_NAME. Создание образов описано в разделе Image Generation [1].
Имя выходных файлов образа без расширений, задаваемое в форме IMAGE_NAME = “${IMAGE_BASENAME}-${MACHINE}-${DATETIME}”.
Определяет коэффициент, который система сборки использует для начального размера образа в случаях, когда используемое в образе пространство (возврат команды du), умноженное на этот коэффициент, превышает сумму IMAGE_ROOTFS_SIZE и IMAGE_ROOTFS_EXTRA_SPACE. Результатом использования коэффициента для начального размера является увеличение свободного пространства в образе. По умолчанию система сборки использует для этой переменной значение 1,3, что приводит к добавлению 30% свободного пространства в финальный образ. Следует учитывать, что применяемые после инсталляции сценарии и система управления пакетами используют пространство из этой области. Поэтому коэффициент не задает точно свободное пространство, получаемое в результате. Определение общего размера образа зависит от переменной IMAGE_ROOTFS_SIZE.
Установленное по умолчанию свободное пространство в 30% обеспечивает достаточно места для загрузки и использования пост-установочных сценариев для большинства случаев. Если это значение не подходит, можно изменить размер свободного пространства. Например, для резервирования 50% свободно места можно задать IMAGE_OVERHEAD_FACTOR = “1.5”. Можно также обеспечить дополнительное свободное пространство на диске с помощью переменной IMAGE_ROOTFS_EXTRA_SPACE.
Определяет тип пакета (DEB, RPM, IPK или TAR), используемый системой сборки OE. Переменная определяется классом package_deb, package_rpm, package_ipk или package_tar. Класс package_tar больше не применяется и не поддерживается, поэтому не следует его использовать. Классы populate_sdk_* и image используют переменную IMAGE_PKGTYPE для упаковки образов и SDK.
Переменную IMAGE_PKGTYPE не следует устанавливать вручную, поскольку она задается опосредованно через подходящий класс package_* с использованием переменной PACKAGE_CLASSES. Система сборки OE применяет первый тип пакета (DEB, RPM или IPK) из этой переменной.
Архивы .tar никогда не применяются в качестве замены форматов DEB, RPM и IPK для образов и SDK.
Задает список функций, однократно вызываемых системой сборки OE при создании окончательных выходных файлов. Функции разделяются точкой с запятой, например, IMAGE_POSTPROCESS_COMMAND += “function; … “
Если нужно передать путь к корневой файловой системе при вызове функции, можно использовать переменную ${IMAGE_ROOTFS}, указывающую каталог, который станет корневой файловой системой образа.
Задает список функций, вызываемых системой сборки OE перед созданием окончательных выходных файлов. Функции разделяются точкой с запятой, например, IMAGE_PREPROCESS_COMMAND += “function; … “
Если нужно передать путь к корневой файловой системе при вызове функции, можно использовать переменную ${IMAGE_ROOTFS}, указывающую каталог, который станет корневой файловой системой образа.
Местоположение корневой файловой системы в процессе ее создания (задача do_rootfs). Значение этой переменной не следует менять.
Задает выравнивание для выходного файла образа в килобайтах. Если размер образа не кратен этому значению, он округляется вверх до кратного значения. По умолчанию установлено значение 1 (см. IMAGE_ROOTFS_SIZE).
Задает дополнительное свободное пространства в создаваемом образе (в килобайтах). По умолчанию дополнительное пространство не выделяется (0). Заданное переменной пространство добавляется в образ после того, как система сборки определит размер образа в соответствии с переменной IMAGE_ROOTFS_SIZE.
Переменная полезна для резервирования свободного пространства в файловой системе после загрузки образа. Например, для обеспечения свободных 5 Гбайт можно указать IMAGE_ROOTFS_EXTRA_SPACE = “5242880”. В частности, Yocto Project Build Appliance задает 40 Гбайт дополнительного места с помощью строки IMAGE_ROOTFS_EXTRA_SPACE = “41943040”.
Определяет размер создаваемого образа к килобайтах. Система сборки OE определяет окончательный размер создаваемого образа с учетом начального диска, используемого для образа, запрошенного размера образа и запрошенного свободного пространства после загрузки образа. Псевдокод для определения размера можно представить в виде
if (image-du * overhead) < rootfs-size:
internal-rootfs-size = rootfs-size + xspace
else:
internal-rootfs-size = (image-du * overhead) + xspace
где
image-du – значение, возвращаемое командой du для образа;
overhead – IMAGE_OVERHEAD_FACTOR;
rootfs-size – IMAGE_ROOTFS_SIZE;
internal-rootfs-size – начальный размер корневой файловой системы до каких-либо изменений;
xspace – IMAGE_ROOTFS_EXTRA_SPACE.
Указывает зависимость одного типа образа от другого, например, для образа из класса image-liveIMAGE_TYPEDEP_live = “ext3”. В этом примере переменная обеспечивает включение live в переменную
IMAGE_FSTYPES
и система сборки OE создает сначала образ ext3, поскольку одной из частей образа live является раздел формата ext3 с корневой файловой системой.
Задает полный список поддерживаемых по умолчанию типов образов: btrfs, cpio, cpio.gz, cpio.lz4, cpio.lzma, cpio.xz, cramfs, elf, ext2, ext2.bz2, ext2.gz, ext2.lzma, ext3, ext3.gz, ext4, ext4.gz, hdddirect, hddimg, iso, jffs2, jffs2.sum, multiubi, squashfs, squashfs-lzo, squashfs-xz, tar, tar.bz2, tar.gz, tar.lz4, tar.xz, ubi, ubifs, wic, wic.bz2, wic.gz, wic.lzma.
Полная информация об этих типах приведена в файлах meta/classes/image_types*.bbclass дерева исходных кодов.
Помогает указать выпуск для заданий, использующих общий включаемый файл. Можно считать эту переменную частью варианта задания, устанавливаемой из включаемого файла.
Предположим, что имеется набор заданий, используемых в нескольких проектах, и для каждого из этих заданий задан выпуск (в переменной PR). В этом случае при изменении номера выпуска задания нужно найти все эти задания и убедиться в корректности обновления номера выпуска. Это может осложняться использованием заданий в разных местах, когда обновляются задания, обеспечивающие общую функциональность. Более эффективным способом в таких случаях является установка переменной INC_PR во включаемых файлах, совместно используемых заданиями, с последующим преобразованием переменной в заданиях для определения выпуска.
Ниже приведен пример использования переменной INC_PR с учетом общего включаемого файла, определяющего эту переменную. После ее указания во включаемом файле переменную можно
использовать для установки значений
PR в каждом задании. При установке PR для задания можно более точно указать выпуск, добавляя значение в конце переменной INC_PR,
как
показано ниже.
recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1"
recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0"
recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
Первая строка в этом примере показывает базовый номер выпуска, используемый всеми заданиями, которые применяют включаемый файл. Остальные строки уточняют выпуски для отдельных заданий, устанавливая PR.
Задает список разделенных пробелами имен лицензий (как в переменной LICENSE), которые следует исключить при сборке. Значения, не содержащие замены исключенных лицензий, собираться не будут, пакеты, с несовместимыми лицензиями будут удалены. Эта функциональность регулярно проверяется лишь для INCOMPATIBLE_LICENSE = “GPL-3.0 LGPL-3.0 AGPL-3.0”. Ваши установки могут отличаться, но все равно может потребоваться указание несовместимых лицензий или замен для создания образа.
Задает глобальное наследование указанных классов. Анонимные функции классов не выполняются для базовой конфигурации и в каждом отдельном задании. Система сборки OE игнорирует изменение переменной INHERIT в отдельных заданиях. Дополнительная информация приведена в разделе INHERIT Configuration Directive [4].
Указывает классы, которые будут наследоваться на уровне дистрибутива. Обычно менять эту переменную не требуется. Используемое по умолчанию значение переменной задано в файле meta/conf/distro/defaultsetup.conf как INHERIT_DISTRO ?= “debian devshell sstate license”.
Предотвращает добавление заданных по умолчанию зависимостей (компилятор C и стандартная библиотека libc) в DEPENDS. Переменная обычно применяется в заданиях, которым не нужен компилятор C. Установка значения 1 предотвращает добавление принятых по умолчанию зависимостей.
Установка значения 1 в этой переменной предотвращает отделение отладочной информации при подготовке пакетов. По умолчанию система сборки отделяет отладочную информацию в процессе выполнения задачи do_package
(см. описание PACKAGE_DEBUG_SPLIT_STYLE).
Установка значения 1 отменяет удаление системой сборки символов из собранных пакетов и предотвращает включение исходных файлов в пакеты -dbg. По умолчанию система сборки OE вырезает символы из двоичных файлов и помещает отладочные символы в ${PN}-dbg. Поэтому не следует устанавливать переменную INHIBIT_PACKAGE_STRIP,
если.
планируется отладка
Установка значения 1 отменяет удаление системой сборки символов из двоичных файлов sysroot, выполняемое по умолчанию. Для использования переменной в задании нужно включить класс staging, который применяет функцию sys_strip() для проверки значения переменной и выполнения нужных действий.
Переменная применяется редко. Примером может служить создание прошивки для пустой платформы (bare-metal) с использованием внешних инструментов GCC. Более того, даже при вырезании информации из двоичных файлов инструментария остаются другие файлы, которые нужны для сборки и не вырезаются.
Задает формат выходного образа initramfs, используемого при загрузке. Поддерживаемые форматы совпадают с возможными форматами IMAGE_FSTYPES. По умолчанию в файле meta/conf/bitbake.conf для этой переменной задается значение cpio.gz. Механизм initramfs в Linux в отличие от initrd предполагает возможность сжатия образа.
Задает имя задания (PROVIDES) для образа, используемое при сборке образа initramfs. Иными словами, переменная вызывает дополнительное задание для сборки как зависимость от используемого для корневой файловой системы задания (например, core-image-sato). Представленное задание для образа initramfs должно устанавливать в IMAGE_FSTYPES значение INITRAMFS_FSTYPES.
Образ обеспечивает временную корневую файловую систему, используемую для начальной инициализации (например, загрузки модулей, требуемых для монтирования реальной корневой файловой системы). В файле meta/recipes-core/images/core-image-minimal-initramfs.bb дерева исходных кодов приведен пример задания initramfs. Для выбора этого образца в качестве задания для образа initramfs нужно установить в переменной INITRAMFS_IMAGE значение core-image-minimal-initramfs. Использование переменной INITRAMFS_IMAGE рассмотрено в файле meta-poky/conf/local.conf.sample.extended, а также в описании классов image и kernel.
Если значение переменной INITRAMFS_IMAGE пусто (принято по умолчанию), образ initramfs не создается.
Переменная INITRAMFS_IMAGE_BUNDLE позволяет связать генерируемый образ с образом ядра. Сведения о создании образов initramfs приведены в разделе Building an Initial RAM Filesystem (initramfs) Image [2].
Управляет дополнительным проходом do_bundle_initramfs при компиляции ядра для образа, заданного переменной INITRAMFS_IMAGE, с целью создания одного двоичного файла с образами ядра и initramfs. Для этого используется свойство ядра CONFIG_INITRAMFS_SOURCE.
Дополнительный проход компиляции для связывания initramfs предотвращает зацикливание зависимостей между заданиями для ядра и initramfs, когда initramfs включает модули ядра. В таких случаях задание initramfs зависит от ядра для получения модулей, а ядро зависит от initramfs, поскольку initramfs встраивается в образ ябра.
Объединенный двоичный файл размещается в каталоге tmp/deploy внутри каталога сборки.
Установка INITRAMFS_IMAGE_BUNDLE = “1” в конфигурационном файле системы сборки OE ведет к генерации образа ядра с initramfs, указанной в INITRAMFS_IMAGE. По умолчанию класс kernel устанавливает пустое значение INITRAMFS_IMAGE_BUNDLE ?= “”.
Переменная должна указываться в конфигурационном файле, а не в файле задания. Дополнительная информация приведена в файле local.conf.sample.extended, а создание initramfs описано в разделе Building an Initial RAM Filesystem (initramfs) Image [2].
Имя ссылки для исходного образа файловой системы initramfs. Переменная задается в файле meta/classes/kernel-artifact-names.bbclass как INITRAMFS_LINK_NAME ?= “initramfs-${KERNEL_ARTIFACT_LINK_NAME}”. Этот же файл задает переменную KERNEL_ARTIFACT_LINK_NAME ?= “${MACHINE}”.
Базовое имя исходного образа файловой системы initramfs. Переменная задается в файле meta/classes/kernel-artifact-names.bbclass как INITRAMFS_NAME ?= “initramfs-${KERNEL_ARTIFACT_NAME}”. Этот же файл задает KERNEL_ARTIFACT_NAME ?= “${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}”.
Задает список файловых систем для конкатенации и использования в качестве исходного RAM-диска (initrd). Переменная не обязательна и применяется классом image-live.
При сборке загружаемых образов live (IMAGE_FSTYPES содержит live) переменная задает задание для образа, которое следует собрать для создания образа исходного RAM-диска. По умолчанию задано значение core-image-minimal-initramfs (см. параграф 6.53. image-live.bbclass).
Имя файла со сценарием инициализации, установленное в ${sysconfdir}/init.d. Переменная применяется в заданиях, использующих класс update-rc.d.bbclass,
и.
является обязательной
Список пакетов, содержащих сценарии инициализации. При задании нескольких пакетов нужно добавлять имя пакета в конце к другим INITSCRIPT_* как переопределение. Переменная применяется в заданиях, использующих класс update-rc.d.bbclass. Переменная не обязательна и по умолчанию имеет значение переменной PN.
Задает опции для передачи update-rc.d. Например, INITSCRIPT_PARAMS = “start 99 5 2 . stop 20 0 1 6 .” указывает сценарий с уровнем запуска (runlevel) 99, запускаемый на уровнях 2 и 5, останавливаемый на уровнях 0, 1 и 6.
По умолчанию переменная имеет значение defaults, устанавливаемое классом update-rc.d. Значение переменной передается через команду update-rc.d. Дополнительная информация доступна по ссылке.
Задает проверки QA, пропускаемые для конкретного пакета в задании. Например, для пропуска проверки символьных ссылок для файлов .so в основном пакете задания в это задание добавляется приведенная ниже переменная. Следует указывать переопределенное имя задания (в примере ${PN}).
INSANE_SKIP_${PN} += "dev-so"
Список проверок QA, которые можно указать в этой переменной, приведен в параграфе 6.56. insane.bbclass.
По умолчанию задание tzdata включает файл /etc/timezone. Установка INSTALL_TIMEZONE_FILE = 0 на уровне конфигурации отменяет это.
При использовании менеджера IPK и включенном на целевой платформе управлении пакетами эта переменная может служить для установки opkg в целевом образе с целью указания источника пакетов на означенном сервере. После организации источника можно устанавливать и обновлять пакеты при работе платформы.
K
Указывает архитектуру ядра, применяемую для сборки конфигурации – powerpc, i386, x86_64, arm, qemu, mips. Переменная KARCH определяется в описаниях BSP [3].
Регулярное выражение, применяемое процессом сборки для явного указания ветви ядра, которая проверяется, изменяется (patch) и настраивается в процессе сборки. Нужно задать эту переменную для точного выбора ветви ядра, используемой в процессе сборки.
Значение этой переменной устанавливается в наборе заданий и файле добавления для ядра. Например, для ядра linux-yocto_4.12 файлом задания является meta/recipes-kernel/linux/linux-yocto_4.12.bb. Переменная KBRANCH в этом файле задается в форме
KBRANCH ?= "standard/base"
Переменная применяется также из файла добавления для ядра, чтобы указать конкретную ветвь ядра для целевой платы или оборудования. В предыдущем примере файл добавления для ядра (linux-yocto_4.12.bbappend) размещается на уровне BSP для данной машины. Например, файл добавления для Beaglebone, EdgeRouter и базовых версий 32- и 64-битовых машин IA (meta-yocto-bsp) называется meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend. Ниже приведены операторы и этого файла.
KBRANCH_genericx86 = "standard/base"
KBRANCH_genericx86-64 = "standard/base"
KBRANCH_edgerouter = "standard/edgerouter"
KBRANCH_beaglebone = "standard/beaglebone"
KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
Операторы KBRANCH указывают ветвь ядра, которая будет использоваться при сборке для каждого BSP.
При использовании с классом kernel-yocto задает размещенный в дереве исходных кодов ядра конфигурационный файл для использования при сборке ядра. Обычно при использовании файла defconfig для настройки конфигурации ядра при сборке файл помещается в каталог вашего уровня как и файлы исправлений, а также файлы с фрагментами конфигурации. Однако если вы хотите использовать файл defconfig как часть дерева ядра, можно воспользоваться переменной KBUILD_DEFCONFIG и добавить переменную KMACHINE для указания файла defconfig.
Для использования переменной следует указать ее в файле добавления для задания ядра в виде KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file. Например, для сборки raspberrypi2 KMACHINE с файлом defconfig, названным bcm2709_defconfig, служит KBUILD_DEFCONFIG_raspberrypi2 = “bcm2709_defconfig”.
Как вариант, можно указать в файле добавления KBUILD_DEFCONFIG_pn-linux-yocto ?= defconfig_file.
Информация об использовании KBUILD_DEFCONFIG приведена в разделе Using an “In-Tree” defconfig File [3].
Задает другой тип образа ядра в дополнение к типу, указанному переменной KERNEL_IMAGETYPE.
Указывает имя для всех элементов сборки (artifact). Значение переменной задается в файле meta/classes/kernel-artifact-names.bbclass как KERNEL_ARTIFACT_NAME ?= “${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}”. Дополнительная информация приведена в описаниях переменных PKGE, PKGV, PKGR и MACHINE. Для переменной IMAGE_VERSION_SUFFIX устанавливается значение DATETIME.
Список классов, определяющих типы образов ядра, которые должен наследовать класс kernel. Обычно эта переменная добавляется для включения расширенных типов образов. Примером является класс kernel-fitimage, включающий поддержку fitImage и заданный в файле meta/classes/kernel-fitimage.bbclass. Можно зарегистрировать свои типы образов ядра с помощью этой переменной.
Задает имя создаваемого файла с деревом устройств ядра Linux (.dtb). Имеется устаревший способ указания полного пути к дереву устройств, однако предпочтительней использовать файл .dtb. Для использования переменной нужно указать включаемые файлы в задании для ядра в форме require recipes-kernel/linux/linux-dtb.inc или require recipes-kernel/linux/linux-yocto.inc.
Имя ссылки на двоичное дерево устройств (DTB6) в файле meta/classes/kernel-artifact-names.bbclass, указанное как KERNEL_DTB_LINK_NAME ?= “${KERNEL_ARTIFACT_LINK_NAME}”. Переменная KERNEL_ARTIFACT_LINK_NAME в
том же файле имеет форму KERNEL_ARTIFACT_LINK_NAME ?= “${MACHINE}”.
Базовое имя DTB, задаваемое в файле meta/classes/kernel-artifact-names.bbclass как KERNEL_DTB_NAME ?= “${KERNEL_ARTIFACT_NAME}”. Переменная KERNEL_ARTIFACT_NAME в том же файле имеет форму KERNEL_ARTIFACT_NAME ?= “${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}”.
Задает дополнительные аргументы команды make, которые система сборки OE использует при компиляции ядра.
Включает дополнительные метаданные ядра. В системе сборки OE принятые по умолчанию метаданные BSP обеспечиваются переменными KMACHINE и KBRANCH. Можно использовать переменную KERNEL_FEATURES из задания или файла добавления для ядра, чтобы добавить метаданные для всех или определенных BSP.
Добавляемые через эту переменную метаданные включают фрагменты конфигурации и описания функций, которые обычно включают исправления (patch), а также фрагменты конфигурации. Переменная KERNEL_FEATURES обычно переопределяется для конкретной машины. Таким способом обеспечивается проверяемый, но не обязательный набор функций и конфигурационных параметров ядра.
Например, можно в задание linux-yocto-rt_4.добавитьnetfilter и taskstats для всех BSP, а также конфигурации virtio для всех машин QEMU. Два последних оператора добавляют конкретные конфигурации к целевым типам машин.
функции
KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc" KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" KERNEL_FEATURES_append_qemuall = " cfg/virtio.scc" KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc" KERNEL_FEATURES_append_qemux86-64 = " cfg/sound.scc"
Имя ссылки на плоское дерево образа ядра (FIT), задаваемое в файле meta/classes/kernel-artifact-names.bbclass
как KERNEL_FIT_LINK_NAME ?= “${KERNEL_ARTIFACT_LINK_NAME}”. В том же файле указывается переменная KERNEL_ARTIFACT_LINK_NAME ?= “${MACHINE}”.
Базовое имя плоского дерева образа ядра (FIT), задаваемое в файле meta/classes/kernel-artifact-names.bbclass как KERNEL_FIT_NAME ?= “${KERNEL_ARTIFACT_NAME}”. В этом же файле устанавливается переменная KERNEL_ARTIFACT_NAME ?= “${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}”.
Имя ссылки для образа ядра, устанавливаемое в файле meta/classes/kernel-artifact-names.bbclass как KERNEL_IMAGE_LINK_NAME ?= “${KERNEL_ARTIFACT_LINK_NAME}”. В том же файле файле устанавливается переменная KERNEL_ARTIFACT_LINK_NAME ?= “${MACHINE}”.
Задает максимальный размер образа ядра в килобайтах. При установке переменной размер ядра сравнивается с ее значением при выполнении задачи do_sizecheck
с. Переменная полезна для систем с ограниченным пространством для хранения образа ядра. По умолчанию переменная не устанавливается и размер ядра не ограничен.
возвратом ошибки в случае превышения
заданного размера
Базовое имя образа ядра. Переменная задается файлом meta/classes/kernel-artifact-names.bbclass в форме KERNEL_IMAGE_NAME ?= “${KERNEL_ARTIFACT_NAME}”. Значение переменной KERNEL_ARTIFACT_NAME
вKERNEL_ARTIFACT_NAME ?= “${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}”.
том же файле имеет форму
Тип ядра, собираемого для устройства, который обычно задается конфигурационными файлами для машины. По умолчанию применяется zImage. Эта переменная используется при сборке ядра и передается команде make как цель сборки. Для сборки дополнительного типа образа используется переменная KERNEL_ALT_IMAGETYPE.
Указывает модули ядра, которые нужно автоматически загружать при загрузке системы. Переменную можно использовать в любом месте, доступном заданию для ядра или внешнего (out-of-tree) модуля (например, в файле конфигурации машины или дистрибутива, файле дополнения к заданию или самом задании).
KERNEL_MODULE_AUTOLOAD += "module_name1module_name2module_name3"
Включение KERNEL_MODULE_AUTOLOAD заставляет систему сборки OE указать список автоматически загружаемых модулей в файле /etc/modules-load.d/modname.conf. Модули указываются по одному в строке, например, KERNEL_MODULE_AUTOLOAD += “module_name“.
Информация о заполнении файла modname.conf в синтаксисом modprobe.d приведена в описании переменной KERNEL_MODULE_PROBECONF.
Задает список модулей, для которых система сборки OE предполагает найти значения module_conf_modname,
задающие
конфигурацию каждого модуля. Информация
о настройке модулей приведена в описании
переменной
module_conf.
Указывает местоположение исходных кодов ядра. Переменная получает значение STAGING_KERNEL_DIR в классе module. Работа с переменной описана в разделе Incorporating Out-of-Tree Modules [3].
Для максимальной совместимости с внешними (out-of-tree) драйверами при сборке модулей система OE распознает и применяет переменную KERNEL_SRC, которая идентична KERNEL_PATH. Обе переменные используются внешними файлами Makefile для указания каталога с исходными кодами ядра.
Указывает местоположение исходных кодов ядра. Переменная получает значение STAGING_KERNEL_DIR в классе module. Работа с переменной описана в разделе Incorporating Out-of-Tree Modules [3].
Для максимальной совместимости с внешними (out-of-tree) драйверами при сборке модулей система OE распознает и применяет переменную KERNEL_PATH, которая идентична KERNEL_SRC. Обе переменные используются внешними файлами Makefile для указания каталога с исходными кодами ядра.
Указывает версию ядра, извлеченную из файла version.h или utsrelease.h в дереве кода ядра. Установка этой переменной не оказывает влияния, пока не будет настроена конфигурация ядра, поэтому попытка обращения к ней до настройки конфигурации не приведет к желаемому результату.
Указывает, нужны ли данные, упомянутые в переменной PKGDATA_DIR. KERNELDEPMODDEPEND контролирует не наличие этих данных, а их использование. Если данные не нужны, укажите KERNELDEPMODDEPEND в задании initramfs, это позволит предотвратить возможное зацикливание зависимостей.
Дает краткое описание фрагмента конфигурации. Эта переменная применяется в файлах .scc, описывающих файлы с фрагментами конфигурации. Например, в файле в файле smp.scc эта переменная включает опции SMP в форме define KFEATURE_DESCRIPTION “Enable SMP”.
Машина, известная ядру. Иногда используемое ядром имя машины не совпадает с именем в системе сборки OE. Например, имя машины, которое система OE воспринимает как core2-32-intel-common, будет иным в ядре Linux Yocto (intel-core2-32). Для таких случаев переменная KMACHINE сопоставляет имена машины в ядре и системе сборки OE.
Эти сопоставления выполняются в ветвях метаданных ядер Yocto Linux. В качестве примера рассмотрим файл common/recipes-kernel/linux/linux-yocto_3.19.bbappend.
LINUX_VERSION_core2-32-intel-common = "3.19.0"
COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
SRCREV_meta_core2-32-intel-common = "8897ef68b30e7426bc1d39895e71fb155d694974"
SRCREV_machine_core2-32-intel-common = "43b9eced9ba8a57add36af07736344dcc383f711"
KMACHINE_core2-32-intel-common = "intel-core2-32"
KBRANCH_core2-32-intel-common = "standard/base"
KERNEL_FEATURES_append_core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}"
Оператор KMACHINE говорит, что ядро воспринимает имя машины как intel-core2-32, однако система сборки OE именует ее как core2-32-intel-common.
Определяет тип ядра, используемый при сборке конфигурации. Задания linux-yocto определяют типы standard, tiny и preempt-rt (см. раздел Kernel Types [3]). Переменная KTYPE задается в описании BSP, а ее значение должно соответствовать значению переменной LINUX_KERNEL_TYPE в задании для ядра.
L
Указывает список целей для автоматической настройки конфигурации. Использование переменной рассмотрено в описании класса grub-efi.
Список разделенных пробелами уровней, от которых зависит данный уровень. Можно также указывать конкретную версию уровня, добавляя ее в конце имени. Например, LAYERDEPENDS_mylayer = “anotherlayer (=3)”, где номер версии 3 уровня anotherlayer сравнивается с LAYERVERSION_anotherlayer. Переменная
указывается в файле conf/layer.conf
и
должна иметь суффикс в виде имени
конкретного уровня (например,
LAYERDEPENDS_mylayer).
При использовании в файле layer.conf указывает путь к текущему уровню. Переменная не доступна за пределами layer.conf и ссылки разыменовываются сразу по завершении разбора файла.
Список разделенных пробелами уровней, рекомендованных для использования с данным уровнем. Можно также указывать конкретную версию уровня, добавляя ее в конце имени. Например, LAYERRECOMMENDS_mylayer = “anotherlayer (=3)”, где номер версии 3 уровня anotherlayer сравнивается с LAYERVERSION_anotherlayer. Переменная указывается в файле conf/layer.conf и должна иметь суффикс в виде имени конкретного уровня (например, LAYERRECOMMENDS_mylayer).
Перечисляет версии OpenEmbedded-Core, с которыми совместим уровень. Переменная LAYERSERIES_COMPAT позволяет указать, какие комбинации уровня и OE-Core предполагаются работоспособными. Переменная позволяет системе определить, когда уровень не будет проверяться с новыми выпусками OE-Core (например, не поддерживается).
Для указания версии OE-Core, с которой совместим уровень, используется эта переменная в файле conf/layer.conf. Для указания версии используйте имя выпуска YP (например, warrior). При указании нескольких версий OE-Core для уровня они разделяются пробелами, как показано ниже.
LAYERSERIES_COMPAT_layer_root_name = "warrior thud"
Установка LAYERSERIES_COMPAT требуется стандартом Yocto Project Compatible версии 2. Система сборки OE выдает предупреждения, если переменная не установлена для уровня.
Опционально задает версию уровня одним числом. Можно использовать это значение в LAYERDEPENDS для другого уровня для указания зависимости от конкретной версии уровня. Переменная применяется в файле conf/layer.conf и должна иметь суффикс в виде имени конкретного уровня (например, LAYERVERSION_mylayer).
Сокращенная команда и аргументы для запуска компоновщика.
Задает флаги, передаваемые компоновщику. Переменная экспортируется в окружение и доступна программам, собираемым на этапе компиляции. Принятое по умолчанию значение LDFLAGS зависит от собираемого объекта:
TARGET_LDFLAGSпри сборке для целевой платформы;BUILD_LDFLAGSпри сборке для сборочного хоста (-native);BUILDSDK_LDFLAGSпри сборке для SDK (nativesdk-).
Задает основной (первичный) файл скомпилированной библиотеки (.so), к которому класс debian применяет свои правила именования в образах с множеством библиотек. Переменная применяется с классам debian.
Контрольная сумма текста лицензии в исходном коде задания для отслеживания изменений в тексте. Если текст лицензии будет изменен, это приведет к отказу сборки, указывающему разработчику просмотреть изменение в тексте. Эта переменная должна указываться для всех заданий, кроме тех, где установлено LICENSE = CLOSED. Дополнительную информацию о лицензировании можно найти в разделе Tracking License Changes [2].
Список лицензий для задания в соответствии с приведенными ниже правилами:
- не допускаются пробелы в именах лицензий;
- имена лицензий разделяются символом | при возможности выбора лицензии;
- имена лицензий разделяются символом & (амперсанд) при наличии нескольких лицензий для разных частей кода;
- между именами лицензий можно использовать символы пробела;
- для стандартных лицензий применяются имена из файла
meta/files/common-licenses/или имена флаговSPDXLICENSEMAP,
заданные
в файлеmeta/conf/licenses.conf.
Ниже приведено несколько примеров.
LICENSE = "LGPLv2.1 | GPLv3"
LICENSE = "MPL-1 & LGPLv2.1"
LICENSE = "GPLv2+"
Первый пример взят из заданий для Qt, распространяемых по лицензии LGPL версии 2.1 или GPL версии 3. Во втором примере представлено лицензирование Cairo, где применяются две лицензии для разных частей кода. Последний пример взят из sysstat, где используется одна лицензия.
Можно также задавать лицензии на уровне пакета для случаев использования компонентами разных лицензий. Например, если часть кода распространяется по лицензии GPLv2, но сопровождается документацией, которая использует лицензию GNU FDL7 1.2, можно указать
LICENSE = "GFDL-1.2 & GPLv2"
LICENSE_${PN} = "GPLv2"
LICENSE_${PN}-doc = "GFDL-1.2"
Установка LICENSE_CREATE_PACKAGE = 1 заставляет систему сборки OE создавать дополнительный пакет (${PN}-lic)ого задания и добавлять эти пакеты в переменную RRECOMMENDS_${PN}.
Пакет ${PN}-lic создает каталог /usr/share/licenses с именем ${PN} (базовое имя задания) и помещает в него файлы с лицензией и информацией об авторских правах (т. е. копии подходящих лицензий из meta/common-licenses, соответствующие лицензиям, указанным в переменной LICENSE метаданных задания, и копии файлов, указанных в LIC_FILES_CHKSUM как файлы с текстами лицензий).
Дополнительная информация о предоставлении текстов лицензий приведена в описаниях переменных COPY_LIC_DIRS и COPY_LIC_MANIFEST, а также в разделе Providing License Text [2].
Перечисляет для задания дополнительные флаги, которые следует включить в LICENSE_FLAGS_WHITELIST, чтобы задание можно было собрать. Флаги в списке разделяются пробелами. Это значение не зависит от LICENSE и обычно применяется для маркировки заданий, которым могут требоваться дополнительные лицензии для использования в коммерческой продукции. Дополнительная информация о лицензировании приведена в разделе Enabling Commercially Licensed Recipes [2].
Перечисляет флаги лицензий, которым при указании в LICENSE_FLAGS для задания, не следует препятствовать в сборке. Это иногда называют «белым списком» лицензий. Дополнительная информация о лицензировании приведена в разделе Enabling Commercially Licensed Recipes [2].
Путь к дополнительным лицензиям, используемым при сборке. По умолчанию система сборки OE применяет COMMON_LICENSE_DIR для определения каталога с общим текстом лицензии, используемой при сборке. Эта переменная позволяет добавить каталоги в форме LICENSE_PATH += “path-to-additional-common-licenses“.
Определяет тип ядра, применяемый при сборке конфигурации. В заданиях linux-yocto определены типы standard, tiny и preempt-rt (см. раздел Kernel Types [3]). Если переменная LINUX_KERNEL_TYPE не задана, применяется тип standard. Вместе с переменной KMACHINE значение LINUX_KERNEL_TYPE определяет аргументы поиска, применяемые инструментами ядра при поиске подходящего описания в метаданных ядра для определения исходных файлов и конфигурации.
Версия Linux с сайта kernel.org, для которой будет собираться образ ядра с помощью системы OE. Эта переменная указывается в задании для ядра. Например, задание linux-yocto-3.4.bb из каталога meta/recipes-kernel/linux определяет переменную
LINUX_VERSION ?= "3.4.24"
Значение LINUX_VERSION используется при определении переменной PV для задания
PV = "${LINUX_VERSION}+git${SRCPV}"
Строка расширения, компилируемая в строку версии ядра Linux, собираемого в системе OE. Эта переменная указывается в задании для ядра. Например, задание определяет ее как
LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
Определение этой переменной по существу задает значение конфигурационного параметра ядра CONFIG_LOCALVERSION, которое доступно по команде uname. Ниже приведен пример вывода команды.
$ uname -r
3.7.0-rc8-custom
Задает каталог, в который система сборки OE записывает log-файлы (по умолчанию ${TMPDIR}/log). Каталоги с журналами для каждой задачи задаются с помощью переменной T.
M
Задает целевое устройство, для которого собирается ядро. Переменная указывается в файле local.conf каталога сборки. По умолчанию задан архитектура x86, эмулируемая с помощью QEMU, как MACHINE ?= “qemux86”. Переменная соответствует одноименному файлу конфигурации машины, в котором установлена конфигурация для нее. Таким образом, при установке qemux86 будет в наличии файл qemux86.conf, хранящийся в каталоге исходных кодов (подкаталог meta/conf/machine). Ниже приведен список машин, включенных в дистрибутив YP.
MACHINE ?= "qemuarm"
MACHINE ?= "qemuarm64"
MACHINE ?= "qemumips"
MACHINE ?= "qemumips64"
MACHINE ?= "qemuppc"
MACHINE ?= "qemux86"
MACHINE ?= "qemux86-64"
MACHINE ?= "genericx86"
MACHINE ?= "genericx86-64"
MACHINE ?= "beaglebone"
MACHINE ?= "mpc8315e-rdb"
MACHINE ?= "edgerouter"
Последние 5 ссылок относятся к эталонным платам YP уровня meta-yocto-bsp. Возможна установка в переменной значений, обеспечиваемых дополнительными уровнями BSP.
Задает архитектуру конкретной машины и устанавливается автоматически из переменной MACHINE или TUNE_PKGARCH. Не следует менять значение MACHINE_ARCH
вручную.
MACHINE_ESSENTIAL_EXTRA_RDEPENDS
Зависящий от машины список обязательных пакетов для установки в создаваемый образ. Процесс сборки зависит от наличия этих пакетов. Кроме того, поскольку эти пакеты важны для машины, без них она может не загрузиться. Переменная влияет на образы, основанные на packagegroup-core-boot, включая образ core-image-minimal.
Эта переменная похожа на MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS,
но.
сборка создаваемого образа зависит от
сборки пакетов из списка. При отсутствии
нужных пакетов сборка станет невозможной
В качестве примера рассмотрим машину, для которой нужно во время загрузки запускать пакет example-init для инициализации оборудования. В этом случае файл конфигурации для машины (.conf)
должен включать строку
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "example-init"
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS
Список зависимых от машины пакетов для включения в собираемый образ. Процесс сборки не зависит от наличия этих пакетов. Однако эти пакеты важны для загрузки машины. Переменная влияет на образы, основанные на packagegroup-core-boot, включая образ core-image-minimal.
Эта переменная похожа на MACHINE_ESSENTIAL_EXTRA_RDEPENDS,
но.
сборка образа не зависит от сборки
пакетов из списка, т. е. при отсутствии
пакета образ все равно будет собран.
Обычно эта переменная служит для
управления важными компонентами ядра,
которые могут встраиваться непосредственно
в ядро (не модуль) и тогда пакет создаваться
не будет
Рассмотрим пример с пользовательским ядром, где нужен драйвер для определенного сенсорного экрана, чтобы использовать машину. Драйвер может быть встроен в ядро или собран как модуль в зависимости от конфигурации. При сборке драйвера в виде модуля его нужно установить, но хочется, чтобы сборка выполнялась и для случая встраивания драйвера в ядро. Данная переменная устанавливает отношение «рекомендации» и во втором случае сборка не будет прерываться в случае отсутствия пакета. Для модуля kernel-module-ab123
в файл конфигурации машины включается
строка
В этом примере задание kernel-module-ab123 должно явно установить свою переменную PACKAGES,
чтобы BitBake не использовал переменную
PACKAGES_DYNAMIC из задания ядра для соблюдения зависимости.
Примерами таких устройств являются драйверы флэш-памяти, экрана, клавиатуры, мыши или сенсорного экрана.
Список машинозависимых пакетов для установки в собираемый образ, которые не имеют значения при загрузке машины, но сборка образа зависит от этих пакетов. Переменная влияет лишь на образы, основанные на packagegroup-base, которые не включают core-image-minimal и core-image-full-cmdline. Переменная похожа на MACHINE_EXTRA_RRECOMMENDS, но отличается тем, что сборка образа зависит
от указанных в ней пакетов.
Примером может служить машина с поддержкой WiFi, которая не существенна для загрузки. Однако при сборке более функционального образа может потребоваться WiFi. В этом случае предполагается наличие пакета с микрокодом WiFi, поэтому логична зависимость процесса сборки от наличия этого пакета. Для решения этой задачи (в предположении, что пакет называется wifidriver-firmware) следует включить в файл .conf для машины строку MACHINE_EXTRA_RDEPENDS += “wifidriver-firmware”.
Список машинозависимых пакетов для установки в собираемый образ, которые не имеют значения при загрузке машины и сборка образа не зависит от этих пакетов. Переменная влияет лишь на образы, основанные на packagegroup-base, которые не включают core-image-minimal и core-image-full-cmdline. Переменная похожа на MACHINE_EXTRA_RDEPENDS, но отличается тем, что сборка образа не зависит от указанных в ней пакетов.
Примером может служить машина с поддержкой WiFi, которая не существенна для загрузки. Однако при сборке более функционального образа может потребоваться WiFi. В этом случае пакет с модулем WiFi для ядра не будет создаваться, если драйвер встроен в ядро, но нужно выполнение сборки без ошибок, несмотря на отсутствие пакета. Для решения этой задачи (в предположении, что пакет называется kernel-module-examplewifi) следует включить в файл .conf для машины строку MACHINE_EXTRA_RRECOMMENDS += “kernel-module-examplewifi”.
Задает список аппаратных функций, которые MACHINE может поддерживать. Включение дополнительных свойств управляется переменными DISTRO_FEATURES, COMBINED_FEATURES и IMAGE_FEATURES. Список аппаратных возможностей, поддерживаемых YP, приведен в параграфе 12.1. Свойства машины.
Свойства, добавляемые в MACHINE_FEATURES при их отсутствии в переменной MACHINE_FEATURES_BACKFILL_CONSIDERED. Эта переменная задана в файле meta/conf/bitbake.conf и не предназначена для настройки пользователем. О сослаться на переменную для просмотра функций, «засыпанных» в конфигурации всех машин (см. параграф 12.4. Отключение автоматически добавляемых свойств).
MACHINE_FEATURES_BACKFILL_CONSIDERED
Свойства из MACHINE_FEATURES_BACKFILL, которые не следует добавлять в MACHINE_FEATURES при сборке (см. параграф 12.4. Отключение автоматически добавляемых свойств).
Разделенный двоеточиями список переопределений, применяемых для конкретной машины. По умолчанию этот список включает значение переменной MACHINE.
Переменную MACHINEOVERRIDES можно расширить добавляя переопределения, применяемые к машине. Например, все машины, эмулируемые в QEMU (qemuarm, qemux86 и т. п.), включают файл meta/conf/machine/include/qemu.inc, который добавляет значение в начало переменной MACHINEOVERRIDES =. “qemuall:”. Это позволяет переопределять переменные для всех машин, эмулируемых в QEMU, как показано в примере из задания connman-conf.
SRC_URI_append_qemuall = "file://wired.config \
file://wired-setup \
"
Базовым механизмом для MACHINEOVERRIDES является включение в значение по умолчанию переменной OVERRIDES.
Адрес электронной почты для поддержки дистрибутива.
Задает дополнительные пути для поиска исходных кодов системой сборки OE, которая сначала пытается найти коды в локальном каталоге загрузки. При отсутствии кодов в этом каталоге система просматривает репозитории, указанные переменной PREMIRRORS, затем «восходящий источник» и репозитории, указанные переменной MIRRORS. В дистрибутиве (DISTRO) poky принятое по умолчанию значение MIRRORS указано в файле conf/distro/poky.conf репозитория meta-poky.
Задает префикс, добавляемый к переменной PN для получения специальной версии задания или пакета (версии Multilib). Переменная применяется там, где нужно добавить или удалить префикс переменной (например, BPN). MLPREFIX устанавливается при наличии префикса у переменной PN.
ML в имени MLPREFIX означает MultiLib. Это возникло в то время, когда строка nativesdk служила суффиксом, а не префиксом имени задания. Префикс nativesdk учитывается в MLPREFIX.
Для разъяснения случаев применения MLPREFIX рассмотрим пример с использованием BBCLASSEXTEND для обеспечения версии задания nativesdk в дополнении к версии для целевой платформы. Если это задание заявляет зависимость при сборке от других заданий с помощью переменной DEPENDS, то зависимость от foo будет автоматически переопределяться в зависимость от nativesdk-foo. Однако зависимости вида do_foo[depends] += “recipe:do_foo” не будут переопределяться автоматически. Если нужно переопределение таких зависимостей, можно указать do_foo[depends] += “${MLPREFIX}recipe:do_foo”.
Переменная заменена KERNEL_MODULE_AUTOLOAD,
поэтому
следует отредактировать
всеmodule_autoload_rfcomm = “rfcomm” заменить на KERNEL_MODULE_AUTOLOAD += “rfcomm”.
файлы, включающие ее. Например,
Задает строки с синтаксисом modprobe.d для включения в файл /etc/modprobe.d/modname.conf. Эту переменную можно использовать в любом месте, доступном заданию для ядра или внешнего (out-of-tree) модуля (например, в файле конфигурации машины или дистрибутива, файле дополнения к заданию или самом задании). При использовании переменной нужно также перечислить модули ядра в переменной KERNEL_MODULE_AUTOLOAD.
Базовый синтаксис переменной имеет вид module_conf_module_name = “modprobe.d-syntax“. Нужно применять переопределение имен модулей ядра.
Включение module_conf заставляет систему сборки OE заполнять файл /etc/modprobe.d/modname.conf строками с синтаксисом modprobe.d (информацию о синтаксисе можно). Например, добавление опций
получить по команде man modprobe.darg1 и arg2 для модуля mymodule
можетmodule_conf_mymodule = “options mymodule arg1=val1 arg2=val2”.
иметь вид
Автоматическая загрузка модулей ядра управляется переменной KERNEL_MODULE_AUTOLOAD.
Управляет созданием файла modules-*.tgz
с
модулями ядра, созданными
при сборке (0 отменяет запись архива).
Имя ссылки для архива модулей ядра, устанавливаемое в файле meta/classes/kernel-artifact-names.bbclass как MODULE_TARBALL_LINK_NAME ?= “${KERNEL_ARTIFACT_LINK_NAME}”. Для KERNEL_ARTIFACT_LINK_NAME
вKERNEL_ARTIFACT_LINK_NAME ?= “${MACHINE}”
том же файле устанавливается значение
Базовое имя архива модулей ядра, устанавливаемое в файле meta/classes/kernel-artifact-names.bbclass
какMODULE_TARBALL_NAME ?= “${KERNEL_ARTIFACT_NAME}”. Переменная
KERNEL_ARTIFACT_NAME в том же файле получает значение KERNEL_ARTIFACT_NAME ?= “${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}”.
Однозначно указывает тип целевой системы, для которой собираются пакеты. Переменная позволяет размещать вывод для разных целевых систем в разные подкаталоги одного выходного каталога. По умолчанию переменная имеет значение ${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}. Некоторые классы (например, cross-canadian) меняют значение MULTIMACH_TARGET_SYS. Дополнительная информация приведена в описаниях переменных STAMP и STAGING_DIR_TARGET.
N
Строка, указывающая дистрибутив хоста. Строка включает идентификатор дистрибутива, за которым следует номер выпуска, возвращаемый командой lsb_release или прочитанный в файле /etc/lsb-release. Например, при работе на хосте Ubuntu 12.10 переменная будет иметь значение Ubuntu-12.10. Если дистрибутив определить не удается, переменная получает значение Unknown.
Переменная используется по умолчанию для разделения естественных пакетов разных дистрибутивов (например, для предотвращения проблем, связанный с несовместимостью версий glibc). Кроме того, эта переменная проверяется по SANITY_TESTED_DISTROS,
если.
та установлена
Сокращенная команда и аргументы для запуска nm
(просмотр
символов.
из объектных файлов)
Предотвращает ошибки QA при использовании в задании необычной, незакрытой лицензии. Имеются пакеты, такие как linux-firmware, со множеством мало распространенных лицензий. Время от времени также появляются новые лицензии, чтобы избежать введения множества базовых лицензий, которые применимы к конкретному пакету. Переменная NO_GENERIC_LICENSE позволяет скопировать лицензию, которой нет в числе базовых. Например, в задание можно добавить лицензию NO_GENERIC_LICENSE to с помощью NO_GENERIC_LICENSE[license_name] = “license_file_in_fetched_source“. В приведенном ниже примере используется файл LICENSE.Abilis.txt file в качестве лицензии для извлеченного исходного кода.
NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"
Предотвращает установку пакетов, которые лишь рекомендованы (устанавливаются через переменную RRECOMMENDS). Например, NO_RECOMMENDATIONS = “1” включает эту функцию.
Переменную можно установить глобально в файле local.conf или присоединить к заданию для конкретного образа, переопределяя имя задания в виде NO_RECOMMENDATIONS_pn-target_image = “1”.
Важно понимать, что при включении в эту переменную пакетов, от которых зависят другие пакеты (указаны в переменной RDEPENDS), система сборки OE будет игнорировать запрос и установит пакеты, чтобы не нарушать зависимостей.
Некоторые рекомендованные пакеты могут потребоваться для некоторых функций, таких как модули ядра. Вы можете указать такие пакеты в переменной IMAGE_INSTALL.
Переменная поддерживается только при наличии менеджеров пакетов IPK и RPM, но не поддерживается для DEB.
См. также описания переменных BAD_RECOMMENDATIONS и PACKAGE_EXCLUDE.
Выключает автоматическое выделение для пакета файлов .debug. Если задание требует установки FILES_${PN}-dbg вручную, можно задать переменную NOAUTOPACKAGEDEBUG,
позволяющую
определить содержимое отладочного
пакета. Например,
NOAUTOPACKAGEDEBUG = "1"
FILES_${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*"
FILES_${PN}-dbg = "/usr/src/debug/"
FILES_${QT_BASE_NAME}-demos-doc = "${docdir}/${QT_DIR_NAME}/qch/qt.qch"
2Package Management System – система управления пакетами.
3Position Independent Executables – независимые от расположения исполняемые файлы.
4Return Oriented Programming – ориентированное на возвращаемое значение программирование.
5GNU GRand Unified Bootloader.
6Device tree binary.
7Free Documentation License – свободное распространение документации.