Справочник по Yocto Project (часть 3)

Часть 2


Глава 13. Переменные

В этой главе перечислены и описаны основные переменные, используемые системой сборки OE.

A

ABIEXTENSION

Расширение поля ABI1 канонического имени GNU для архитектуры (например, «eabi»). Расширения ABI задаются во включаемых файлах для машин. Например, файл meta/conf/machine/include/arm/arch-arm.inc задает расширение ABIEXTENSION = «eabi».

ALLOW_EMPTY

Задает необходимость создания на выходе пустых пакетов, которые BitBake по умолчанию не создает. Принятое по умолчанию поведение может создавать проблемы в тех случаях, когда RDEPENDS или другое жесткое требование во время работы указывает необходимость пакета.

Как и в других переменных управления пакетами требуется суффикс в виде имени пакета, как показано ниже.

     ALLOW_EMPTY_${PN} = "1"
     ALLOW_EMPTY_${PN}-dev = "1"
     ALLOW_EMPTY_${PN}-staticdev = "1"   

ALTERNATIVE

Перечисляет команды в пакете, которым нужна схема вариативного именования. Иногда одна команда предоставляется несколькими пакетами и в таких случаях системе сборки OE приходиться использовать систему вариантов для создания разных имен двоичных файлов, чтобы команды могли существовать совместно.

При использовании этой переменной указывается список команд пакета, которые применяются также в другом пакете, как показано ниже. Например, если пакет busybox имеет 4 таких команды, можно указать ALTERNATIVE_busybox = «sh sed test bracket». Дополнительная информация о вариантах именования приведена в параграфе 6.141. update-alternatives.bbclass.

ALTERNATIVE_LINK_NAME

Применяется системой вариантов (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).

ALTERNATIVE_PRIORITY

Применяется системой вариантов для установки приоритата дублированных команд. Переменная позволяет создать единственный принятый по умолчанию вариант, независимо от команды или пакета, а также принятые по умолчанию варианты для конкретных пакетов (6.141. update-alternatives.bbclass). Варианты синтаксиса даны ниже.

ALTERNATIVE_PRIORITY = "priority" ALTERNATIVE_PRIORITY[name] = "priority" ALTERNATIVE_PRIORITY_pkg[name] = "priority"

ALTERNATIVE_TARGET

Применяется системой вариантов для создания используемого по умолчанию местоположения для дубликатов команд. Переменная позволяет создать единственный принятый по умолчанию вариант, независимо от команды или пакета, а также принятые по умолчанию варианты для конкретных пакетов (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,
сохраняя
при необходимости поддержку команды
.

APPEND

Переопределяет список добавленных строк для каждой цели, указанной с LABELS
спользование переменной рассмотрено в описании класса grub-efi).

AR

Сокращенная команда и аргументы для работы ar.

ARCHIVER_MODE

При использовании с классом 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 дерева исходных кодов.

AS

Сокращенная команда и аргументы для работы ассемблера.

ASSUME_PROVIDED

Список имен заданий (PN values), которые BitBake не будет пытаться собрать, предполагая, что они уже собраны. В OpenEmbedded-Core переменная ASSUME_PROVIDED задает естественные инструменты, которые не нужно собирать. Примером служит задание git-native, его указание позволяет применять Git хоста без сборки git-native.

ASSUME_SHLIBS

Предоставляет дополнительные данные о провайдере общих библиотек, которые дополняют или переопределяют информацию, автоматически предоставляемую системой. Элементы разделяются пробелами.

Например, приведенная ниже форма добавляет провайдера shlib с именем shlibname в packagename с необязвтельным указанием версии.

shlibname:packagename[_version]

Следующий пример добавляет общую библиотеку libEGL.so.1 как предоставляемую пакетом libegl-implementation.

     ASSUME_SHLIBS = "libEGL.so.1:libegl-implementation"

AUTHOR

Почтовый адрес для контактов с исходным автором или авторами для передачи правок и сообщений об ошибках.

AUTO_LIBNAME_PKGS

При наследовании класса debian
(принято по умолчанию) переменная задает пакеты, которые следует проверять на предмет библиотек и переименовывать в соответствии с правилами Debian. По умолчанию принято значение ${PACKAGES}, которое включает класс debian для всех пакетов, явно создаваемых заданием.

AUTO_SYSLINUXMENU

Включает создание автоматического меню для загрузчика syslinux. Переменная должна устанавливаться в задании, класс syslinux проверяет ее.

AUTOREV

Когда для переменной 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

B

Каталог внутри каталога сборки, куда система сборки OE помещает объекты, созданные в процессе сборки задания. По умолчанию этот каталог совпадает с каталогом S,
определяемым
как

     S = "${WORKDIR}/${BP}"

Можно разделить каталог S
и
каталог, указанный переменной
B. Большинство заданий, применяющих автоматические инструменты поддерживают такое разделение. По умолчанию система сборки использует отдельные каталоги для gcc и некоторых заданий для ядра.

BAD_RECOMMENDATIONS

Перечисляет «лишь рекомендуемые» (recommended-only) пакеты, которые не устанавливаются. К таким пакетам относятся указанные через переменную RRECOMMENDS. Можно предотвратить установку любого из таких пакетов, указав его в переменной BAD_RECOMMENDATIONS.

BAD_RECOMMENDATIONS = "package_name package_name package_name ..."

Эту переменную можно задать глобально в файле local.conf или присоединить к заданию для конкретного образа, используя переопределение имени задания, как показано ниже.

BAD_RECOMMENDATIONS_pn-target_image = "package_name"

Важно отметить, что при отказе от установки пакетов с помощью этой переменной и наличии зависимости от них других пакетов (указанных в переменной RDEPENDS для задания), система сборки OE будет игнорировать запрос и установит пакеты для предотвращения нарушений в зависимостях.

Переменная поддерживается только при наличии менеджеров пакетов IPK и RPM, но не поддерживается для DEB.

См. также описания переменных NO_RECOMMENDATIONS и PACKAGE_EXCLUDE.

BASE_LIB

Имя каталоги библиотек для настройки CPU или ABI, которое применяется лишь в контексте Multilib (см. раздел Combining Multiple Versions of Library Files into One Image [2]). Переменная определяется во включаемых файлах машины в дереве исходного кода. Если Multilib не используется, переменная имеет значение lib.

BASE_WORKDIR

Задает базу для сетевого каталога, применяемого во всех задания (по умолчанию ${TMPDIR}/work).

BB_ALLOWED_NETWORKS

Задает список разделенных пробелами хостов, которые сборщику разрешено использовать для получения нужных исходных кодов. Ниже рассмотрены некоторые аспекты использования этой переменной.

  • Список хостов применяется лишь в при установке 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.

BB_DANGLINGAPPENDS_WARNONLY

Определяет обработку в BitBake ситуаций, когда файл дополнения (.bbappend) не имеет соответствующего задания (.bb). Такое часто возникает при рассинхронизации уровней (например, oe-core нужно задания, для которого старой версии уже нет, а другой уровень еще не обновлен с новой версией задания). По умолчанию в такой ситуации возникает критическая ошибка и это обеспечивает наиболее безопасный вариант. Поведение можно изменить указав для переменной BB_DANGLINGAPPENDS_WARNONLY значение «1», «yes» или «true» в файле local.conf каталога сборки.

BB_DISKMON_DIRS

Отслеживает доступное пространство и 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 Кбайт без отслеживания свободного места в каталоге.

BB_DISKMON_WARNINTERVAL

Задает интервал предупреждений о нехватке места на диске и свободных 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 Кбайт.

BB_GENERATE_MIRROR_TARBALLS

Заставляет систему сборки размещать архивы репозиториев исходного кода (например, Git), включая метаданные, в каталоге DL_DIR. Для повышения производительности система сборки OE п умолчанию не сохраняет такие архивы.

Переменная устанавливается в файле local.conf каталога сборки.

BB_NUMBER_THREADS

Максимальное число задач, которые BitBake следует запускать параллельно. Система сборки OE автоматически устанавливает для этой переменной число ядре на хосте сборки. Например, в системе с 2-ядерным процессором и поддержной hyper-threading по умолчанию задается BB_NUMBER_THREADS = «4». Для 1-процессорных систем не следует переопределять эту переменную. Оптимизация скорости сборки описана в Speeding Up a Build [2].

BB_SERVER_TIMEOUT

Указывает время (в секундах), по истечение которого сервер BitBake выключается при отсутствии активности. Например, в файле local.conf можно указать 20-секундное ожидание в виде BB_SERVER_TIMEOUT = «20». Для постоянной работы сервера следует установить BB_SERVER_TIMEOUT = «-1».

BBCLASSEXTEND

Позволяет расширить задание для сборки вариантов программ. Существуют распространенные варианты заданий, такие как «естественные» (например, 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_COLLECTIONS

Список имен настроенных уровней, используемых для поиска других переменных BBFILE_*. Обычно каждый уровень добавляет свое имя в конце этой переменной в своем файле conf/layer.conf.

BBFILE_PATTERN

Переменная, которая преобразуется для сопоставления с файлами из переменной BBFILES в определенном слое. Эта переменная используется в файле conf/layer.conf и должна иметь суффикс с именем конкретного слоя (например, BBFILE_PATTERN_emenlow).

BBFILE_PRIORITY

Задает уровень приоритета для файлов заданий уровня. Эта переменная полезна в случаях, когда одноименные задания указаны в разных уровнях. Установка переменной позволяет задать приоритет заданий своего уровня, позволяя сделать его предпочтительным по сравнению с другими. Предпочтения, задаваемые этой переменной взаимодействуют с версиями заданий (переменная PV). Например, уровень, имеющий задание с более высоким значением PV,
может иметь меньшее значение BBFILE_PRIORITY
и быть менее предпочтительным.

Большее значение BBFILE_PRIORITY означате более высокий приоритет. Если переменная не задана, ее значение устанавливается на основе зависимостей уровня (см. LAYERDEPENDS). Если уровень не имеет зависимостей и приоритет не задан, определяется минимальным заданным приоритетом + 1 (т. е. 1, если приоритет не задан).

С помощью команды bitbake-layers
show-layers
можно посмотреть все настроенные уровни с их приоритетами.

BBFILES

Разделенный пробелами список файлов заданий, который BitBake использует для сборки программ. При указании файлов заданий можно применять синтаксис Python glob.

BBFILES_DYNAMIC

Активирует содержимое при наличии идентифицированных уровней, которые задаются коллекциями, определенными в них. Переменная используется для исключения файлов .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

BBINCLUDELOGS

Управляет отображением журнала сборки программой BitBake при возникновении отказов.

BBINCLUDELOGS_LINES

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

BBLAYERS

Список уровней, включаемых в сборку. Переменная указывается в файле 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)
является пользовательским
.

BBMASK

Управляет исключением файлов заданий и дополнений из обработки 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"

Для исключения каталога следует указывать символ / в конце имени.

BBMULTICONFIG

Позволяет 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].

BBPATH

Применяется BitBake для поиска файлов .bbclass и файлов конфигурации подобно системной переменной PATH.

При использовании BitBake извне каталога сборки нужно обеспечить, чтобы переменная BBPATH указывала сборочный каталог. Установка выполняется так же, как для других переменных среды и переменная должна быть задана до начала работы BitBake.

$ BBPATH = "build_directory" $ export BBPATH $ bitbake target

BBSERVER

При определении в среде BitBake переменная BBSERVER указывает удаленный сервер BitBake. Переменная экспортируется в среду BitBake как показано ниже.

     export BBSERVER=localhost:$port"

По умолчанию BBSERVER присутствует также в BB_HASHBASE_WHITELIST,
поэтому
переменная
BBSERVER исключена из расчета контрольной суммы и данных зависимостей.

BINCONFIG

При наследовании класса binconfig-disabled эта переменная указывает двоичные сценарии настройки, которые следует отключить в пользу запроса информации с помощью pkg-config. Класс binconfig-disabled будет изменять указанные сценарии для возврата ошибки, позволяющего найти и заменить вызовы таких сценариев. При добавлении нескольких сценариев они разделяются пробелами, как показано ниже для задания libpng.

     BINCONFIG = "${bindir}/libpng-config ${bindir}/libpng16-config"

BINCONFIG_GLOB

При наследовании класса binconfig эта переменная задает шаблон для сценариев конфигурации, которые нужно редактировать. При редактировании изменяются пути, заданные во время компиляции, чтобы они были пригодны для установки в sysroot и могли использоваться процессами сборки других заданий. Переменная использует шаблоны оболочки при сопоставлении имен, похожие на fnmatch и glob. Информацию о работе переменной можно найти в файле meta/classes/binconfig.bbclass дерева исходных кодов, а также в параграфе 6.7. binconfig.bbclass.

BP

Базовое имя и версия задания без дополнительных суффиксов (-native, lib64-
и
т. п.).
BP имеет вид ${BPN}-${PV}.

BPN

Это вариант переменной PN с удаленными общими префиксами и суффиксами, такими как nativesdk-, -cross, -native, а также lib64- и lib32-. Точный список удаляемых префиксов и суффиксов задается переменными MLPREFIX и SPECIAL_PKGSUFFIX.

BUGTRACKER

Задает идентификатор URL сайта отслеживания ошибок для задания. Система сборки OE не использует эту переменную, она служит лишь указателем для разработчиков в случае необходимости сообщить об ошибке.

BUILD_ARCH

Указывает архитектуру хоста сборки (например, i686). Сиситема сборки OE устанавливает переменную по выводу команды uname.

BUILD_AS_ARCH

Задает зависящие от архитектуры флаги ассемблера для хоста сборки (по умолчанию «»).

BUILD_CC_ARCH

Задает зависящие от архитектуры флаги компилятора C для хоста сборки (по умолчанию «»).

BUILD_CCLD

Задает команду компоновки, используемую хостом сборки в случае применения для компоновки компилятора C. По умолчанию BUILD_CCLD указывает GCC и передает в качестве аргумента значение BUILD_CC_ARCH.

BUILD_CFLAGS

Задает флаги, передаваемые компилятору C при сборке для сборочного хоста. При сборке в контексте -native
по умолчанию используется значение CFLAGS.

BUILD_CPPFLAGS

Задает флаги, передаваемые препроцессору C (т. е. компиляторам C и C++). При сборке в контексте -native
по умолчанию используется значение CPPFLAGS.

BUILD_CXXFLAGS

Задает флаги, передаваемые компилятору C++ при сборке для сборочного хоста. При сборке в контексте -native
по умолчанию используется значение CXXFLAGS.

BUILD_FC

Задает флаги, передаваемые компилятору Fortran для хоста сборки. По умочанию переменная указывает Gfortran и передает значение BUILD_CC_ARCH.

BUILD_LD

Задает флаги команду компоновщика для хоста сборки. По умочанию переменная указывает компоновщик GNU (ld) и передает значение BUILD_LD_ARCH.

BUILD_LD_ARCH

Задает зависящие от архитектуры флаги компоновщика для хоста сборки (по умолчанию «»).

BUILD_LDFLAGS

Задает флаги, передаваемые компоновщику при сборке для сборочного хоста. При сборке в контексте -native
по умолчанию используется значение LDFLAGS.

BUILD_OPTIMIZATION

Задает флаги оптимизации, передаваемые компилятору C при сборке для сборочного хоста или SDK через заданные по умолчанию значения переменных BUILD_CFLAGS и BUILDSDK_CFLAGS. По умолчанию переменная BUILD_OPTIMIZATION имеет значение -O2 -pipe.

BUILD_OS

Указывает операционную систему сборочного хоста (например, linux). Система сборки OE устанавливает переменную по первому слову вывода команды uname,
преобразованному
в нижний регистр.

BUILD_PREFIX

Префикс двоичного файла инструментария для естественных заданий. Система сборки OE использует значение переменной TARGET_PREFIX при сборке ествественных заданий.

BUILD_STRIP

Указывает команду для вырезания отладочных символов из файлов, созданных для сборочного хоста (по умолчанию ${BUILD_PREFIX}strip).

BUILD_SYS

Задает систему (включая архитектуру и ОС), используемую при сборке для сборочного хоста (задания native). Система сборки OE автоматически назначает эту переменную на основе значений BUILD_ARCH, BUILD_VENDOR и BUILD_OS
то значение не требуется менять).

BUILD_VENDOR

Задает имя производителя для использования при сборке для сборочного хоста (по умолчанию «»).

BUILDDIR

Указывает местоположение каталога сборки, который можно задать опосредованно через сценарий oe-init-build-env,
указав
путь в команде запуска сценария
. Если сценарий запущен без указания каталога сборки, по умолчанию BUILDDIR будет применять текущий каталог.

BUILDHISTORY_COMMIT

При наследовании класса buildhistory управляет фиксацией вывода истории сборки в локальном репозитории Git. При значении 1 этот локальный репозиторий будет поддерживаться автоматически классом buildhistory с фиксацией при каждой сборке изменений в каждом каталоге верхнего уровня вывода истории сборки (images, packages, sdk). Это позволяет отслеживать историю сборки. По умолчанию класс buildhistory не фиксирует вывод истории сборки в локальном репозитории Git, т. е. BUILDHISTORY_COMMIT ?= «0».

BUILDHISTORY_COMMIT_AUTHOR

При наследовании класса buildhistory
указывает
автора для каждой фиксации
Git. Чтобы переменная работала, нужно установить BUILDHISTORY_COMMIT = «1». Git требует в переменной BUILDHISTORY_COMMIT_AUTHOR
значение
в формате
email@host. Использование недействительного адреса или хоста не ведет к ошибке. По умолчанию класс buildhistory задает BUILDHISTORY_COMMIT_AUTHOR ?= «buildhistory <buildhistory@${DISTRO}>»

BUILDHISTORY_DIR

При наследовании класса buildhistory эта переменная задает каталог для хранения данных истории сборки. По умолчанию устанавливается BUILDHISTORY_DIR ?= «${TOPDIR}/buildhistory».

BUILDHISTORY_FEATURES

При наследовании класса buildhistory эта переменная задает включенные функции истории сборки (см. Maintaining Build Output Quality [2]). Свойства указываются в форме разделенного пробелами списка элементов:

  • imageанализ содержимого образов, включая список установленных пакетов;
  • packageанализ содержимого отдельных пакетов;
  • sdkанализ содержимого SDK;
  • taskсохранение подписей выходных файлов задач sstate (по одному файлу на задачу с контрольной суммой SHA-256 для каждого подготовленного файла).

По умолчанию класс buildhistory устанавливает BUILDHISTORY_FEATURES ?= «image package sdk».

BUILDHISTORY_IMAGE_FILES

При наследовании класса buildhistory переменная задает список путей к файлам, копируемым из образа в каталог истории сборки каталога image-files в каталоге для образа, чтобы можно было отследить содержимое каждого файла. По умолчанию копируются /etc/passwd и /etc/group, что позволяет контролировать изменения пользователей и групп. Можно включить в список любой файл. Задание некорректного пути в переменной не ведет к ошибке, поэтому можно указать даже не всегда присутствующие файлы. По умолчанию класс buildhistory устанавливает BUILDHISTORY_IMAGE_FILES ?= «/etc/passwd /etc/group».

BUILDHISTORY_PUSH_REPO

При наследовании класса buildhistory переменная может задавать удаленный репозиторий, в который история сборки выталкивает (push) изменения Git. Для работы переменной BUILDHISTORY_PUSH_REPO нужно установить BUILDHISTORY_COMMIT = «1». Репозиторий должен соответствовать заданному удаленному адресу, понятному Git, или удаленному имени, установленному вручную с использованием git
remote
в локальном репозитории. По умолчанию класс buildhistory устанавливает BUILDHISTORY_PUSH_REPO ?= «».

BUILDSDK_CFLAGS

Указывает флаги для передачи компилятору C при сборке для SDK. При сборке в контексте nativesdk- переменная CFLAGS получает значение этой переменной по умолчанию.

BUILDSDK_CPPFLAGS

Указывает флаги для передачи препроцессору C (для компиляторов C и C++) при сборке для SDK. При сборке в контексте nativesdk- переменная CPPFLAGS
получает
значение этой переменной по умолчанию
.

BUILDSDK_CXXFLAGS

Указывает флаги для передачи компилятору C++ при сборке для SDK. При сборке в контексте nativesdk- переменная CXXFLAGS получает значение этой переменной по умолчанию.

BUILDSDK_LDFLAGS

Указывает флаги для передачи компоновщику при сборке для SDK. При сборке в контексте nativesdk- переменная LDFLAGS получает значение этой переменной по умолчанию.

BUILDSTATS_BASE

Указывает местоположение каталога со статистикой сборки при включенном и используемом классе buildstats. По умолчанию BUILDSTATS_BASE имеет значение ${TMPDIR}/buildstats/.

BUSYBOX_SPLIT_SUID

Управляет для задания BusyBox расщеплением выходного файла на 2 части, одна из который выполняет функции, требующие setuid
root
, а другая делает все остальное (где не требуется setuid
root
).

BUSYBOX_SPLIT_SUID по умолчанию имеет значение 1, обеспечивающее на выходе два исполняемых файла. Установка значения 0 отменяет расщепление выходного файла.

C

CACHE

Задает каталог, используемый BitBake для хранения кэшированных метаданных чтобы не анализировать их при каждом запуске BitBake.

CC

Сокращенная команда и аргументы для запуска компилятора C.

CFLAGS

Задает флаги для передачи компилятору C. Переменная экспортируется в окружение и доступна программам, собираемым на этапе компиляции. Принятая по умолчанию инициализация CFLAGS зависит от собираемого объекта:

  • TARGET_CFLAGS при сборке для целевой платформы;
  • BUILD_CFLAGS при сборке для сборочного хоста (-native);
  • BUILDSDK_CFLAGS при сборке для SDK (nativesdk-).

CLASSOVERRIDE

Внутренняя переменная, задающая переопределение класса, который следует применять (например, 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.

CLEANBROKEN

При установке в задании значения 1 для этой переменной команда make
clean
не будет работать для собираемой программы, поэтому система сборки OE не будет пытаться запустить ее при выполнении задачи do_configure.

COMBINED_FEATURES

Указывает список аппаратных свойств, включенных в MACHINE_FEATURES и DISTRO_FEATURES. Это определяет список свойств, которыми имеет смысл управлять на уровне конфигурации машины и дистрибутива. Например, свойство bluetooth требует аппаратной поддержки, но является также опцией дистрибутива.

COMMON_LICENSE_DIR

Указывает каталог meta/files/common-licenses в дереве исходных кодов, где хранятся файлы базовых лицензий.

COMPATIBLE_HOST

Регулярное выражение, указывающее один или несколько хостов (естественное задание) или целей (неестественное задание), с которыми задание совместимо. Выражение сопоставляется с HOST_SYS. Переменную можно использовать для предотвращения сборки заданий для несовместиых классов систем. Особенно полезно это при сборке ядер. Переменная также помогает ускорить синтаксический анализ, поскольку система сборки будет пропускать несовместимые задания.

COMPATIBLE_MACHINE

Регулярное выражение, указывающее одну или несколько целевых машин, совместимых с заданием. Выражение сравнивается с MACHINEOVERRIDES. Можно использовать эту переменню для предотвращения сборки кода для машин, которые не совместимы с заданием. Особенно полезно это при сборке ядер. Переменная также помогает повысить скорость анализа, поскольку система сборки будет пропускать несовместимые с машиной задания.

COMPLEMENTARY_GLOB

Задает шаблоны сопоставления при установке списка дополнительных пакетов для всех пакетов, явно или неявно включенных в образ. Переменная использует шаблоны соответствия имен Unix (fnmatch), похожие на шаблоны преобразования путей Unix (glob).

Результирующий список пакетов связан с элементом, который может быть добавлен в IMAGE_FEATURES.Примером может служить элемент dev-pkgs при добавлении которого в IMAGE_FEATURES будут устанавливаться пакеты -dev (заголовки и другие файлы для разработки) для каждого пакета в образе.

Для добавления указанного шаблоном свойства служит флаг переменной и значение шаблона, например, COMPLEMENTARY_GLOB[dev-pkgs] = ‘*-dev’.

COMPONENTS_DIR

Сохраняет компоненты sysroot для каждого задания. Система сборки OE использует переменную при создании зависимых от задания каталогов sysroot для других заданий. По умолчанию установлено «${STAGING_DIR}-components» (т. е. «${TMPDIR}/sysroots-components«).

CONF_VERSION

Отслеживает версию файла local.conf. Значение увеличивается при каждом изменении совместимости build/conf/.

CONFFILES

Указывает редактируемые или настраиваемые файлы в пакете. Если система 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 в дереве исходных кодов.

CONFIG_INITRAMFS_SOURCE

Задает файлы для 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].

CONFIG_SITE

Список файлов, содержащих результаты теста autoconf,
относящиеся
к текущей сборке. Переменная используется
утилитами
Autotools при настройке конфигурации (configure).

CONFIGURE_FLAGS

Минимальные аргументы для GNU configure.

CONFLICT_DISTRO_FEATURES

При наследовании класса distro_features_check эта переменная указывает свойства дистрибутива, которые будут вызывать конфликты при сборке образа. Иными словами, при включении свойства в CONFLICT_DISTRO_FEATURES и DISTRO_FEATURES в одной конфигурации будет возникать ошибка.

COPYLEFT_LICENSE_EXCLUDE

Список разделенных пробелами лицензий для исключения источников, архивируемых классом archiver.
Если
лицензия из переменной
LICENSE включена в COPYLEFT_LICENSE_EXCLUDE,
ее
источник не будет архивироваться
.
Переменная
имеет более высокий приоритет по
сравнению с
COPYLEFT_LICENSE_INCLUDE.

Принятое по умолчанию значение «CLOSED Proprietary» устанавливается классом copyleft_filter, котрый наследуется классом archiver.

COPYLEFT_LICENSE_INCLUDE

Список разделенных пробелами лицензий для включения источников, архивируемых классом archiver.
Если
лицензия из переменной
LICENSE включена в COPYLEFT_LICENSE_INCLUDE, ее источник будет архивироваться. Принятое по умолчанию значение задается классом copyleft_filter, наследуемым классом archiver,
и
содержит
GPL*, LGPL* и AGPL*.

COPYLEFT_PN_EXCLUDE

Список заданий для исключения источников, архивируемых классом archiver. Переменная переопределяет включение и исключение лицензий через COPYLEFT_LICENSE_INCLUDE и COPYLEFT_LICENSE_EXCLUDE. Принятое по умолчанию значение «» указывает отсутствие явного исключения заданий и устанавливается классом copyleft_filter, который наследуется классом archiver.

COPYLEFT_PN_INCLUDE

Список заданий для включения источников, архивируемых классом archiver. Переменная переопределяет включение и исключение лицензий через COPYLEFT_LICENSE_INCLUDE и COPYLEFT_LICENSE_EXCLUDE. Принятое по умолчанию значение «» указывает отсутствие явного включения заданий и устанавливается классом copyleft_filter, который наследуется классом archiver.

COPYLEFT_RECIPE_TYPES

Список разделенных пробелами типов заданий для включения в архив исходных кодов, создаваемый классом archiver. Задания могут иметь тип target, native, nativesdk, cross, crosssdk
и
cross-canadian. По умолчанию применяется тип target* и для COPYLEFT_RECIPE_TYPES оно устанавливается классом copyleft_filter,
который
наследуется классом
archiver.

COPY_LIC_DIRS

При установке значения 1 для этой переменной и COPY_LIC_MANIFEST система сборки OE копирует в образ файлы лицензий из каталога /usr/share/common-licenses
для
каждого пакета
. Файлы лицензий помещаются в образ при его сборке.

COPY_LIC_DIRS не предлагает путь добавления лицензий для вновь устанавливаемых пакетов в образах с файловой системой read-only, которая не разрешает запись (см. описание LICENSE_CREATE_PACKAGE).
Дополнительная информация о предоставлении
текстов лицензий приведена в разделе
Providing License Text [2].

COPY_LIC_MANIFEST

При установке значения 1 система сборки OE копирует манифест лицензии в файл образа /usr/share/common-licenses/license.manifest в процессе сборки.

COPY_LIC_MANIFEST не предлагает для вновь устанавливаемых в образ пакетов путь добавления лицензий, который может лучше подходить для файловых систем без возможности записи read-only), не позволяющих вносить изменения (см. описание переменной LICENSE_CREATE_PACKAGE).
Сведения о предоставлении текстов
лицензий приведены также в разделе
Providing License Text [2].

CORE_IMAGE_EXTRA_INSTALL

Задает список пакетов для добавления в образ. Переменную следует включать лишь в файл local.conf каталога сборки. Эта переменная заменила ранее применявшуюся переменную POKY_EXTRA_INSTALL.

COREBASE

Задает родительский каталог уровня метаданных OpenEmbedded-Core (meta).

COREBASE_FILES

Список файлов из каталога COREBASE,
которые
следует скопировать, если они не относятся
к уровням, указанным в
bblayers.conf. Переменная предназначена для копирования метаданных из системы сборки OE в расширяемый SDK. Явное указание копируемых файлов из COREBASE требуется потому, что этот каталог обычно содержит каталоги сборки и другие файлы, которые не нужны в eSDK.

CPP

Сокращенная команда и аргументы для запуска препроцессора C.

CPPFLAGS

Задает флаги для передачи препроцессору C (для компиляторов C и C++). Переменная экспортируется в окружение и доступна программам, собираемым на этапе компиляции. Принятая по умолчанию инициализация CPPFLAGS зависит от собираемого объекта:

  • TARGET_CPPFLAGS при сборке для целевой платформы;
  • BUILD_CPPFLAGS при сборке для сборочного хоста (-native);
  • BUILDSDK_CPPFLAGS при сборке для SDK (nativesdk-).

CROSS_COMPILE

Префикс двоичных файлов инструментария для целевой платформы (совпадает со значением TARGET_PREFIX). Система сборки OE устанавливает CROSS_COMPILE
лишь в определенном контексте (например, при сборке заданий для ядра или модулей ядра).

CVSDIR

Каталог для хранения файлов, выбранных в системе CVS.

CXX

Сокращенная команда и аргументы для запуска компилятора C++.

CXXFLAGS

Задает флаги для передачи компилятору C++. Переменная экспортируется в окружение и доступна программам, собираемым на этапе компиляции. Принятая по умолчанию инициализация CXXFLAGS зависит от собираемого объекта:

  • TARGET_CXXFLAGS при сборке для целевой платформы;
  • BUILD_CXXFLAGS при сборке для сборочного хоста (-native);
  • BUILDSDK_CXXFLAGS при сборке для SDK (nativesdk-).

D

D

Каталог назначения в каталоге сборки, куда устанавливаются компоненты задачей do_install
(по умолчанию ${WORKDIR}/image). Задачи, читающие каталог или записывающие в него, следует запускать в fakeroot [1].

DATE

Дата начала сборки в формате YMD (например, 20150209 для 9 февраля 2015 г.).

DATETIME

Дата и время начала текущей сборки в формате, пригодном для временных меток.

DEBIAN_NOAUTONAME

При
наследовании класса
debian
(принято
по умолчанию) переменная задает отмену
переименования библиотек в стиле
Debian для отдельного пакета. При установке переменной должно применяться имя пакета, например, DEBIAN_NOAUTONAME_fontconfig-utils = «1».

DEBIANNAME

При наследовании класса debian (принято по умолчанию) переменная позволяет переопределить имя библиотеки для отдельного пакета. Такое переопределение происходит редко и при установке переменной должно применяться имя пакета, например, DEBIANNAME_${PN} = «dbus-1».

DEBUG_BUILD

Задает сборку пакетов с отладочной информацией. Это влияет на значение SELECTED_OPTIMIZATION.

DEBUG_OPTIMIZATION

Опции для передачи в TARGET_CFLAGS и CFLAGS при компиляции системы с отладкой. По умолчанию переменная имеет значение -O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe.

DEFAULT_PREFERENCE

Задает незначительное смещение при выборе приоритета для задания. Чаще всего для переменной устанавливают значение -1 в заданиях для development-версий программ. Это ведет к сборке по умолчанию стабильной версии задания при отсутствии PREFERRED_VERSION. Смещение от DEFAULT_PREFERENCE невелико и часто переопределяется BBFILE_PRIORITY,
если
эта переменная различается в двух
уровнях, содержащих разные версии одного
задания
.

DEFAULTTUNE

Используемые по умолчанию настройки CPU и ABI для системы сборки OE. Переменная DEFAULTTUNE помогает определить TUNE_FEATURES. Принятые по умолчанию настройки явно или неявно задаются машиной (MACHINE), однако их можно переопределить с помощью значений переменной AVAILTUNES.

DEPENDS

Список зависимостей при сборке задания. Это зависимости от других заданий (например, заголовков и общих библиотек). Например, задание 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].

DEPLOY_DIR

Указывает базовую область, куда система сборки OE помещает образы, пакеты, SDK и другие выходные файлы, предназначенные для внешнего использования. По умолчанию этот каталог размещается в каталоге сборки как ${TMPDIR}/deploy. Структура каталога сборки описана в разделе 5.2. Каталог сборки build/, а содержимое каталога развертывания рассмотрено в разделах Images, Package Feeds, и Application Development SDK [1].

DEPLOY_DIR_DEB

Указывает область, используемую системой сборки 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]).

DEPLOY_DIR_IMAGE

Указывает область, используемую системой сборки OE для размещения и связанных с ними файлов , готовых для развертывания вне системы сборки. Переменная является машино-зависимой, поскольку содержит ${MACHINE}.
По
умолчанию этот каталог размещается в
каталоге сборки как
${DEPLOY_DIR}/images/${MACHINE}/.

Информация о структуре каталога сборки приведена в разделе 5.2. Каталог сборки build/, а содержимое каталога развертывания описано в разделах Images и Application Development SDK [1].

DEPLOY_DIR_IPK

Указывает область, используемую системой сборки 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]).

DEPLOY_DIR_RPM

Указывает область, используемую системой сборки 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]).

DEPLOY_DIR_TAR

Указывает область, которую система сборки OE использует для размещения архивов, готовых для внешнего использования. Переменная применяется при наличии в переменной PACKAGE_CLASSES строки package_tar. Конфигурационный файл BitBake изначально определяет эту переменную как подкаталог в DEPLOY_DIR
-
DEPLOY_DIR_TAR = «${DEPLOY_DIR}/tar». Класс package_tar использует переменную DEPLOY_DIR_TAR для гарантии того, что задача do_package_write_tar
будет
записывать пакеты
TAR в подходящий каталог. Дополнительная информация о процессе упаковки приведена в разделе Package Feeds [1].

DEPLOYDIR

При наследовании класса deploy эта переменная указывает временную рабочую область для разворачиваемых файлов, установленную в классе deploy как DEPLOYDIR = «${WORKDIR}/deploy-${PN}». Заданиям, наследующим класс deploy,
следует
копировать разворачиваемые файлы в
DEPLOYDIR, а класс затем скопирует их в DEPLOY_DIR_IMAGE.

DESCRIPTION

Описание пакета, используемое менеджерами пакетов. Если значение DESCRIPTION не задано, автоматически принимается значение переменной SUMMARY.

DISTRO

Короткое имя для дистрибутива. Длинные имена задаются переменной DISTRO_NAME.

Переменная DISTRO соответствует файлу конфигурации (.conf) дистрибутива, корневое имя которого совпадает со значением переменной. Например, файл конфигурации дистрибутива Poky называется poky.conf и размещается в каталоге meta-poky/conf/distro дерева исходных кодов. В этом файле переменная задана как DISTRO = «poky».

Конфигурационные файлы дистрибутивов размещаются в каталоге conf/distro метаданных с конфигурацией дистрибутива. Значение DISTRO должно быть без пробелов и обычно указывается строчными буквами. Если переменная DISTRO пуста, используется заданное по умолчанию значение, которое указано в файле meta/conf/distro/defaultsetup.conf дерева исходных кодов.

DISTRO_CODENAME

Задает кодовое имя для собираемого дистрибутива.

DISTRO_EXTRA_RDEPENDS

Задает список определяемых дистрибутивом приложений, которые включаются во все образы. Эта переменная работает через packagegroup-base,
поэтому
на деле применяется только к наиболее
функциональным образам, включающим
группу
packagegroup-base. Переменная указывается в файле конфигурации дистрибутива .conf.

DISTRO_EXTRA_RRECOMMENDS

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

DISTRO_FEATURES

Поддержка программ, которую нужно включить в дистрибутив, задаваемая в конфигурационном файле. В большинстве случаев наличие или отсутствие свойства в DISTRO_FEATURES передается в соответствующую опцию сценария настройки при выполнении задачи do_configure
для
заданий, которые могут поддерживать
это свойство
. Например, указание x11 в DISTRO_FEATURES
приведет
к возможности включения поддержки
X11 для каждой собираемой программы. Другими примерами служат поддержка Bluetooth и NFS. Более полный список включенных в YP свойств (возможностей) представлен в параграфе 12.2. Свойства дистрибутива.

DISTRO_FEATURES_BACKFILL

Свойства для добавления в DISTRO_FEATURES при отсутствии в DISTRO_FEATURES_BACKFILL_CONSIDERED. Переменная указывается в файле meta/conf/bitbake.conf и не предназначена для настройки пользователем. Лучше просто указать переменную для свойств, включаемых во все конфигурации дистрибутива (параграф 12.4. Отключение автоматически добавляемых свойств).

DISTRO_FEATURES_BACKFILL_CONSIDERED

Свойства из переменной DISTRO_FEATURES_BACKFILL,
которые
не следует включать
(добавлять в DISTRO_FEATURES) при сборке (параграф 12.4. Отключение автоматически добавляемых свойств).

DISTRO_FEATURES_DEFAULT

Вспомогательная переменная со списком принятых по умолчанию свойств дистрибутива за исключением свойств, относящихся к библиотеке C (libc).

При создании пользовательского дистрибутива может оказаться полезной возможность многократного использования заданных по умолчанию опций DISTRO_FEATURES без необходимости переписывать весь набор. Это можно сделать, указав в конфигурационном файле дистрибутива DISTRO_FEATURES ?= «${DISTRO_FEATURES_DEFAULT} myfeature».

DISTRO_FEATURES_FILTER_NATIVE

Задает список свойств, которые при их наличии в DISTRO_FEATURES следует включать в сборку заданий native. Эти свойства дополняют список свойств, отфильтрованных переменой DISTRO_FEATURES_NATIVE.

DISTRO_FEATURES_FILTER_NATIVESDK

Задает список свойств, которые при их наличии в DISTRO_FEATURES следует включать в сборку заданий nativesdk. Эти свойства дополняют список свойств, отфильтрованных переменой DISTRO_FEATURES_NATIVESDK.

DISTRO_FEATURES_NATIVE

Задает список свойств, которые следует включать в DISTRO_FEATURES при сборке естественных заданий. Эти свойства дополняют список свойств, отфильтрованных переменой DISTRO_FEATURES_FILTER_NATIVE.

DISTRO_FEATURES_NATIVESDK

Задает список свойств, которые следует включать в DISTRO_FEATURES при сборке заданий nativesdk. Эти свойства дополняют список свойств, отфильтрованных переменой DISTRO_FEATURES_FILTER_NATIVESDK.

DISTRO_NAME

Длинное имя дистрибутива (короткое задает переменная 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_VERSION

Версия дистрибутива.

DISTROOVERRIDES

Список разделенных двоеточиями переопределений для текущего дистрибутива. По умолчанию список включает значение DISTRO. Можно расширить DISTROOVERRIDES для добавления переолпределений, применяемых к дистрибутиву. Базовым механизмом для DISTROOVERRIDES является включение в принятое по умолчанию значение OVERRIDES.

DL_DIR

Основной каталог загрузок, используемый процессом сборки для хранения загруженных файлов. По умолчанию 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.

DOC_COMPRESS

При наследовании класса compress_doc эта переменная задает правила сжатия, используемые системой сборки OE для страниц man и info. По умолчанию применяется компрессия gz (gzip), но можно выбрать xz или bz2. Информация об использовании этой переменной и правилах приведена в комментариях в файле meta/classes/compress_doc.bbclass.

E

EFI_PROVIDER

При сборке загружаемых образов (типы 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 Мбайт).

ERR_REPORT_DIR

При использовании с классом report-error задает путь, используемый для хранения отладочных файлов, созданных инструментом отчетов об ошибках, для централизованного хранения сведений об ошибках сборки. По умолчанию переменная имеет значение ${LOG_DIR}/error-report,
которое
можно изменить в файле
local.conf с помощью строки ERR_REPORT_DIR = «path«.

ERROR_QA

Задает проверки качества, об отказах которых системой сборки OE будут выдаваться сообщения об ошибках. Переменная задается в конфигурации дистрибутива, список проверок приведен в параграфе 6.56. insane.bbclass.

EXCLUDE_FROM_SHLIBS

Запускает распознаватель общих библиотек в системе сборки OE для исключения пакета целиком при сканировании общих библиотек. Функциональность распознавателя общих библиотек частично определяется внутренней функцией package_do_shlibs, которая является частью задачи do_package task. Следует знать, что распознаватель общих библиотек может неявно определять некоторые зависимости между пакетами.

Переменная EXCLUDE_FROM_SHLIBS похожа на PRIVATE_LIBS, которая исключает отдельные библиотеки, а не весь пакет. Переменная устанавливается для конкретного пакета в форме EXCLUDE_FROM_SHLIBS = «1».

EXCLUDE_FROM_WORLD

Указывает BitBake исключить задание из сборки world (т. е. bitbake
world
). При сборках world программа BitBake находит, анализирует и собирает все задания, найденные в каждом уровне, указанном в файле bblayers.conf. Для исключения задания следует установить в этой переменной значение 1 в задании.

Добавленные в EXCLUDE_FROM_WORLD могут все-таки включаться в сборку world для выполнения зависимостей других заданий. Включение в EXCLUDE_FROM_WORLD лишь блокирует явное включение задания в сборку.

EXTENDPE

применяется с файлами и именами путей для создания префикса версии задания на основе значения PE. Если для задания установлено значение PE больше 0, переменная EXTENDPE принимает это значение (т. е. при PE = «1» EXTENDPE становится «1_»). Если переменная PE в задании не установлена (принято по умолчанию) или равна 0, EXTENDPE получает значение «». Дополнительные сведения приведены в описании переменной STAMP.

EXTENDPKGV

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

     RDEPENDS_${PN}-additional-module = "${PN} (= ${EXTENDPKGV})"

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

EXTERNAL_KERNEL_TOOLS

Установленная переменная показывает инструменты, не включенные в дерево исходных кодов. Инструменты, доступные в дереве, обычно являются предпочтительными, но установка этой переменной позволяет системе сборки OE отдать предпочтение внешним инструментам. Использование переменной рассмотрено в параграфе 6.66. kernel-yocto.bbclass.

EXTERNALSRC

При наследовании класса externalsrc эта переменная указывает каталог исходных кодов за пределами системы сборки OE. При установке этой переменной она задает значение переменной S, используемой системой OE для указания распакованного исходного кода. Информация о классе externalsrc
приведена
в параграфе 6.34. externalsrc.bbclass,
а
использование переменной описано в
разделе
Building Software from an External Source [2].

EXTERNALSRC_BUILD

При наследовании класса externalsrc эта переменная указывает каталог, в котором собирается исходный код задания, находящийся вне системы сборки OE. При установке этой переменной она задает значение переменной B,
используемой
системой
OE для указания сборочного каталога. Информация о классе externalsrc
приведена
в параграфе 6.34. externalsrc.bbclass,
а
использование переменной описано в
разделе
Building Software from an External Source [2].

EXTRA_AUTORECONF

Для заданий, наследующих класс autotools, эта переменная позволяет задать дополнительные опции команды autoreconf,
выполняемой
задачей
do_configure
(по
умолчанию
—exclude=autopoint).

EXTRA_IMAGE_FEATURES

Список разделенных пробелами дополнительных возможностей для включения в образ. Обычно эта переменная указывается в файле 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].

EXTRA_IMAGECMD

Задает опции команды создания образа, указанной в IMAGE_CMD. При установке этой переменной используется переопределение соответствующего типа образа, например, EXTRA_IMAGECMD_ext3 ?= «-i 4096».

EXTRA_IMAGEDEPENDS

Список заданий для сборки, которые не предоставляют пакетов, устанавливаемых в корневую файловую систему.

Иногда для сборки финального образа нужны задания, которые не требуются в корневой файловой системе. Переменная EXTRA_IMAGEDEPENDS позволяет указать эти задания для выполнения зависимостей. Типичные примером является требование иметь загрузчик в конфигурации машины.

Добавление пакетов в корневую систему управляется переменными *RDEPENDS и *RRECOMMENDS.

EXTRANATIVEPATH

Список каталогов в ${STAGING_BINDIR_NATIVE},
добавляемых
в начало переменной окружения
PATH. Например, для добавления в путь поиска каталогов «${STAGING_BINDIR_NATIVE}/foo:${STAGING_BINDIR_NATIVE}/bar:» можно указать EXTRANATIVEPATH = «foo bar».

EXTRA_OECMAKE

Опции CMake (см. параграф 6.17. cmake.bbclass).

EXTRA_OECONF

Опции сценария configure.
Передача
опций зависит от переменной
PACKAGECONFIG_CONFARGS.

EXTRA_OEMAKE

Опции GNU make. Поскольку переменная EXTRA_OEMAKE по умолчанию пуста, ее требуется установить в соответствии с нужными опциями GNU. Переменные PARALLEL_MAKE и PARALLEL_MAKEINST также используют EXTRA_OEMAKE для передачи требуемых флагов.

EXTRA_OESCONS

При наследовании класса scons эта переменная задает дополнительные параметры конфигурации, которые нужно передать команде scons.

EXTRA_USERS_PARAMS

При наследовании класса 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

FEATURE_PACKAGES

Определяет пакеты для включения в образ, когда соответствующее свойство включено в переменную IMAGE_FEATURES. При установке значения переменной FEATURE_PACKAGES следует указывать суффикс в виде имени свойства, например,

FEATURE_PACKAGES_widget = "package1 package2"

В этом примере при наличии свойства widget в IMAGE_FEATURES
в
образ будут добавлены пакеты
package1 и package2. Пакеты, устанавливаемые свойствами через переменную FEATURE_PACKAGES,
зачастую
являются группами
. Несмотря на схожесть имен, не следует путать переменную FEATURE_PACKAGES с группами пакетов, встречающимися в документации.

FEED_DEPLOYDIR_BASE_URI

Указывает базовый идентификатор (URL) сервера и местоположение на нем метаданных и пакетов, требуемых OPKG для поддержки управления пакетами IPK в процессе работы. Переменная задается в файле local.conf,
например,
FEED_DEPLOYDIR_BASE_URI = «http://192.168.7.1/BOARD-dir». Здесь предполагается, что пакеты обслуживаются по протоколу HTTP, а базы данных хранятся на сервере в каталоге BOARD-dir. В этом случае система сборки OE будет создавать набор конфигурационных файлов для целевой платформы, которые подойдут для указанного хранилища.

FILES

Список файлов и каталогов, помещенных в пакет. Пакеты, созданные заданием перечисляются в переменной 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).

FILES_SOLIBSDEV

Задает спецификацию файлов для сопоставления с SOLIBSDEV. Иными словами, FILES_SOLIBSDEV определяет полный путь к символьным ссылкам на общие библиотеки для целевой платформы. Переменная задается в файле bitbake.conf как FILES_SOLIBSDEV ?= «${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}».

FILESEXTRAPATHS

Расширяет путь поиска OE для файлов и исправлений при обработке файлов заданий и добавлений. Используются принятые по умолчанию каталоги, используемые BitBake, определяются переменной FILESPATH,
которая может быть расширена с помощью
FILESEXTRAPATHS
. Лучше делать это с помощью переменной FILESEXTRAPATHS из файла .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
переопределение, полезно
е
на уровне
BSP — FILESEXTRAPATHS_prepend_intel-x86-common := «${THISDIR}/${PN}:»

Этот оператор присутствует в файле linux-yocto-dev.bbappend, который имеется в YP Source Repositories (раздел meta-intel/common/recipes-kernel/linux). Здесь в зависимости от машины изменяется специальное определение PACKAGE_ARCH для множества машин meta-intel.

Для уровней, поддерживающих один пакет BSP, переопределение может задаваться значением MACHINE.

Добавление пути в начало через файлы .bbappend позволяет расширять путь с помощью множества файлов дополнения, находящихся на разных уровнях но относящихся к одному заданию.

FILESOVERRIDES

Подмножество OVERRIDES,
используемое
системой сборки
OE для создания FILESPATH. Переменная использует переопределение для автоматического расширения FILESPATH
(пример работы приведен в описании FILESPATH,
а
более подробная информация о
переопределениях - в разделе
Conditional Syntax (Overrides) [4]). По умолчанию переменная задается в форме FILESOVERRIDES = «${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}». Переменную не следует редактировать вручную. Значения совпадают с ожидаемыми переопределениями и используются системой сборки ожидаемым способом.

FILESPATH

Принятый по умолчанию набор каталогов, в котором система сборки 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.

FILESYSTEM_PERMS_TABLES

Позволяет задать свю таблицу настроек прав доступа к файлу как часть конфигурации процесса подготовки пакетов. Например, при потребности в согласованном наборе прав доступа для гупп и пользователей в рамках проекта лучше устанавливать эти права в пакетах, но это возможно не всегда. По умолчанию система сборки OE использует файл fs-perms.txt
из
каталога
meta/files в дереве кодов. При создании своей таблицы разрешений следует поместить ее на свой уровень или уровень дистрибутива.

Переменная определяется в файле conf/local.conf каталога сборки и указывает пользовательский файл fs-perms.txt. Можно задать несколько таблиц доступа. Пути к файлам должны быть определены в переменной BBPATH. Рекомендации по созданию таблицы прав даны в файле fs-perms.txt.

FONT_EXTRA_RDEPENDS

При наследовании класса fontcache задает зависимости при работе от шрифтовых пакетов. По умолчанию FONT_EXTRA_RDEPENDS имеет значение «fontconfig-utils».

FONT_PACKAGES

При наследовании класса fontcache указывает пакеты, содержашие файлы шрифтов, которые нужно кэшировать в Fontconfig. По умолчанию класс fontcache предполагает шрифты в основном задании пакета (${PN}). Эта переменная нужна для случаев, когда шрифты размещаются не в основном пакете.

FORCE_RO_REMOVE

Значение 1 форсирует удаление пакетов, указанных в ROOTFS_RO_UNNEEDED,
при
создании корневой файловой системы.

FULL_OPTIMIZATION

Опции, передаваемые в TARGET_CFLAGS и CFLAGS при компиляции оптимизированной системы (по умолчанию -O2 -pipe ${DEBUG_FLAGS}).

G

GCCPIE

Включает поддержку PIE3 для компилятора GCC. Включение PIE в GCC осложняет организацию атак ROP4. По умолчанию в файле security_flags.inc указано GCCPIE ?= «—enable-default-pie».

GCCVERSION

Задает принятый по умолчанию компилятор GNU C (GCC). По умолчанию в файле meta/conf/distro/include/tcmode-default.inc задано GCCVERSION ?= «8.%». Можно указать другую веерсию в файле local.conf.

GDB

Сокращенная команда и аргументы для запуска отладчика GNU (gdb).

GITDIR

Каталог для хранения локальной копии репозитория Git при его клонировании.

GLIBC_GENERATE_LOCALES

Задает список языковых файлов GLIBC, если не нужны все такие файлы (занимает много времени). При удалении языка en_US.UTF-8
следует
должным образом установить переменную
IMAGE_LINGUAS. По умолчанию создаются файлы для всех языков.Значение GLIBC_GENERATE_LOCALES можно указать в файле local.conf
как
GLIBC_GENERATE_LOCALES = «en_GB.UTF-8 en_US.UTF-8».

GROUPADD_PARAM

При
наследовании класса
useradd
эта
переменная указывает, какие параметры
для пакета следует передать команде
groupadd,
если
нужно добавить группу при установке
пакета
. Например, для задания dbus указывается GROUPADD_PARAM_${PN} = «-r netdev»

Информация о стандартной команде Linux groupadd
доступна
по ссылке
http://linux.die.net/man/8/groupadd.

GROUPMEMS_PARAM

При наследовании класса useradd эта переменная указывает, какие параметры для пакета следует передать команде groupmems,
если
нужно изменить состав группы при
установке пакета.

Информация о стандартной команде Linux groupmems
доступна
по ссылке
http://linux.die.net/man/8/groupmems.

GRUB_GFXSERIAL

Указывает режим работы загрузчика GRUB5. Установите для этой переменной значение 1 в файле local.conf или файле конфигурации дистрибутива для включения графического режима и консоли serial. Использование переменной рассмотрено в описании класса grub-efi.

GRUB_OPTS

Опции для добавления в конфигурацию загрузчика GRUB, разделенные точкой с запятой (;). Переменная не обязательна, ее использование переменной рассмотрено в описании класса grub-efi.

GRUB_TIMEOUT

Задает время ожидания перед выбором заданной по умолчанию метки default LABEL загрузчике GRUB. Переменная не обязательна, ее использование переменной рассмотрено в описании класса grub-efi.

GTKIMMODULES_PACKAGES

При наследовании класса gtk-immodules-cache эта переменная указывает пакеты, содержащие устанавливаемые модули ввода GTK+, когда они не находятся в основном пакете.

H

HOMEPAGE

Web-сайт, на котором можно найти дополнительную информацию о собираемой заданием программе.

HOST_ARCH

Имя целевой архитектуры, которое обычно совпадает с TARGET_ARCH. Система сборки OE поддерживает множество вариантов архитектуры, включая arm, i586, x86_64, powerpc, powerpc64, mips, mipsel.

HOST_CC_ARCH

Указывает зависящие от архитектуры флаги, передаваемые компилятору C. Принятая по умолчанию инициализация HOST_CC_ARCH зависит от цели сборки:

  • TARGET_CC_ARCH при сборке для целевой платформы;
  • BUILD_CC_ARCH при сборке для сборочного хоста (-native);
  • BUILDSDK_CC_ARCH при сборке для SDK (nativesdk-).

HOST_OS

Задает имя целевой операционной системы, которое обычно совпадает с TARGET_OS. Для переменной можно установить значение linux в системах на основе glibc
и
linux-musl в системах на основе musl. Для пратформ ARM/EABI возможны также значения linux-gnueabi и linux-musleabi.

HOST_PREFIX

Задает префикс для инструментов кросс-компиляции. HOST_PREFIX обычно совпадает с TARGET_PREFIX.

HOST_SYS

Задает систему, включая архитектуру и ОС, для которой выполняется сборка в контексте текущего задания. Система сборки OE автоматически устанавливает эту переменную на основе значений HOST_ARCH, HOST_VENDOR
и
HOST_OS. Например, для естественного задания на 32-битовой машине x86 с ОС Linux переменная будет иметь значение i686-linux, а для задания на платформе little-endian MIPS с ОС Linux — mipsel-linux. Менять переменную не нужно.

HOSTTOOLS

Список разделенных пробелами инструментов, которые можно вызывать на хосте сборки из сборочных задач. Использование этого фильтра помогает снизить вероятность нарушения работы сборочного хоста. Если заданный в переменной инструмент не найден, система сборки OE выдает ошибку и сборка не начинается.

HOSTTOOLS_NONFATAL

Список разделенных пробелами инструментов, которые можно вызывать на хосте сборки из сборочных задач. Использование этого фильтра помогает снизить вероятность нарушения работы сборочного хоста. В отличие от инструментов HOSTTOOLS
система
сборки
OE не выдает ошибку при отсутствии указанного в HOSTTOOLS_NONFATAL.
Таким
образом, эта переменная указывает
необязательные инструменты хоста
.

HOST_VENDOR

Задает имя производителя целевого хоста. HOST_VENDOR обычно совпадает с TARGET_VENDOR.

I

ICECC_DISABLED

Управляет работой icecc (Icecream), рассмотренной в параграфе 6.49. icecc.bbclass. Установка в файле local.conf
ICECC_DISABLED ??= «1» отключает функцию, ICECC_DISABLED = «» — включает.

ICECC_ENV_EXEC

Указывает пользовательский сценарий icecc-create-env,
используется
классом
icecc и устанавливается в файле local.conf. Если сценарий не указан, система сборки OE использует принятый по умолчанию сценарий из задания icecc-create-env.bb, который является измененой вресией сценария из состава icecc.

ICECC_PARALLEL_MAKE

Опции, передаваемые команде make в задаче do_compile для параллельной компиляции. Эта переменная обычно имеет форму -j x, где x указывает максимальное число параллельных потоков. Опция влияет на все машины в сети сборки, где работает демон iceccd. При поддержке машинами множества ядер определение максимального числа потоков может потребовать некоторых экспериментов для учета скорости машин, задержек в сети, доступной памяти и текущей загрузки машин. Поэтому, в отличие от переменной PARALLEL_MAKE,
для
установки
ICECC_PARALLEL_MAKE нет строгих правил.

При отсутствии ICECC_PARALLEL_MAKE
система
сборки не будет определять и задавать
число используемых ядер, как это делается
для
PARALLEL_MAKE.

ICECC_PATH

Путь к исполняемому файлу icecc,
задаваемый
в файле
local.conf. Если путь не задан, класс icecc пытается найти icecc с помощью команды which.

ICECC_USER_CLASS_BL

Указывает пользовательские классы, для который не следует использовать распределенную компиляцию Icecream. Переменная используется классом icecc и устанавливается в файле local.conf. Все указанные переменной классы будут компилироваться локально.

ICECC_USER_PACKAGE_BL

Указывает пользовательские задания, которые не нужно учитывать в распределенной компиляции Icecream. Переменная используется классом icecc и устанавливается в файле local.conf. Все указанные переменной пакеты будут компилироваться локально.

ICECC_USER_PACKAGE_WL

Указывает пользовательские задания с пустой переменной PARALLEL_MAKE,
для
которых нужно принудительно использовать
параллельную удаленную компиляции с
использованием системы распределенной
компиляции
Icecream. Переменная используется классом icecc
и
может указываться в файле
local.conf.

IMAGE_BASENAME

Базовое имя выходных файлов образа, по умолчанию совпадающее с именем задания (${PN}).

IMAGE_BOOT_FILES

Список разделенных пробелами файлов, установленных в корневой раздел пр подготовке образа с использованием 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.

IMAGE_CLASSES

Список классов, которые нужно наследовать всем образам. Обычно эта переменная служит для задания классов, регистрирующих разные типы образов, которые создает система сборки OE. По умолчанию используется IMAGE_CLASSES = image_types,
но
можно установить другое значение в
файле
local.conf или в конфигурационном файле дистрибутива (см. meta/classes/image_types.bbclass в каталоге исходных кодов).

IMAGE_CMD

Задает команду создания файла образа определенного типа, соответствующего значению 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.

IMAGE_DEVICE_TABLES

Задает один или несколько файлов с пользовательскими таблицами устройств, которые передаются команде makedevs как часть создания образа. Эти файлы указывают базовые узлы устройства, которые следует создать в иерархии /dev внутри образа. Если переменная не указана, используется файл files/device_table-minimal.txt is used, найденный в пути BBPATH. Пример таблицы устройств имеется в файле meta/files/device_table-minimal.txt.

IMAGE_FEATURES

Основной список свойств (возможностей) для включения в образ. Обычно эта переменная указывается в задании для образа. Можно указать переменную в файле local.conf в каталоге сборки, но лучше так не поступать.

Для добавления возможностей за пределами задания для образа служит переменная EXTRA_IMAGE_FEATURES.

Список возможностей, включенных в выпуск YP, представлен в параграфе 12.3. Свойства образа. Пример настройки образа с помощью этой переменной приведен в разделе Customizing Images Using Custom IMAGE_FEATURES and EXTRA_IMAGE_FEATURES [2].

IMAGE_FSTYPES

Задает формат, применяемый системой сборки OE при создании корневой файловой системы. Например, для создания файлов систем, использующих форматы .ext3 и .tar.bz2
служит
IMAGE_FSTYPES = «ext3 tar.bz2».

Полный список поддерживаемых форматов приведен в описании переменной IMAGE_TYPES.

  • Если задание для образа использует строку inherit image и в нем установлена переменная IMAGE_FSTYPES, ее значение должно быть установлено до строки inherit image.
  • Способ обработки этой переменной в системе сборки OE не позволяет обновлять ее содержимое с помощью _append или _prepend
    и
    требует использования оператора
    += для добавления опций в IMAGE_FSTYPES.

IMAGE_INSTALL

Используется в заданиях для указания пакетов, устанавливаемых в образ с помощью класса 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.conf file или иных файлах задания для образе не рекомендуется, поскольку применение этого оператора может приводить к проблемам с порядком установки. Класса core-image.bbclass устанавливает для IMAGE_INSTALL принятое по умолчанию значение с помощью оператора ?=, использование += для переменной IMAGE_INSTALL в файле conf/local.conf
    приводит к неожиданному поведению. Кроме того, та же операция из задания для образа может завершаться отказом в зависимости от ситуации. В обоих случаях поведение будет отличаться от ожидаемого пользователем для оператора +=.

IMAGE_LINGUAS

Задает список языков (locale) для включения в образ при создании корневой файловой системы. Система сборки OE автоматически разделяет языковые файлы по отдельным пакетам. Назначение переменной IMAGE_LINGUAS гарантирует включение языковых пакетов во все пакеты, выбранные для инсталяции в образ. Переменная задается в форме IMAGE_LINGUAS = «pt-br de-de». Пример показывает установку языковых файлов для бразильского португальского и немецкого языка для включенных в образ пакетов (т. е. *-locale-pt-br и *-locale-de-de,
а
для некоторых пакетов
*-locale-pt и *-locale-de, поскольку часть пакетов обеспечивает файлы языков без учета страны). Генерация языковых файлов GLIBC рассмотрена в описании переменной GLIBC_GENERATE_LOCALES.

IMAGE_MANIFEST

Файл манифеста для образа, перечисляющий все установленные пакеты (по одной строке на пакет) в форме packagename packagearch version.
Класс
image определяет файл манифеста как IMAGE_MANIFEST = «${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest». Местоположение выводится из переменных DEPLOY_DIR_IMAGE и IMAGE_NAME. Создание образов описано в разделе Image Generation [1].

IMAGE_NAME

Имя выходных файлов образа без расширений, задаваемое в форме IMAGE_NAME = «${IMAGE_BASENAME}-${MACHINE}-${DATETIME}».

IMAGE_OVERHEAD_FACTOR

Определяет коэффициент, который система сборки использует для начального размера образа в случаях, когда используемое в образе пространство (возврат команды 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.

IMAGE_PKGTYPE

Определяет тип пакета (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.

IMAGE_POSTPROCESS_COMMAND

Задает список функций, однократно вызываемых системой сборки OE при создании окончательных выходных файлов. Функции разделяются точкой с запятой, например, IMAGE_POSTPROCESS_COMMAND += «function; … «

Если нужно передать путь к корневой файловой системе при вызове функции, можно использовать переменную ${IMAGE_ROOTFS},
указывающую
каталог, который станет корневой файловой
систем
ой
образа.

IMAGE_PREPROCESS_COMMAND

Задает список функций, вызываемых системой сборки OE перед созданием окончательных выходных файлов. Функции разделяются точкой с запятой, например, IMAGE_PREPROCESS_COMMAND += «function; … «

Если нужно передать путь к корневой файловой системе при вызове функции, можно использовать переменную ${IMAGE_ROOTFS},
указывающую
каталог, который станет корневой файловой
систем
ой
образа.

IMAGE_ROOTFS

Местоположение корневой файловой системы в процессе ее создания (задача do_rootfs). Значение этой переменной не следует менять.

IMAGE_ROOTFS_ALIGNMENT

Задает выравнивание для выходного файла образа в килобайтах. Если размер образа не кратен этому значению, он округляется вверх до кратного значения. По умолчанию установлено значение 1 (см. IMAGE_ROOTFS_SIZE).

IMAGE_ROOTFS_EXTRA_SPACE

Задает дополнительное свободное пространства в создаваемом образе (в килобайтах). По умолчанию дополнительное пространство не выделяется (0). Заданное переменной пространство добавляется в образ после того, как система сборки определит размер образа в соответствии с переменной IMAGE_ROOTFS_SIZE.

Переменная полезна для резервирования свободного пространства в файловой системе после загрузки образа. Например, для обеспечения свободных 5 Гбайт можно указать IMAGE_ROOTFS_EXTRA_SPACE = «5242880». В частности, Yocto Project Build Appliance задает 40 Гбайт дополнительного места с помощью строки IMAGE_ROOTFS_EXTRA_SPACE = «41943040».

IMAGE_ROOTFS_SIZE

Определяет размер создаваемого образа к килобайтах. Система сборки 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_TYPEDEP

Указывает зависимость одного типа образа от другого, например, для образа из класса image-live
IMAGE_TYPEDEP_live = «ext3». В этом примере переменная обеспечивает включение live в переменную IMAGE_FSTYPES
и система сборки OE создает сначала образ ext3, поскольку одной из частей образа live является раздел формата ext3 с корневой файловой системой.

IMAGE_TYPES

Задает полный список поддерживаемых по умолчанию типов образов: 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 дерева исходных кодов.

INC_PR

Помогает указать выпуск для заданий, использующих общий включаемый файл. Можно считать эту переменную частью варианта задания, устанавливаемой из включаемого файла.

Предположим, что имеется набор заданий, используемых в нескольких проектах, и для каждого из этих заданий задан выпуск (в переменной 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.

INCOMPATIBLE_LICENSE

Задает список разделенных пробелами имен лицензий (как в переменной LICENSE), которые следует исключить при сборке. Значения, не содержащие замены исключенных лицензий, собираться не будут, пакеты, с несовместимыми лицензиями будут удалены. Эта функциональность регулярно проверяется лишь для INCOMPATIBLE_LICENSE = «GPL-3.0 LGPL-3.0 AGPL-3.0». Ваши установки могут отличаться, но все равно может потребоваться указание несовместимых лицензий или замен для создания образа.

INHERIT

Задает глобальное наследование указанных классов. Анонимные функции классов не выполняются для базовой конфигурации и в каждом отдельном задании. Система сборки OE игнорирует изменение переменной INHERIT в отдельных заданиях. Дополнительная информация приведена в разделе INHERIT Configuration Directive [4].

INHERIT_DISTRO

Указывает классы, которые будут наследоваться на уровне дистрибутива. Обычно менять эту переменную не требуется. Используемое по умолчанию значение переменной задано в файле meta/conf/distro/defaultsetup.conf как INHERIT_DISTRO ?= «debian devshell sstate license».

INHIBIT_DEFAULT_DEPS

Предотвращает добавление заданных по умолчанию зависимостей (компилятор C и стандартная библиотека libc) в DEPENDS. Переменная обычно применяется в заданиях, которым не нужен компилятор C. Установка значения 1 предотвращает добавление принятых по умолчанию зависимостей.

INHIBIT_PACKAGE_DEBUG_SPLIT

Установка значения 1 в этой переменной предотвращает отделение отладочной информации при подготовке пакетов. По умолчанию система сборки отделяет отладочную информацию в процессе выполнения задачи do_package
(см. описание PACKAGE_DEBUG_SPLIT_STYLE).

INHIBIT_PACKAGE_STRIP

Установка значения 1 отменяет удаление системой сборки символов из собранных пакетов и предотвращает включение исходных файлов в пакеты -dbg. По умолчанию система сборки OE вырезает символы из двоичных файлов и помещает отладочные символы в ${PN}-dbg. Поэтому не следует устанавливать переменную INHIBIT_PACKAGE_STRIP,
если
планируется отладка
.

INHIBIT_SYSROOT_STRIP

Установка значения 1 отменяет удаление системой сборки символов из двоичных файлов sysroot, выполняемое по умолчанию. Для использования переменной в задании нужно включить класс staging,
который
применяет функцию
sys_strip() для проверки значения переменной и выполнения нужных действий.

Переменная применяется редко. Примером может служить создание прошивки для пустой платформы (bare-metal) с использованием внешних инструментов GCC. Furthermore, even if the toolchain’s binaries are strippable, other files exist that are needed for the build that are not strippable.

INITRAMFS_FSTYPES

Задает формат выходного образа initramfs, используемого при загрузке. Поддерживаемые форматы совпадают с возможными форматами IMAGE_FSTYPES. По умолчанию в файле meta/conf/bitbake.conf для этой переменной задается значение cpio.gz. Механизм initramfs в Linux в отличие от initrd предполагает возможность сжатия образа.

INITRAMFS_IMAGE

Задает имя задания (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].

INITRAMFS_IMAGE_BUNDLE

Управляет дополнительным проходом 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_LINK_NAME

Имя ссылки для исходного образа файловой системы initramfs. Переменная задается в файле meta/classes/kernel-artifact-names.bbclass
как
INITRAMFS_LINK_NAME ?= «initramfs-${KERNEL_ARTIFACT_LINK_NAME}». Этот же файл задает переменную KERNEL_ARTIFACT_LINK_NAME ?= «${MACHINE}».

INITRAMFS_NAME

Базовое имя исходного образа файловой системы initramfs. Переменная задается в файле meta/classes/kernel-artifact-names.bbclass как INITRAMFS_NAME ?= «initramfs-${KERNEL_ARTIFACT_NAME}». Этот же файл задает KERNEL_ARTIFACT_NAME ?= «${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}».

INITRD

Задает список файловых систем для конкатенации и использования в качестве исходного RAM-диска (initrd). Переменная не обязательна и применяется классом image-live.

INITRD_IMAGE

При сборке загружаемых образов live (IMAGE_FSTYPES содержит live) переменная задает задание для образа, которое следует собрать для создания образа исходного RAM-диска. По умолчанию задано значение core-image-minimal-initramfs (см. параграф 6.53. image-live.bbclass).

INITSCRIPT_NAME

Имя файла со сценарием инициализации, установленное в ${sysconfdir}/init.d. Переменная применяется в заданиях, использующих класс update-rc.d.bbclass,
и
является обязательной
.

INITSCRIPT_PACKAGES

Список пакетов, содержащих сценарии инициализации. При задании нескольких пакетов нужно добавлять имя пакета в конце к другим INITSCRIPT_* как переопределение. Переменная применяется в заданиях, использующих класс update-rc.d.bbclass. Переменная не обязательна и по умолчанию имеет значение переменной PN.

INITSCRIPT_PARAMS

Задает опции для передачи 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. Дополнительная информация доступна по ссылке.

INSANE_SKIP

Задает проверки QA, пропускаемые для конкретного пакета в задании. Например, для пропуска проверки символьных ссылок для файлов .so в основном пакете задания в это задание добавляется приведенная ниже переменная. Следует указывать переопределенное имя задания (в примере ${PN}).

     INSANE_SKIP_${PN} += "dev-so"

Список проверок QA, которые можно указать в этой переменной, приведен в параграфе 6.56. insane.bbclass.

INSTALL_TIMEZONE_FILE

По умолчанию задание tzdata включает файл /etc/timezone. Установка INSTALL_TIMEZONE_FILE = 0 на уровне конфигурации отменяет это.

IPK_FEED_URIS

При использовании менеджера IPK и включенном на целевой платформе управлении пакетами эьа переменная может служить для установки opkg в целевом образе с целью указания источника пакетов на означенном сервере. После организации источника можно устанавливать и обновлять пакеты при работе платформы.

K

KARCH

Указывает архитектуру ядра, применяемую для сборки конфигурации — powerpc, i386, x86_64, arm, qemu, mips. Переменная KARCH определяется в описаниях BSP [3].

KBRANCH

Регулярное выражение, применяемое процессом сборки для явного указания ветви ядра, которая проверяется, изменяется (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.

KBUILD_DEFCONFIG

При использовании с классом 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_ALT_IMAGETYPE

Задает другой тип образа ядра в дополнение к типу, указанному переменной KERNEL_IMAGETYPE.

KERNEL_ARTIFACT_NAME

Указывает имя для всех элементов сборки (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_CLASSES

Список классов, определяющих типы образов ядра, которые должен наследовать класс kernel. Обычно эта переменная добавляется для включения расширенных типов образов. Примером является класс kernel-fitimage, включающий поддержку fitImage и заданный в файле meta/classes/kernel-fitimage.bbclass. Можно зарегистрировать свои типы образов ядра с помощью этой переменной.

KERNEL_DEVICETREE

Задает имя создаваемого файла с деревом устройств ядра Linux (.dtb). Имеется устаревший способ указания полного пути к дереву устройств, однако предпочтительней использовать файл .dtb. Для использования переменной нужно указать включаемые файлы в задании для ядра в форме require recipes-kernel/linux/linux-dtb.inc или require recipes-kernel/linux/linux-yocto.inc.

KERNEL_DTB_LINK_NAME

Имя ссылки на двоичное дерево устройств (DTB6) в файле meta/classes/kernel-artifact-names.bbclass,
указанное
как
KERNEL_DTB_LINK_NAME ?= «${KERNEL_ARTIFACT_LINK_NAME}». Переменная KERNEL_ARTIFACT_LINK_NAME
в
том же файле
имеет форму KERNEL_ARTIFACT_LINK_NAME ?= «${MACHINE}».

KERNEL_DTB_NAME

Базовое имя 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}».

KERNEL_EXTRA_ARGS

Задает дополнительные аргументы команды make,
которые
система сборки
OE использует при компиляции ядра.

KERNEL_FEATURES

Включает дополнительные метаданные ядра. В системе сборки 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"

KERNEL_FIT_LINK_NAME

Имя ссылки на плоское дерево образа ядра (FIT), задаваемое в файле meta/classes/kernel-artifact-names.bbclass
как KERNEL_FIT_LINK_NAME ?= «${KERNEL_ARTIFACT_LINK_NAME}». В том же файле указывается переменная KERNEL_ARTIFACT_LINK_NAME ?= «${MACHINE}».

KERNEL_FIT_NAME

Базовое имя плоского дерева образа ядра (FIT), задаваемое в файле meta/classes/kernel-artifact-names.bbclass как KERNEL_FIT_NAME ?= «${KERNEL_ARTIFACT_NAME}». В этом же файле устанавливается переменная KERNEL_ARTIFACT_NAME ?= «${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}».

KERNEL_IMAGE_LINK_NAME

Имя ссылки для образа ядра, устанавливаемое в файле meta/classes/kernel-artifact-names.bbclass как KERNEL_IMAGE_LINK_NAME ?= «${KERNEL_ARTIFACT_LINK_NAME}». В том же файле файле устанавливается переменная KERNEL_ARTIFACT_LINK_NAME ?= «${MACHINE}».

KERNEL_IMAGE_MAXSIZE

Задает максимальный размер образа ядра в килобайтах. При установке переменной размер ядра сравнивается с ее значением при выполнении задачи do_sizecheck
с
возвратом ошибки в случае превышения
заданного размера
. Переменная полезна для систем с ограниченным пространством для хранения образа ядра. По умолчанию переменная не устанавливается и размер ядра не ограничен.

KERNEL_IMAGE_NAME

Базовое имя образа ядра. Переменная задается файлом 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}».

KERNEL_IMAGETYPE

Тип ядра, собираемого для устройства, который обычно задается конфигурационными файлами для машины. По умолчанию применяется zImage. Эта переменная используется при сборке ядра и передается команде make как цель сборки. Для сборки дополнительного типа образа используется переменная KERNEL_ALT_IMAGETYPE.

KERNEL_MODULE_AUTOLOAD

Указывает модули ядра, которые нужно автоматически загружать при загрузке системы. Переменную можно использовать в любом месте, доступном заданию для ядра или внешнего (out-of-tree) модуля (например, в файле конфигурации машины или дистрибутива, файле дополнения к заданию или самом задании).

KERNEL_MODULE_AUTOLOAD += "module_name1 module_name2 module_name3"

Включение KERNEL_MODULE_AUTOLOAD заставляет систему сборки OE указать список автоматически загружаемых модулей в файле /etc/modules-load.d/modname.conf. Модули указываются по одному в строке, например, KERNEL_MODULE_AUTOLOAD += «module_name«.

Информация о заполнении файла modname.conf в синтаксисом modprobe.d приведена в описании переменной KERNEL_MODULE_PROBECONF.

KERNEL_MODULE_PROBECONF

Задает список модулей, для которых система сборки OE предполагает найти значения module_conf_modname,
задающие
конфигурацию каждого модуля. Информация
о настройке модулей приведена в описании
переменн
ой
module_conf.

KERNEL_PATH

Указывает местоположение исходных кодов ядра. Переменная получает значение STAGING_KERNEL_DIR в классе module. Работа с переменной описана в разделе Incorporating Out-of-Tree Modules [3].

Для максимальной совместимости с внешними (out-of-tree) драйверами при сборке модулей система OE распознает и применяет переменную KERNEL_SRC, которая идентична KERNEL_PATH
. Обе переменные используются внешними файлами Makefile для указания каталога с исходными кодами ядра.

KERNEL_SRC

Указывает местоположение исходных кодов ядра. Переменная получает значение STAGING_KERNEL_DIR в классе module. Работа с переменной описана в разделе Incorporating Out-of-Tree Modules [3].

Для максимальной совместимости с внешними (out-of-tree) драйверами при сборке модулей система OE распознает и применяет переменную KERNEL_PATH, которая идентична KERNEL_SRC. Обе переменные используются внешними файлами Makefile для указания каталога с исходными кодами ядра.

KERNEL_VERSION

Указывает версию ядра, извлеченную из файла version.h или utsrelease.h в дереве кода ядра. Установка этой переменной не оказывает влияния, пока не будет настроена конфигурация ядра, поэтому попытка обращения к ней до настроки конфигурации не приведет к желаемому результату.

KERNELDEPMODDEPEND

Указывает, нужны ли данные, упомянутые в переменной PKGDATA_DIR. KERNELDEPMODDEPEND контролирует не наличие этих данных, а их использование. Если данные не нужны, укажите KERNELDEPMODDEPEND
в
задании
initramfs,
это
позволит предотвратить возможное
зацикливание зависимостей
.

KFEATURE_DESCRIPTION

Дает краткое описание фрагмента конфигурации. Эта переменная применяется в файлах .scc,
описывающих
файлы с фрагментами конфигурации
. Например, в файле в файле smp.scc эта переменная включает опции SMP в форме define KFEATURE_DESCRIPTION «Enable SMP».

KMACHINE

Машина, известная ядру. Иногда используемое ядром имя машины не совпадает с именем в системе сборки 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.

KTYPE

Определяет тип ядра, используемый при сборке конфигурации. Задания linux-yocto определяют типы standard, tiny и preempt-rt (см. раздел Kernel Types [3]). Переменная KTYPE задается в описании BSP, а ее значение должно соответствовать значению переменной LINUX_KERNEL_TYPE в задании для ядра.

L

LABELS

Указывает список целей для автоматической настройки конфигурации. Использование переменной рассмотрено в описании класса grub-efi.

LAYERDEPENDS

Список разделенных пробелами уровней, от которых зависит данный уровень. Можно также указывать конкретную версию уровня, добавляя ее в конце имени. Например, LAYERDEPENDS_mylayer = «anotherlayer (=3)», где номер версии 3 уровня anotherlayer сравнивается с LAYERVERSION_anotherlayer. Переменная
указывается в файле
conf/layer.conf
и
должна иметь суффикс в виде имени
конкретного уровня (например,
LAYERDEPENDS_mylayer).

LAYERDIR

При использовании в файле layer.conf указывает путь к текущему уровню. Переменная не доступна за пределами layer.conf и ссылки разыменовываются сразу по завершении разбора файла.

LAYERRECOMMENDS

Список разделенных пробелами уровней, рекомендованных для использования с данным уровнем. Можно также указывать конкретную версию уровня, добавляя ее в конце имени. Например, LAYERRECOMMENDS_mylayer = «anotherlayer (=3)», где номер версии 3 уровня anotherlayer сравнивается с LAYERVERSION_anotherlayer. Переменная указывается в файле conf/layer.conf и должна иметь суффикс в виде имени конкретного уровня (например, LAYERRECOMMENDS_mylayer).

LAYERSERIES_COMPAT

Перечисляет версии 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 выдает предупреждения, если переменная не установлена для уровня.

LAYERVERSION

Опционально задает версию уровня одним числом. Можно использовать это значение в LAYERDEPENDS для другого уровня для указания зависимости от конкретной версии уровня. Переменная применяется в файле conf/layer.conf и должна иметь суффикс в виде имени конкретного уровня (например, LAYERVERSION_mylayer).

LD

Сокращенная команда и аргументы для запуска компоновщика.

LDFLAGS

Задает флаги, передаваемые компоновщику. Переменная экспортируется в окружение и доступна программам, собираемым на этапе компиляции. Принятое по умолчанию значение LDFLAGS зависит от собираемого объекта:

  • TARGET_LDFLAGS при сборке для целевой платформы;
  • BUILD_LDFLAGS при сборке для сборочного хоста (-native);
  • BUILDSDK_LDFLAGS при сборке для SDK (nativesdk-).

LEAD_SONAME

Задает основной (первичный) файл скомпилированной библиотеки (.so), к которому класс debian применяет свои правила именования в образах с множеством библиотек. Переменная применяется с классам debian.

LIC_FILES_CHKSUM

Контрольная сумма текста лицензии в исходном коде задания для отслеживания изменений в тексте. Если текст лицензии будет изменен, это приведет к отказу сборки, указывающему разработчику просмотреть изменение в тексте. Эта переменная должна указываться для всех заданий, кроме тех, где установлено LICENSE = CLOSED. Дополнительную информацию о лицензировании можно найти в разделе Tracking License Changes [2].

LICENSE

Список лицензий для задания в соответствии с приведенными ниже правилами:

  • не допускаются пробелы в именах лицензий;
  • имена лицензий разделяются символом | при возможности выбора лицензии;
  • имена лицензий разделяются символом & (амперсанд) при наличии нескольких лицензий для разных частей кода;
  • между именами лицензий можно использовать символы пробела;
  • для стандартных лицензий применяются имена из файла 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

Установка LICENSE_CREATE_PACKAGE = 1 заставляет систему сборки OE создавать дополнительный пакет (${PN}-lic)ого задания и добавлять эти пакеты в переменную RRECOMMENDS_${PN}.

Пакет ${PN}-lic создает каталог /usr/share/licenses named ${PN}
(базовое
имя задания) и помещает в него файлы с
лицензией и информацией об авторских
правах (т. е. копии подходящих лицензий
из
meta/common-licenses,
соответствующие
лицензиям, указанным в переменной
LICENSE метаданных задания, и копии файлов, указанных в LIC_FILES_CHKSUM как файлы с текстами лицензий).

Дополнительная информация о предоставлении текстов лицензий приведена в описаниях переменных COPY_LIC_DIRS и COPY_LIC_MANIFEST, а также в разделе Providing License Text [2].

LICENSE_FLAGS

перечисляет для задания дополнительные флаги, которые следует включить в LICENSE_FLAGS_WHITELIST,
чтобы
задание можно было собрать
. Флаги в списке разделяются пробелами. Это значение не зависит от LICENSE
и
обычно применяется для маркировки
заданий, которым могут требоваться
дополнительные лицензии для использования
в коммерческой продукции. Дополнительная
информация о лицензировании приведена
в разделе Enabling
Commercially Licensed Recipes
[2].

LICENSE_FLAGS_WHITELIST

Перечисляет флаги лицензий, которым при указании в LICENSE_FLAGS
для
задания
,
не
следует препятствовать в сборке. Это
иногда называют «белым списком» лицензий.
Дополнительная информация о лицензировании
приведена в разделе
Enabling Commercially Licensed Recipes [2].

LICENSE_PATH

Путь к дополнительным лицензиям, используемым при сборке. По умолчанию система сборки OE применяет COMMON_LICENSE_DIR для определения каталога с общим текстом лицензии, используемой при сборке. Эта переменная позволяет добавить каталоги в форме LICENSE_PATH += «path-to-additional-common-licenses«.

LINUX_KERNEL_TYPE

Определяет тип ядра, применяемый при сборке конфигурации. В заданиях linux-yocto определены типы standard, tiny и preempt-rt (см. раздел Kernel Types [3]). Если переменная LINUX_KERNEL_TYPE
не
задана
, применяется тип standard. Вместе с переменной KMACHINE значение LINUX_KERNEL_TYPE определяет аргументы поиска, применяемые инструментами ядра при поиске подходящего описания в метаданных ядра для определения исходных файлов и конфгурации.

LINUX_VERSION

Версия 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_VERSION_EXTENSION

Строка расширения, компилируемая в строку версии ядра Linux, собираемого в системе OE. Эта переменная указывается в задании для ядра. Например, задание определяет ее как

     LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"

Определение этой переменной по существу задает значение конфигурационного параметра ядра CONFIG_LOCALVERSION, которое доступно по команде uname. Ниже приведен пример вывода команды.

     $ uname -r
     3.7.0-rc8-custom

LOG_DIR

Задает каталог, в который система сборки OE записывает log-файлы (по умолчанию ${TMPDIR}/log). Каталоги с журналами для каждой задачи задаются с помощью переменной T.

M

MACHINE

Задает целевое устройство, для которого собирается ядро. Переменная указывается в файле 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_ARCH

Задает архитектуру конкретной машины и устанавливается автоматически из переменной 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
в файл конфигурации машины включается
строка
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += «kernel-module-ab123».

В этом примере задание kernel-module-ab123 должно явно установить свою переменную PACKAGES,
чтобы
BitBake не использовал переменную PACKAGES_DYNAMIC из задания ядра для соблюдения зависимости.

Примерами таких устройств являются драйверы флэш-памяти, экрана, клавиатуры, мыши или сенсорного экрана.

MACHINE_EXTRA_RDEPENDS

Список машино-зависимых пакетов для установки в собираемый образ, которые не имеют значения при загрузке машины, но сборка образа зависит от этих пакетов. Переменная влияет лишь на образы, основанные на packagegroup-base, которые не включают core-image-minimal и core-image-full-cmdline. Переменная похожа на MACHINE_EXTRA_RRECOMMENDS,
но
отличается тем, что сборка образа зависит
от указанных в ней пакетов.

Примером может служить машина с поддержкой WiFi, которая не существенна для загрузки. Однако при сборке более функционального образа может потребоваться WiFi. В этом случае предполагается наличие пакета с микрокодом WiFi, поэтому логична зависимость процесса сборки от наличия этого пакета. Для решения этой задачи (в предположении, что пакет называется wifidriver-firmware)
следует включить в файл
.conf для машины строку MACHINE_EXTRA_RDEPENDS += «wifidriver-firmware».

MACHINE_EXTRA_RRECOMMENDS

Список машино-зависимых пакетов для установки в собираемый образ, которые не имеют значения при загрузке машины и сборка образа не зависит от этих пакетов. Переменная влияет лишь на образы, основанные на 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_FEATURES

Задает список аппаратных функций, которые MACHINE может поддерживать. Включение дополнительных свойств управляется переменными DISTRO_FEATURES, COMBINED_FEATURES
и IMAGE_FEATURES. Список аппаратных возможностей, поддерживаемых YP, приведен в параграфе 12.1. Свойства машины.

MACHINE_FEATURES_BACKFILL

Свойства, добавляемые в MACHINE_FEATURES при их отсутствии в переменной MACHINE_FEATURES_BACKFILL_CONSIDERED. Эта переменная задана в файле meta/conf/bitbake.conf
и
не предназначена для настройки
пользователем
. О сослаться на переменную для просмотра функций, «засыпанных» в конфигурации всех машин (см.
параграф 12.4. Отключение автоматически добавляемых свойств)
.

MACHINE_FEATURES_BACKFILL_CONSIDERED

Свойства из MACHINE_FEATURES_BACKFILL,
которые
не следует добавлять в
MACHINE_FEATURES
при
сборке (см. параграф 12.4. Отключение автоматически добавляемых свойств)
.

MACHINEOVERRIDES

Разделенный двоеточиями список переопределений, применяемых для конкретной машины. По умолчанию этот список включает значение переменной 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.

MAINTAINER

Адрес электронной почты для поддержки дистрибутива.

MIRRORS

Задает дополнительные пути для поиска исходных кодов системой сборки OE, которая сначала пытается найти коды в локальном каталоге загрузки. При отсутствии кодов в этом каталоге система просматривает репозитории, указанные переменной PREMIRRORS, затем «восходящий источник» и репозитории, указанные переменной MIRRORS. В дистрибутиве (DISTRO) poky принятое по умолчанию значение MIRRORS указано в файле conf/distro/poky.conf репозитория meta-poky.

MLPREFIX

Задает префикс, добавляемый к переменной 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».

module_autoload

Переменная заменена KERNEL_MODULE_AUTOLOAD,
поэтому
следует
отредактировать
все
файлы, включающие ее. Например,
module_autoload_rfcomm = «rfcomm» заменить на KERNEL_MODULE_AUTOLOAD += «rfcomm».

module_conf

Задает строки с синтаксисом 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.d
). Например, добавление опций arg1 и arg2 для модуля mymodule
может
иметь вид
module_conf_mymodule = «options mymodule arg1=val1 arg2=val2».

Автоматическая загрузка модулей ядра управляется переменной KERNEL_MODULE_AUTOLOAD.

MODULE_TARBALL_DEPLOY

Управляет созданием файла modules-*.tgz
с
модулями ядра, созданны
ми
при сборке
(0 отменяет запись архива).

MODULE_TARBALL_LINK_NAME

Имя ссылки для архива модулей ядра, устанавливаемое в файле meta/classes/kernel-artifact-names.bbclass как MODULE_TARBALL_LINK_NAME ?= «${KERNEL_ARTIFACT_LINK_NAME}». Для KERNEL_ARTIFACT_LINK_NAME
в
том же файле устанавливается значение
KERNEL_ARTIFACT_LINK_NAME ?= «${MACHINE}»

MODULE_TARBALL_NAME

Базовое имя архива модулей ядра, устанавливаемое в файле 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}».

MULTIMACH_TARGET_SYS

Однозначно указывает тип целевой системы, для которой собираются пакеты. Переменная позволяет размещать вывод для разных целевых систем в разные подкаталоги одного выходного каталога. По умолчанию переменная имеет значение ${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}. Некоторые классы (например, cross-canadian) меняют значение MULTIMACH_TARGET_SYS. Дополнительная информация приведена в описаниях переменных STAMP и STAGING_DIR_TARGET.

N

NATIVELSBSTRING

Строка, указывающая дистрибутив хоста. Строка включает идентификатор дистрибутива, за которым следует номер выпуска, возвращаемый командой lsb_release или прочитанный в файле /etc/lsb-release. Например, при работе на хосте Ubuntu 12.10 переменная будет иметь значение Ubuntu-12.10. Если дистрибутив определить не удается, переменная получает значение Unknown.

Переменная используется по умолчанию для разделения естественных пакетов разных дистрибутивов (например, для предотвращения проблем, связанный с несовместимостью версий glibc). Кроме того, эта переменная проверяется по SANITY_TESTED_DISTROS,
если
та установлена
.

NM

Сокращенная команда и аргументы для запуска nm
(просмотр
символ
ов
из объектных файлов)
.

NO_GENERIC_LICENSE

Предотвращает ошибки 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"

NO_RECOMMENDATIONS

Предотвращает установку пакетов, которые лишь рекомендованы (устанавливаются через переменную RRECOMMENDS). Например, NO_RECOMMENDATIONS = «1» включает эту функцию.

Переменную можно установить глобально в файле local.conf или присоединить к заданию для конкретного образа, переопределяя имя задания в виде NO_RECOMMENDATIONS_pn-target_image = «1».

Важно понимать, что при включении в эту переменную пакетов, от которых зависят другие пакеты (указаны в переменной RDEPENDS), система сборки OE будет игнорировать запрос и установит пакеты, чтобы не нарушать зависимостей.

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

Переменная поддерживается только при наличии менеджеров пакетов IPK и RPM, но не поддерживается для DEB.

См. также описания переменных BAD_RECOMMENDATIONS и PACKAGE_EXCLUDE.

NOAUTOPACKAGEDEBUG

Выключает автоматическое выделение для пакета файлов .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"

Продолжение


1Application Binary Interface — интерфейс двоичных приложений.

2Package Management System — система управления пакетами.

3Position Independent Executables — независимые от расположения исполняемые файлы.

4Return Oriented Programming — ориентированное на возвращаемое значение программирование.

5GNU GRand Unified Bootloader.

6Device tree binary.

7Free Documentation License — свободное распространение документации.