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

O

OBJCOPY

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

OBJDUMP

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

OE_BINCONFIG_EXTRA_MANGLE

При наследовании класса binconfig указывает дополнительные аргументы для команды sed, которая меняет пути в сценариях конфигурации, установленные во время компиляции. Наследование этого класса ведет к изменению всех путей в сценариях конфигурации так, чтобы они указывали каталог sysroot, чтобы все сборки, использующие сценарий применяли корректные каталоги для кросс-компиляции. Детали применения класса приведены в файле meta/classes/binconfig.bbclass каталога исходных кодов, а базовая информация – в параграфе 6.7. binconfig.bbclass.

OE_IMPORTS

Внутренняя переменная, указывающая системе сборки OE модули Python, импортируемые для каждой функции Python, выполняемой системой. Не нужно устанавливать эту переменную.

OE_INIT_ENV_SCRIPT

Имя сценария настройки среды сборки для организации работы в расширяемом SDK (по умолчанию oe-init-build-env). Для пользовательских сценариев настройки следует указывать имя сценария в переменной.

OE_TERMINAL

Управляет вызовом интерактивных терминалов системой сборки OE на сборочном хосте (например, использование команды BitBake с опцией -c devshell). Работа с терминальными сессиями описана в разделе Using a Development Shell [2]. Переменная OE_TERMINAL может принимать значения auto, gnome, xfce, rxvt, screen, konsole, none.

OEROOT

Каталог, из которого запускается сценарий верхнего уровня для настройки окружения (oe-init-build-env). При запуске сценария переменная OEROOT преобразуется в имя каталога, где этот сценарий размещен.

OLDEST_KERNEL

Указывает минимальную версию ядра Linux, с которой будут работать собираемые двоичные файлы. Эта переменная передается в сборку встроенной библиотеки glibc. По умолчанию эта переменная принимает значение из файла meta/conf/bitbake.conf, которое можно переопределить ф файле конфигурации дистрибутива.

OVERRIDES

Список разделенных двоеточиями переопределений, которые будут применены. Переопределения в BitBake позволяют селективно изменять значения переменных при завершении анализа. Набор переопределений в переменной OVERRIDES представляет «состояние» в процессе сборки, которое включает собираемое задание, машину, для которой выполняется сборка и т. п.

Например, если строка an-override представлена как элемент списка в OVERRIDES, приведенное назначение FOO_an-override = “overridden” будет переопределять FOO значением overridden в конце анализа.

В разделе Conditional Syntax (Overrides) [4] механизм переопределения описан более подробно.

Принятое по умолчанию значение OVERRIDES включает значения переменных CLASSOVERRIDE, MACHINEOVERRIDES и DISTROOVERRIDES. Другим важным переопределением, включенным по умолчанию, является pn-${PN}. Это позволяет установить переменные для определенного задания в файлах .conf. Например, FOO_pn-myrecipe = “myrecipe-specific value”.

Простым способом узнать используемые переопределения является поиск строки OVERRIDES в выводе команды bitbake -e (см. раздел Viewing Variable Values [2]).

P

Имя и версия задания в форме ${PN}-${PV}.

PACKAGE_ARCH

Архитектура собираемых пакетов. По умолчанию для этой переменной устанавливается значение TUNE_PKGARCH при сборке пакета для целевой платформы, BUILD_ARCH при сборке для сборочного хоста и ${SDK_ARCH}-${SDKPKGSUFFIX} при сборке для SDK (см. SDK_ARCH). Однако, если выходные пакеты задания связаны с конкретной целевой системой, а не с базовой архитектурой машины, следует устанавливать в задании для PACKAGE_ARCH значение переменной MACHINE_ARCHв формеPACKAGE_ARCH = “${MACHINE_ARCH}”

PACKAGE_ARCHS

Задает список архитектур, совместимых с целевой машиной. Эта переменная устанавливается автоматически и обычно не следует менять ее вручную. Записи в списке разделяются пробелами и упорядочены по приоритету. По умолчанию переменная имеет значение ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}.

PACKAGE_BEFORE_PN

Включает легко добавляемые пакеты в PACKAGES перед ${PN} так, что эти пакеты могут указывать файлы, которые обычно включаются в принятые по умолчанию пакеты.

PACKAGE_CLASSES

Эта переменная, устанавливаемая в файле conf/local.conf каталога сборки, задает менеджер пакетов, который система сборки OE использует для упаковки. Можно указать в переменной один или несколько менеджеров, например, PACKAGE_CLASSES ?= “package_rpm package_deb package_ipk package_tar”. Хотя класс package_tar и поддерживается, его функциональность ограничена, поскольку для него не поддерживаются зависимости между пакетами в машине установки. Поэтому применять данный класс не рекомендуется.

Система сборки использует только первый элемент из списка в качестве менеджера пакетов при создании образа или SDK. Однако пакеты будут создаваться с использованием и дугих указанных менеджеров. Например, для использования менеджера пакетов IPK в файле local.conf задается строка PACKAGE_CLASSES ?= “package_ipk”.

Дополнительная информация о влиянии менеджера пакетов на производительность упаковки и сборки рассмотрена в параграфе 6.88. package.bbclass.

PACKAGE_DEBUG_SPLIT_STYLE

Определяет расщепление двоичных файлов и отладочной информации при создании пакетов *-dbg для отладчика GDB¹. Переменная позволяет управлять местом размещения отладочной информации, которая может включать исходные файлы.

.debug задает размещение отладочных символов вместе с двоичными файлами в каталоге .debug на целевой платформе. Например, при установке двоичного файла в /bin соответствующие отладочные символы будут помещены в /bin/.debug. Исходные коды помещаются в /usr/src/debug.
debug-file-directory задает размещение отладочных символов /usr/lib/debug на целевой платформе и их разделение по пути установки двоичного файла. Например, при установке двоичного файла в /bin соответствующие отладочные символы помещаются в /usr/lib/debug/bin. Исходные коды помещаются в /usr/src/debug.
debug-without-srcпохоже на .debug, но файлы исходных кодов не устанавливаются.
debug-with-srcpkg похоже на .debug, но исходные файлы помещаются в отдельный пакет *-src pkg. Этот вариант применяется по умолчанию.

Отладка с использованием GDB описана в разделе Debugging With the GNU Project Debugger (GDB) Remotely [2].

PACKAGE_EXCLUDE_COMPLEMENTARY

Блокирует установку указанных пакетов при установке дополнений. Например, при использовании IMAGE_FEATURES для установки пакетов dev- можно отказаться от инсталляции всех пакетов, кроме определенного multilib. В переменной PACKAGE_EXCLUDE_COMPLEMENTARY можно указать регулярное выражение для отбора исключаемых из установки пакетов.

PACKAGE_EXCLUDE

Указывает пакеты, которые не следует устанавливать в образ. Например, PACKAGE_EXCLUDE = “package_name package_name package_name …”. Эту переменную можно установить глобально в файле local.conf или присоединить к заданию для конкретного образа путем переопределения имени задания, как PACKAGE_EXCLUDE_pn-target_image = “package_name“.

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

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

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

PACKAGE_EXTRA_ARCHS

Задает список архитектур, совместимых с процессором устройства. Переменная полезна при сборке для нескольких разных устройств, использующих смешанные процессоры, например, XScale и ARM926-EJS.

PACKAGE_FEED_ARCHS

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

Можно использовать PACKAGE_FEEDS_ARCHS в качестве «белого списка» вариантов архитектуры пакетов. Если такой список не нужен (типичная ситуация), переменную можно опустить, что приведет к включению всех вариантов архитектуры для текущей машины из удаленного хранилища пакетов.

Рассмотрим пример, где PACKAGE_FEED_URIS, PACKAGE_FEED_BASE_PATHS и PACKAGE_FEED_ARCHS заданы в файле local.conf, как показано ниже.

     PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
                          https://example.com/packagerepos/updates"
     PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
     PACKAGE_FEED_ARCHS = "all core2-64"

С учетом этих определений идентификаторы хранилищ пакетов будут иметь вид, представленный ниже.

     https://example.com/packagerepos/release/rpm/all
     https://example.com/packagerepos/release/rpm/core2-64
     https://example.com/packagerepos/release/rpm-dev/all
     https://example.com/packagerepos/release/rpm-dev/core2-64
     https://example.com/packagerepos/updates/rpm/all
     https://example.com/packagerepos/updates/rpm/core2-64
     https://example.com/packagerepos/updates/rpm-dev/all
     https://example.com/packagerepos/updates/rpm-dev/core2-64

PACKAGE_FEED_BASE_PATHS

Задает базовый путь, используемый при создании URI хранилищ пакетов, образуя среднюю часть URI, используемых системой сборки OE. Базовый путь включается между переменными PACKAGE_FEED_URIS и PACKAGE_FEED_ARCHS.

Рассмотрим пример, где PACKAGE_FEED_URIS, PACKAGE_FEED_BASE_PATHSиPACKAGE_FEED_ARCHS определены в файле local.conf,как показано ниже.

     PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
                          https://example.com/packagerepos/updates"
     PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
     PACKAGE_FEED_ARCHS = "all core2-64"

В этом случае идентификаторы хранилищ пакетов будут иметь вид, представленный ниже.

     https://example.com/packagerepos/release/rpm/all
     https://example.com/packagerepos/release/rpm/core2-64
     https://example.com/packagerepos/release/rpm-dev/all
     https://example.com/packagerepos/release/rpm-dev/core2-64
     https://example.com/packagerepos/updates/rpm/all
     https://example.com/packagerepos/updates/rpm/core2-64
     https://example.com/packagerepos/updates/rpm-dev/all
     https://example.com/packagerepos/updates/rpm-dev/core2-64

PACKAGE_FEED_URIS

Задает начальную часть URI хранилища пакета, используемого системой сборки OE. Полный идентификатор URI включает переменные PACKAGE_FEED_URIS, PACKAGE_FEED_BASE_PATHSиPACKAGE_FEED_ARCHS.

В приведенном ниже примере переменные PACKAGE_FEED_URIS, PACKAGE_FEED_BASE_PATHSи PACKAGE_FEED_ARCHS заданы в файле local.conf.

     PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
                          https://example.com/packagerepos/updates"
     PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
     PACKAGE_FEED_ARCHS = "all core2-64"

С учетом этих установок идентификаторы хранилищ пакетов будут иметь вид, представленный ниже.

     https://example.com/packagerepos/release/rpm/all
     https://example.com/packagerepos/release/rpm/core2-64
     https://example.com/packagerepos/release/rpm-dev/all
     https://example.com/packagerepos/release/rpm-dev/core2-64
     https://example.com/packagerepos/updates/rpm/all
     https://example.com/packagerepos/updates/rpm/core2-64
     https://example.com/packagerepos/updates/rpm-dev/all
     https://example.com/packagerepos/updates/rpm-dev/core2-64

PACKAGE_GROUP

Переменная PACKAGE_GROUP была переименована в FEATURE_PACKAGES. Если вы продолжаете использовать PACKAGE_GROUP,система сборки OE будет выдавать предупреждение.

PACKAGE_INSTALL

Окончательный список пакетов, передаваемый менеджеру пакетов для установки в образ. Этот список не обязательно совпадает с полным списком устанавливаемых пакетов. Эта переменная является внутренней для кода создания образа, поэтому в общем случае следует использовать IMAGE_INSTALL для указания устанавливаемых пакетов. Исключением является работа с образом core-image-minimal-initramfs. Для образов initramfs применяется переменная PACKAGE_INSTALL (см. Building an Initial RAM Filesystem (initramfs) Image [2]).

PACKAGE_INSTALL_ATTEMPTONLY

Задает список пакетов, которые система сборки OE пытается установить при создании образа. Если установка пакета не удается, система сборки не генерирует ошибки. Эту переменную пользователь обычно не задает.

PACKAGE_PREPROCESS_FUNCS

Задает список функций предварительной обработки каталога PKGD при разделении файлов по разным пакетам.

PACKAGE_WRITE_DEPS

Задает список зависимостей для сценарией предустановки и пост-установки инструментов native/cross. Если сценарий может выполняться во время создания rootfs, а не на целевой платформе, но зависит от естественного инструмента при работе, нужно указать этот инструмент в PACKAGE_WRITE_DEPS. Работа сценариев пост-установки описана в разделе Post-Installation Scripts [2].

PACKAGECONFIG

Эта переменная обеспечивает способ управления свойствами заданий на уровне отдельного задания. Блок PACKAGECONFIG определяется в заданиях при выборе свойств и аргументов для них. Ниже показана базовая структура блока.

     PACKAGECONFIG ??= "f1 f2 f3 ..."
     PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1,rt-recs-f1"
     PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2,rt-recs-f2"
     PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3,rt-recs-f3"

Сама переменная PACKAGECONFIG задает список разделенных пробелами свойств, которые нужно включить. Для каждого свойства можно задать поведение, указав до 5 упорядоченных аргументов, разделенных запятыми. Любой аргумент можно опустить, сохраняя запятые. Для аргументов применяется показанный ниже порядок.

Дополнительные аргументы, которые следует добавить в список аргументов сценария настройки (EXTRA_OECONF или PACKAGECONFIG_CONFARGS), если свойство включено.
Дополнительные аргументы для EXTRA_OECONF или PACKAGECONFIG_CONFARGS, если свойство выключено.
Дополнительные зависимости при сборке (DEPENDS), если свойство включено.
Дополнительные зависимости при работе (RDEPENDS), если свойство включено.
Дополнительные рекомендации при работе (RRECOMMENDS), если свойство включено.

Рассмотрим блок PACKAGECONFIG из задания librsvg. В этом примере свойство croco имеет 3 аргумента, определяющих его поведение.

     PACKAGECONFIG ??= "croco"
     PACKAGECONFIG[croco] = "--with-croco,--without-croco,libcroco"

Аргументы –with-croco и libcroco применяются лишь при включенном свойстве. В этом случае –with-croco добавляется к аргументам сценария настройки, а libcroco – в DEPENDS. Если свойство отключено (например, в файле .bbappend на другом уровне, к сценарию настройки добавляется аргумент –without-croco вместо –with-croco.

Показанная выше базовая структура PACKAGECONFIG одинакова для создания и изменения блока. При создании используется структура внутри задания. Для изменения имеющегося блока PACKAGECONFIG есть два способа.

Файл добавления. Создается файл .bbappend с именем задания на вашем уровне и в нем переопределяется значение PACKAGECONFIG. Можно полностью переопределить переменную PACKAGECONFIG = “f4 f5” или добавить значение в конце PACKAGECONFIG_append = ” f4″
Файл конфигурации. Этот метод идентичен изменению блока через файл добавления, но редактируется файл local.conf или файл конфигурации дистрибутива. Можно переопределить переменную PACKAGECONFIG_pn-recipename = “f4 f5” или добавить значение в конце PACKAGECONFIG_append_pn-recipename = ” f4″

PACKAGECONFIG_CONFARGS

Список разделенных пробелами опций настройки, создаваемый из переменной PACKAGECONFIG. Классы autotools и cmake используют PACKAGECONFIG_CONFARGS для передачи опций PACKAGECONFIG командам configure и cmake, соответственно. Если вы применяете PACKAGECONFIG,но не класс, обслуживающий задачуdo_configure, нужно соответствующим образом использовать PACKAGECONFIG_CONFARGS.

PACKAGEGROUP_DISABLE_COMPLEMENTARY

Для заданий, наследующих класс packagegroup, установка PACKAGEGROUP_DISABLE_COMPLEMENTARY = “1” указывает, что обычные дополнительные пакеты (-dev, -dbgи т. п.) не следует автоматически создавать в задании packagegroup, как это принято по умолчанию.

PACKAGES

Список пакетов, создаваемых заданием. По умолчанию это ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}.

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

Пустые пакеты из списка (т. е. не соответствующие ни одному из шаблонов FILES_pkg,установленных задачей do_install) не создаются, если это явно не задано переменной ALLOW_EMPTY.

PACKAGES_DYNAMIC

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

Обычно, если возможна такая ситуация и пакета, который не был создан, был бы действительным без выполнения зависимости, следует использовать RRECOMMENDS (мягкая зависимость при работе) вместо RDEPENDS.

Пример использования PACKAGES_DYNAMIC для разделения пакетов приведен в разделе Handling Optional Module Packaging [2].

PACKAGESPLITFUNCS

Задает список функций, применяемых для дополнительного разделения файлов по отдельным пакетам. Задания могут добавлять значения в начало этой переменной или функции populate_packagesдля дополнительного разделения пакета. Во всех случаях функции следует устанавливатьPACKAGES, FILES, RDEPENDS и другие переменные управления пакетами соответствующим образом для желаемого разделения пакетов.

PARALLEL_MAKE

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

По умолчанию система сборки OE автоматически устанавливает в этой переменной число ядер сборочного хоста. Если при сборке в процессе выполнения задачи do_compile возникают проблемы с зависимостями, можно сбросить переменную PARALLEL_MAKE для задания (см. раздел Debugging Parallel Make Races [2]).

Для систем с одним процессором не следует переопределять эту переменную для использования параллельной сборки. Однако в больших системах с несколькими процессорами можно установить для переменной PARALLEL_MAKE значение -j 20. Вопросы ускорения сборки рассмотрены в разделе Speeding Up a Build [2].

PARALLEL_MAKEINST

Опции, передаваемые команде make install в задаче do_install для использования параллельной установки. По умолчанию переменная принимает значение PARALLEL_MAKE. Для учета PARALLEL_MAKEINST команда make должна вызываться с ${EXTRA_OEMAKE},для чего можно просто использовать функциюoe_runmake.

Если при сборке программы возникают проблемы с зависимостями в задаче do_install,можно просто сбросить переменнуюPARALLEL_MAKEINST в задании (см. раздел Debugging Parallel Make Races [2]).

PATCHRESOLVE

Задает действие при отказе наложения изменений (patch) и может принимать значение noop или user. Принятое по умолчанию значение noop просто останавливает сборку, когда система OE не может применить исправление. Установка значения user заставляет систему сборку запустить консоль (shell) с переходом в нужный каталог для исправления конфликта вручную. Переменная задана в файле local.conf.

PATCHTOOL

Задает утилиту для применения исправлений (patch) во время выполнения задачи do_patch(patch, quilt или git). По умолчанию используется утилита quilt для всех заданий, кроме quilt-native, для которого применяется patch, поскольку инструмент quilt недоступен во время исправления quilt-native. Для использования определенной утилиты можно указать PATCHTOOL = “patch”, PATCHTOOL = “quilt” или PATCHTOOL = “git”.

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

Задает имя задания или пакета с включением номера версии и выпуска (glibc-2.13-r20+svnr15508/ или bash-4.2-r1/) в форме ${PN}-${EXTENDPE}${PV}-${PR}.

PIXBUF_PACKAGES

При наследовании класса pixbufcache переменная указывает пакеты, содержащие загрузчики pixbuf, используемые gdk-pixbuf. По умолчанию класс pixbufcache предполагает загрузчики из основного пакета задания (${PN}), а эта переменная позволяет указать другие пакеты.

PKG

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

PKG_CONFIG_PATH

Путь к файлам pkg-config для текущего контекста сборки. Программа pkg-config читает переменную из окружения.

PKGD

Указывает целевой каталог для упаковываемых файлов, которые будут разделены на отдельные пакеты. По умолчанию используется значение ${WORKDIR}/package, которое не следует менять.

PKGDATA_DIR

Указывает общий каталог данных глобального состояния, генерируемый в процессе упаковки. В этом процессе задача do_packagedata упаковывает данные для каждого задания и помещает их в эту общую временную область. По умолчанию эта переменная имеет значение ${STAGING_DIR_HOST}/pkgdata, менять которое не следует. Примеры использования этих данных приведены в разделах Automatically Added Runtime Dependencies [1] и Viewing Package Information with oe-pkgdata-util [2]. Информация о каталоге глобальных состояний приведена в описании переменной STAGING_DIR_HOST.

PKGDEST

Указывает родительский каталог для упаковываемых файлов после разделения их по отдельным пакетам. По умолчанию это каталог ${WORKDIR}/packages-split, в котором система сборки создает каталог для каждого пакета из PACKAGES. Менять имя этого каталога не следует.

PKGDESTWORK

Указывает временную рабочую область, где задача do_package сохраняет метаданные пакета. По умолчанию переменная PKGDESTWORK имеет значение ${WORKDIR}/pkgdata, которое не следует менять. Задача do_packagedata task копирует метаданные из PKGDESTWORK в PKGDATA_DIR для глобальной доступности.

PKGE

Эпоха, для которой пакет(ы) собирается заданием. По умолчанию значением PKGE является значение PE.

PKGR

Выпуск (revision) пакета, собираемого заданием. По умолчанию значением PKGR является значение PR.

PKGV

Номер версии пакета (пакетов), собираемого заданием. По умолчанию PKGV принимает значение переменной PV.

Назначение этой переменной может меняться в зависимости от контекста – имя задания или получаемого в результате пакета.

PN указывает имя задания в контексте файла, используемого системой сборки OE в качестве входного для создания пакета. Имя обычно извлекается из имени файла задания. Например для задания с именем expat_2.0.1.bb по умолчанию значением PN будет expat.

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

Когда это применимо, переменная PN включает специальный суффикс или префикс. Например, при использовании bash для сборки пакетов для естественной машины PN будет bash-native, а при использовании bash для сборки пакетов для цели и для Multilib значением PN будет bash и lib64-bash, соответственно.

PNBLACKLIST

Перечисляет задания, которые не нужно собирать в системе OE. Переменная работает вместе с классом blacklist,наследуемым глобально. Переменная PNBLACKLIST задается в файле local.conf. Например, для предотвращения сборки myrecipeслужитPNBLACKLIST[myrecipe] = “Not supported by our organization.”.

POPULATE_SDK_POST_HOST_COMMAND

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

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

POPULATE_SDK_POST_TARGET_COMMAND

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

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

Номер пересмотра (изменения) задания. По умолчанию используется значение r0, а последующие варианты имеют номера r1, r2 и т. д. При увеличении переменной PV значение PR обычно сбрасывается в r0.

Системе сборки OE не нужно знать PR для принятия решения о пересборке пакета, для этого служат входные контрольные суммы задания [1] вместе с механизмами stamp (5.2.20. build/tmp/stamps/) и кэширования общих состояний [1].

Переменная PR приобретает важное значение, когда менеджер пакетов динамически устанавливает программы в уже созданном образе. В таких случаях PR, которая по умолчанию имеет значение переменной PKGR, помогает менеджеру определить, какой пакет является более свежим, если имеется несколько пакетов с совпадающими номерами PV (PKGV). Наличие множества пакетов с одним PV обычно говорит о том, что пакеты имеют одну исходную версию, но различаются номерами вариантов (PR), которые могут включать изменения.

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

Поскольку ручное управление PR громоздко и подвержено ошибкам, имеется автоматизированное решение (Working With a PR Service [2]).

PREFERRED_PROVIDER

Если один элемент обеспечивается несколькими заданиями, эта переменная позволяет указать предпочтительное задание, что обеспечивает выбор элемента (предпочтительного поставщика). В переменной всегда следует использовать суффикс в форме имени предоставляемого элемента и указывать предпочтительное задание (PN), например, PREFERRED_PROVIDER_virtual/kernel ?= “linux-yocto”. Здесь элемент virtual/kernel предоставляется несколькими заданиями и переменная PREFERRED_PROVIDER указывает имя (PN), задания, предпочитаемого для обеспечения virtual/kernel.

Ниже приведены еще два примера.

     PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
     PREFERRED_PROVIDER_virtual/libgl ?= "mesa"

Дополнительные сведения о работе с виртуальными провайдерами приведены в разделе Using Virtual Providers [2].

При использовании элемента virtual/* с переменной PREFERRED_PROVIDERзадание, которые включают этот элемент в PROVIDES,но не были выбраны переменнойPREFERRED_PROVIDER,не будут собираться.

PREFERRED_VERSION

При наличии нескольких версий заданий эта переменная указывает предпочтительную версию. Переменная всегда указывается с PNзадания и указанием предпочтительной версииPV. Переменная поддерживает ограниченное использование символа %в качестве шаблона. Этому шаблону может соответствовать любое число символов, что может быть полезно при указании версий с длинными номерами, которые могут изменяться. Ниже приведены два примера.

     PREFERRED_VERSION_python = "3.4.0"
     PREFERRED_VERSION_linux-yocto = "4.12%"

Символ % можно указывать лишь в конце строки.

Указанная версия сопоставляется со значением PV, которое не обязательно совпадает с версией в имени задания. Рассмотрим в качестве примера задания foo_1.2.bb и foo_git.bb, где foo_git.bb включает PV = “1.1+git${SRCPV}”. В этом случае корректным способом выбора foo_git.bb будет указание PREFERRED_VERSION_foo = “1.1+git%”. Если же указать PREFERRED_VERSION_foo = “git”, это не будет работать.

Иногда переменная PREFERRED_VERSION может устанавливаться конфигурационными файлами так, что ее сложно изменить. В таких случаях можно использовать переменную OVERRIDES для машинозависимого переопределения, например, PREFERRED_VERSION_linux-yocto_qemux86 = “4.12%”

Хотя это и не рекомендуется, в крайнем случае можно воспользоваться переопределением forcevariable, которое является наиболее сильным из переопределений. Например, можно задать PREFERRED_VERSION_linux-yocto_forcevariable = “4.12%”. Переопределение _forcevariable не получает особой обработки и действует лишь потому, что значение OVERRIDES по умолчанию включает forcevariable.

PREMIRRORS

Задает дополнительные пути для поиска исходных кодов системой сборки OE, которая сначала пытается найти коды в локальном каталоге загрузки. При отсутствии кодов в этом каталоге система просматривает репозитории, указанные переменной PREMIRRORS, затем «восходящий источник» и репозитории, указанные переменной MIRRORS.

Предположим, что используется дистрибутив (DISTRO) poky, для которого принятое по умолчанию значение PREMIRRORS указано в файле conf/distro/poky.conf репозитория meta-poky. Можно добавить нужные серверы в начало списка, указав их в файле local.conf в каталоге сборки, как показано ниже.

     PREMIRRORS_prepend = "\
     git://.*/.* http://www.yoctoproject.org/sources/ \n \
     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
     http://.*/.* http://www.yoctoproject.org/sources/ \n \
     https://.*/.* http://www.yoctoproject.org/sources/ \n"

Эти изменения заставят систему сборки перехватывать запросы Git, FTP, HTTP, HTTPS и направлять их на указанное зеркало http://. Можно использовать URL типа file:// для указания локальных или сетевых каталогов.

PRIORITY

Указывает уровень важности пакета. Переменная PRIORITY считается частью политики дистрибутива, поскольку важность любого задания зависит от целей дистрибутива. Поэтому PRIORITY обычно не указывается в заданиях. Переменная может принимать значения required (требуется), standard (стандартный уровень), extra (дополнение) и optional (не обязательно, используется по умолчанию).

PRIVATE_LIBS

Задает установленные в задании библиотеки, которые следует игнорировать распознавателю общих библиотек системы сборки OE. Переменная обычно применяется в тех случаях, когда создаваемые заданием программы имеют свои версии библиотек, обычно создаваемых другим заданием. В таких случаях следует исключить зависимость от пакета со своими библиотеками не связанных с ним пакетов, которые обычно зависят от стандартных версий библиотек. Библиотеки в этой переменной следует указывать именами файлов. Ниже приведен пример из задания Firefox в meta-browser.

     PRIVATE_LIBS = "libmozjs.so \
                     libxpcom.so \
                     libnspr4.so \
                     libxul.so \
                     libmozalloc.so \
                     libplc4.so \
                     libplds4.so"

Дополнительная информация представлена в разделе Automatically Added Runtime Dependencies [1].

PROVIDES

Список псевдонимов, под которыми может быть известно определенное задание. По умолчанию значение PN для задания неявно уже присутствует в списке PROVIDES. Если задание использует PROVIDES, дополнительные псевдонимы являются синонимами для задания и могут быть полезны для выполнения зависимостей других заданий в процессе сборки, указанных в DEPENDS.

В задании libav_0.8.11.bb указано PROVIDES += “libpostproc”, в результате чего libav имеет псевдоним libpostproc.

Кроме дополнительных имен для заданий механизм PROVIDES применяется также для реализации виртуальных целей, которые являются именами, соответствующими некой определенной функциональности (например, ядро Linux). Задания, обеспечивающие соответствующую функциональность, указывают виртуальную цель в PROVIDES. Задания, зависящие от рассматриваемой функциональности, могут включать виртуальную цель в DEPENDS, оставляя выбор поставщика открытым. Обычно виртуальные цели имеют имена вида virtual/function (например, virtual/kernel). Символ дробной черты (/) просто является частью имени и не имеет синтаксического значения. Переменная PREFERRED_PROVIDER служит для выбора конкретного задания, обеспечивающего виртуальную цель.

Имеется соответствующий механизм для виртуальных зависимостей (пакетов) во время выполнения. Однако этот механизм не зависит от какой-либо особой функциональности обычного назначения переменных. Например, VIRTUAL-RUNTIME_dev_manager указывает пакет, который управляет каталогом /dev. Установка «предпочтительного поставщика» для зависимостей во время исполнения так же проста, как назначение в конфигурационном файле VIRTUAL-RUNTIME_dev_manager = “udev”.

PRSERV_HOST

Хост и порт сетевой службы PR.В файлеconf/local.conf.sample.extended каталога исходных кодов переменная задана в виде PRSERV_HOST = “localhost:0”. Эту переменную нужно устанавливать при необходимости автоматического запуска локальной службы PR. Можно указать также значения для удаленной службы PR.

PTEST_ENABLED

Управляет включением функциональности тестирования пакетов (ptest) при сборке задания. Переменную не следует задавать напрямую, поскольку управление тестированием пакетов при сборке задается добавлением (или удалением) ptest в переменную DISTRO_FEATURES.

Номер версии задания. Обычно номер версии извлекается из имени файла задания. Например, для задания expat_2.0.1.bbпеременнаяPV по умолчанию будет иметь значение 2.0.1. Значение PV обычно не переопределяется в задании, если сборка не является нестабильной (рабочей) из репозитория исходных кодов), например, Git или Subversion.

ЗначениеPV используется по умолчанию для переменной PKGV.

PYTHON_ABI

При использовании в заданиях, наследующих класс distutils3, setuptools3, distutilsилиsetuptools, указывает интерфейс ABI, используемый для Python (по умолчанию “m”). Переменную не нужно задавать, это делает OE.

Система сборки OE применяет ABI для задания имен каталогов, используемых при установке заголовков и библиотек Python в (например .../python3.3m/...).

Задания, наследующие класс distutils, при кросс-сборке также используют эту переменную для поиска заголовков и библиотек версии Python, для которой предназначено расширение.

PYTHON_PN

При использовании в заданиях, наследующих класс distutils3, setuptools3, distutilsилиsetuptools, указывает старшую версию Python для сборки. Для Python 2.x переменная PYTHON_PN будет иметь значение python2, для Python 3.x – python3. Если переменная не установлена, система сборки OE сделает это автоматически.

Переменная позволяет заданиям использовать общую инфраструктуру, в форме DEPENDS += “${PYTHON_PN}-native”, где PYTHON_PNуказывает версию зависимости.

R

RANLIB

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

RCONFLICTS

Список пакетов, конфликтующих с другими пакетами. Установка пакетов будет блокироваться до устранения конфликтов. Как и другие переменные управления пакетами, RCONFLICTS нужно всегда указывать с переопределением имени пакета, например, RCONFLICTS_${PN} = “another_conflicting_package_name“.

BitBake поддерживает указание зависимостей с учетом версии. Синтаксис зависит от формата пакетов, но BitBake скрывает эти различия. Базовый синтаксис указания версии имеет вид RCONFLICTS_${PN} = “package (operator version)”. Оператором может служить =, <, >, <= или >=.

Например, для указания зависимости от версии 1.2 или выше для пакета fooможно задатьRCONFLICTS_${PN} = “foo (>= 1.2)”.

RDEPENDS

Список зависимостей пакета во время выполнения. Эти зависимости указывают пакеты, которые должны быть установлены для корректной работы данного пакета. Например, приведенная ниже строка указывает зависимость работы пакета foo от наличия установленных пакетов bar и baz.

     RDEPENDS_foo = "bar baz"

Наиболее распространенные зависимости пакетов во время исполнения обнаруживаются и добавляются автоматически, поэтому в большинстве задания переменная RDEPENDSне нужна. Зависимости более подробно рассмотрены в разделе Automatically Added Runtime Dependencies [1].

Практическое влияние приведенного выше примера RDEPENDS состоит в том, что пакеты bar и baz объявляются зависимостями в пакете foo,когда он будет записан одной из задачdo_package_write_*. Способ выполнения этого зависит от используемого формата пакета, который определяется переменной PACKAGE_CLASSES. Когда соответствующий менеджер устанавливает пакет, он знает, что нужно установить пакеты, от которых тот зависит.

Чтобы обеспечить сборку пакетов bar и baz,предыдущий пример RDEPENDS также вызывает добавление зависимости задач. Это зависимость задачи do_build для задания (не путайте с do_compile) от задач do_package_write_* заданий сборки bar и baz.

Имена в переменной RDEPENDS должны указывать другие пакеты – это не могут быть имена заданий. Хотя имена пакетов и заданий могут совпадать, важно отметить, что в переменной RDEPENDS указываются именно пакеты. Подробный список пакетов, создаваемых заданием, можно узнать из переменной PACKAGES.

Поскольку переменная RDEPENDS применяется к собираемым пакетам, ее следует использовать с именем пакета в конце (помните, что одно задание может собирать несколько пакетов). Предположим, например, сборку пакета для разработки, который зависит от perl. В этом случае используется оператор RDEPENDS вида

     RDEPENDS_${PN}-dev += "perl"

В этом примере пакет для разработки зависит от пакета perl. Таким образом, RDEPENDS включает ${PN}-devкак часть переменной. RDEPENDS_${PN}-dev включает ${PN} по умолчанию, что устанавливается в конфигурационном файле BitBake (meta/conf/bitbake.conf). Соблюдайте осторожность, чтобы случайно не удалить ${PN} при изменении RDEPENDS_${PN}-dev. Следует также применять оператор +=, а не просто =.

Имена пакетов в переменной RDEPENDS должны указывать в том виде, как они представлены в PACKAGES. Переменная PKG разрещает использовать для финального пакета другое имя (например, класс debian использует ее для переименования пакетов), но это окончательное имя пакета не может использоваться в RDEPENDS, поскольку эта переменная предполагает независимость от применяемого формата пакетов.

Программа BitBake, используемая системой сборки OE, поддерживает в зависимостях указание версий. Хотя синтаксис версии зависит от формата упаковки, BitBake скрывает эту зависимость. Базовый синтаксис указания версии имеет видRDEPENDS_${PN} = “package (operator version)”.

Оператором может служить =, <, >, <= или >=, версия указывается номером. Можно использовать переменную EXTENDPKGV для полного указания версии пакета. Например, для указания зависимости от версии 1.2 или выше для пакета fooможно задатьRDEPENDS_${PN} = “foo (>= 1.2)”.

Информация о зависимостях во время сборки задается переменной DEPENDS.Дополнительные сведения о задачах и зависимостях приведены в разделахTasks и Dependencies [4].

REQUIRED_DISTRO_FEATURES

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

RM_WORK_EXCLUDE

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

ROOT_HOME

Задает корневой каталог root. По умолчанию каталог указывается в конфигурационном файле BitBake как ROOT_HOME ??= “/home/root”. Заданное по умолчанию значение вероятно будет использоваться, поскольку некоторые встраиваемые системы предпочитают создавать корневую файловую систему, доступную лишь для чтения, и хранить перезаписываемые данные в отдельном месте. Переменную можно переопределить на любом уровне или в файле local.conf. Поскольку для заданного по умолчанию значения используется «мягкое» назначение (??”), для переопределения можно указать любой из приведенных ниже вариантов.

     ROOT_HOME = "/root"
     ROOT_HOME ?= "/root"

ROOTFS

Указывает образ файловой системы для включения в корневую файловую системы. Переменная является необязательной и применяется с классом image-live.

ROOTFS_POSTINSTALL_COMMAND

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

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

ROOTFS_POSTPROCESS_COMMAND

Задает список функций для однократного вызова системой сборки OE при создании корневой файловой системы. Функции разделяются символом точки с запятой (;), например, ROOTFS_POSTPROCESS_COMMAND += “function; … “. Если нужно передать путь к корневой файловой системе команде с функцией, можно использовать переменную ${IMAGE_ROOTFS}, указывающую каталог, который станет корневой файловой системой образа.

ROOTFS_POSTUNINSTALL_COMMAND

Задает список функций, вызываемых после удаления системой сборки OE ненужных приложений. Когда менеджер пакетов при работе системы (runtime) отключен в образе, удаляется несколько пакетов, включая base-passwd, shadowиupdate-alternatives. Функции разделяются символом точки с запятой (;), например, ROOTFS_POSTUNINSTALL_COMMAND += “function; … “.

ROOTFS_PREPROCESS_COMMAND

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

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

RPROVIDES

Список псевдонимов имен пакетов, которые полезны для выполнения зависимостей во время работы как при сборке, так и на целевой платформе (как указано переменной RDEPENDS). Реальное имя пакета неявно уже присутствует в списке RPROVIDES.

Как и другие переменных управления пакетами, RPROVIDES всегда нужно использовать в сочетании с переопределением имени пакета, например, RPROVIDES_${PN} = “widget-abi-2”.

RRECOMMENDS

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

Менеджер пакетов будет автоматически устанавливать пакеты из списка RRECOMMENDS при установке собираемого пакета. Однако можно предотвратить установку пакетов из списка с помощью переменных BAD_RECOMMENDATIONS, NO_RECOMMENDATIONS и PACKAGE_EXCLUDE.

Пакеты, указанные в RRECOMMENDS не обязательно создавать в действительности, однако должно существовать задание для каждого из этих пакетов в переменной PACKAGES, PACKAGES_DYNAMIC или RPROVIDES, иначе возникнет ошибка. Если задание имеется, но пакет не создается, сборка продолжится без ошибки.

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

RRECOMMENDS_${PN}-dev += "wireless_package_name"

В этом примере имя пакета (${PN}-dev) должно представляться как в пространстве имен PACKAGES до какого-либо переименования выходного пакета классами, такими как debian.bbclass.

BitBake, использующий систему сборки OE, поддерживает указание нужной версии. Хотя синтаксис такого указания зависит от формата упаковки, BitBake скрывает эти различия от вас. Ниже показан базовый синтаксис задания версии в переменной RRECOMMENDS.

RRECOMMENDS_${PN} = "package (operator version)"

В качестве оператора можно использовать =, <, >, <=, >=.

Например, приведенная ниже строка рекомендует версии не ниже 1.2 для пакета foo.

     RRECOMMENDS_${PN} = "foo (>= 1.2)"

RREPLACES

Список пакетов, заменяемых данным пакетом. Менеджер пакетов применяет эту переменную для определения пакетов, которые следует установить взамен других в процессе обновления. Для одновременного удаления других пакетов нужно добавить их имена в переменную RCONFLICTS. Как и другие переменные управления пакетами, RREPLACES требуется применять вместе с переопределением имени пакета, например, RREPLACES_${PN} = “other_package_being_replaced“.

BitBake поддерживает указание версий при замене. Синтаксис зависит от формата пакетов, однако BitBake маскирует эти различия. Общий синтаксис указания версий имеет вид RREPLACES_${PN} = “package (operator version)”. В качестве оператора можно использовать =, <, >, <=, >=.

Например, строка RREPLACES_${PN} = “foo (>= 1.2)” рекомендует версии не ниже 1.2 для пакета foo.

RSUGGESTS

Список дополнительных пакетов, которые можно предложить при установке менеджеру пакетов во время инсталляции данного пакета. Функциональность поддерживают не все менеджеры пакетов. Как и другие переменные управления пакетами, RSUGGESTS требуется применять вместе с переопределением имени пакета.

RSUGGESTS_${PN} = "useful_package another_package"

S

Место в каталоге сборки, где размещаются неупакованные исходные коды задания. По умолчанию это каталог ${WORKDIR}/${BPN}-${PV}, где ${BPN} – базовое имя задания, а ${PV} – версия задания. Если из архива исходных кодов файлы извлечены в каталог, имя которого отличается от ${BPN}-${PV}, или исходный код получен из SCM (например, Git или Subversion), нужно установит переменную S в задании так, чтобы система сборки OE знала, где искать неупакованные исходные файлы.

Предположим, например, что каталог верхнего уровня в дереве исходных кодов называется poky, а принятым по умолчанию каталогом сборки служит poky/build. В этом случае рабочим каталогом системы сборки, используемым для хранения распакованного задания для db, будет poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19

Распакованные исходные файлы размещаются в каталоге db-5.1.19.

В следующем примере предполагается репозиторий Git. По умолчанию такие репозитории клонируются в ${WORKDIR}/git задачей do_fetch. Поскольку этот путь отличается от принятого по умолчанию значения S, нужно указать его как место размещения исходных кодов

     SRC_URI = "git://path/to/repo.git"
     S = "${WORKDIR}/git"

SANITY_REQUIRED_UTILITIES

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

SANITY_TESTED_DISTROS

Список идентификаторов дистрибутивов, для которых система сборки была протестирована. Идентификатор состоит из идентификатора дистрибутива, за которым следует номер выпуска, указанный инструментом lsb_release или прочитанный из файла /etc/lsb-release. Элементы списка задаются по одному в строках, завершающихся символом перевода строки (\n). Если строка SANITY_TESTED_DISTROS не пуста, а текущее значение NATIVELSBSTRING не присутствует в списке, система сборки выдает предупреждение, указывающее, что текущий дистрибутив не был проверен как хост сборки.

SDK_ARCH

Целевая архитектура для SDK. Обычно эта переменная не устанавливается напрямую и взамен применяется SDKMACHINE.

SDK_DEPLOY

Созданный и используемый классом populate_sdk_base каталог, в котором разворачивается SDK. Класс populate_sdk_base определяет переменную как SDK_DEPLOY = “${TMPDIR}/deploy/sdk”.

SDK_DIR

Родительский каталог, используемый системой сборки OE при выводе SDK. Класс populate_sdk_base определяет переменную как SDK_DIR = “${WORKDIR}/sdk”. Этот каталог является временным как часть WORKDIR,окончательный вывод помещается вSDK_DEPLOY.

SDK_EXT_TYPE

Управляет копированием элементов общего состояния в eSDK. При заданном по умолчанию значении full копируются все нужные элементы общего состояния, значение minimal оставляет элементы за пределами SDK.

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

SDK_HOST_MANIFEST

Файл манифеста для хостовой части SDK, содержащий все установленные пакеты, которые делают хост частью SDK. Пакеты указываются по одному в строке в форме packagename packagearch version. Класс populate_sdk_base определяет файл манифеста как SDK_HOST_MANIFEST = “${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest”. Расположение файла выводится из переменных SDK_DEPLOY и TOOLCHAIN_OUTPUTNAME.

SDK_INCLUDE_PKGDATA

Значение 1 задает включение packagedata для всех заданий цели world в расширяемом SDK. Это позволяет команде devtool search находить эти задания, а также позволяет команде devtool add более эффективно отображать зависимости.

Включение SDK_INCLUDE_PKGDATA существенно увеличивает время сборки, потому что требуется собирать все задания из world. Размер eSDK также возрастает.

SDK_INCLUDE_TOOLCHAIN

Значение 1 задает включение инструментария в расширяемый SDK. Это особенно полезно при установке в SDK_EXT_TYPE значения minimal для снижения размера SDK, когда есть также необходимость в инструментарии. Например, может быть нужно включение инструментария из IDE или другого набора без дополнительных действий по установке инструментов. По умолчанию переменная имеет значение 0, если для SDK_EXT_TYPE выбрано значение minimal, и 1 для SDK_EXT_TYPE = “full”.

SDK_INHERIT_BLACKLIST

Список классов для глобального удаления из значения INHERIT в конфигурации расширяемых SDK. Принятое по умолчанию значение задает класс populate-sdk-ext в форме SDK_INHERIT_BLACKLIST ?= “buildhistory icecc”. Некоторые классы обычно не применимы в контексте расширяемых SDK и из можно отключить этой переменной.

Дополнительные сведения о настройке расширяемых SDK приведена в разделе Configuring the Extensible SDK [7].

SDK_LOCAL_CONF_BLACKLIST

Список переменных, которые не разрешено передавать из системы сборки OE в конфигурацию расширяемых SDK. Обычно эти переменные связаны с машиной, на которой работает система сборки, и поэтому могут создавать проблемы в расширяемых SDK. По умолчанию переменная устанавливается классом populate-sdk-ext в форме

     CONF_VERSION
     BB_NUMBER_THREADS
     BB_NUMBER_PARSE_THREADS
     PARALLEL_MAKE
     PRSERV_HOST
     SSTATE_MIRRORS
     DL_DIR
     SSTATE_DIR
     TMPDIR
     BB_SERVER_TIMEOUT

Дополнительные сведения о настройке расширяемых SDK приведена в разделе Configuring the Extensible SDK [7].

SDK_LOCAL_CONF_WHITELIST

Список переменных, передаваемых из системы сборки OE в конфигурацию расширяемых SDK. По умолчанию пустой список устанавливается классом populate-sdk-ext. Этот список переопределяет переменные, заданные с помощью SDK_LOCAL_CONF_BLACKLIST,а также другие переменные, автоматически включаемые в «черный список» символом/ в начале значения, который обычно указывает путь и поэтому не пригоден для системы, где будет устанавливаться SDK.

Дополнительные сведения о настройке расширяемых SDK приведена в разделе Configuring the Extensible SDK [7].

SDK_NAME

Базовое имя для выходных файлов SDK, которое выводится из переменных DISTRO, TCLIBC, SDK_ARCH, IMAGE_BASENAMEи TUNE_PKGARCH,как показано ниже.

     SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"

SDK_OS

Задает операционную систему, для которой собирается SDK (по умолчанию значение BUILD_OS).

SDK_OUTPUT

Место, используемое системой сборки OE для вывода SDK. Класс populate_sdk_base определяет переменную, как показано ниже.

     SDK_DIR = "${WORKDIR}/sdk"
     SDK_OUTPUT = "${SDK_DIR}/image"
     SDK_DEPLOY = "${DEPLOY_DIR}/sdk"

Каталог SDK_OUTPUT служит временным каталогом, являясь частью WORKDIR через SDK_DIR. Финальный вывод записывается в SDK_DEPLOY.

SDK_PACKAGE_ARCHS

Задает список вариантов архитектуры, совместимых с машиной SDK. Переменная устанавливается автоматически и обычно ее не нужно редактировать. Элементы разделяются пробелами и указаны по приоритету. По умолчанию установлено значение “all any noarch ${SDK_ARCH}-${SDKPKGSUFFIX}”.

SDK_POSTPROCESS_COMMAND

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

SDK_PREFIX

Префикс двоичных файлов инструментария для заданий nativesdk(по умолчанию ${SDK_SYS}-). Система сборки OE использует значение SDK_PREFIX для установки TARGET_PREFIX при сборке заданий nativesdk.

SDK_RECRDEP_TASKS

Список задач общего состояния, добавленных в расширяемый SDK. По умолчанию добавляются задачи do_populate_lic, do_package_qa, do_populate_sysroot и do_deploy, несмотря на принятое по умолчанию значение “”. Для добавления других задач нужно указать их в переменной (например, при создании задач, которые нужно включить в SDK_TARGETS).

SDK_SYS

Указывает систему, для которой будет собираться SDK, включая архитектуру и ОС. Система сборки OE автоматически устанавливает эту переменную на основе SDK_ARCH, SDK_VENDORиSDK_OS.

SDK_TARGET_MANIFEST

Файл манифеста для целевой части SDK, где указаны все установленные пакеты, составляющие целевую часть SDK. Пакеты указываются по одному в строке в форме packagename packagearch version.Классpopulate_sdk_base задает файл как SDK_TARGET_MANIFEST = “${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest”. Местоположение выводится из переменных SDK_DEPLOY и TOOLCHAIN_OUTPUTNAME.

SDK_TARGETS

Список целей для установки из общего состояния как части установки стандартного или расширяемого SDK. По умолчанию установлено значение “${PN}” (образ, из которого собран SDK). Переменная является внутренней и обычно не меняется.

SDK_TITLE

Заголовок, выводимый при запуске установщика SDK. По умолчанию этот заголовок основан на значении переменной DISTRO_NAME или DISTRO и задается классом populate_sdk_base в форме SDK_TITLE ??= “${@d.getVar(‘DISTRO_NAME’) or d.getVar(‘DISTRO’)} SDK”. Для дистрибутива poky переменная SDK_TITLE имеет значение Poky (Yocto Project Reference Distro). Способы смены принятого по умолчанию значения описаны в разделе Changing the Extensible SDK Installer Title [7].

SDK_UPDATE_URL

Необязательный идентификатор URL сервера обновления для расширяемого SDK. Если переменная установлена, ее значение используется в качестве принятого по умолчанию сервера обновления командой devtool sdk-update.

SDK_VENDOR

Задает имя производителя SDK.

SDK_VERSION

Задает версию SDK. Конфигурационные файлы дистрибутивов (например, /meta-poky/conf/distro/poky.conf) задают переменную в виде SDK_VERSION = “${@d.getVar(‘DISTRO_VERSION’).replace(‘snapshot-${DATE}’,’snapshot’)}”.

SDKEXTPATH

Принятый по умолчанию каталог для установки расширяемого SDK. По умолчанию эта переменная базируется на переменной DISTRO и задается классом populate_sdk_base как SDKEXTPATH ??= “~/${@d.getVar(‘DISTRO’)}_sdk”. Для дистрибутива poky переменная имеет значение poky_sdk.

Смена принятого по умолчанию каталога описана в разделе Changing the Default SDK Installation Directory [7].

SDKIMAGE_FEATURES

Эквивалент IMAGE_FEATURES для SDK, созданных из образа по команде bitbake -c populate_sdk imagename.

SDKMACHINE

Машина, для которой собирается SDK. Иными словами, SDK собирается так, чтобы работать на целевой платформе, заданной значением SDKMACHINE, указывающим
нужный файл .conf из conf/machine-sdk/.

Можно использовать i686 и x86_64 в качестве значения этой переменной. Используемое по умолчанию значение i686 задается в файле local.conf сборочного каталоге.

     SDKMACHINE ?= "i686"

Не следует устанавливать переменную SDKMACHINE в конфигурационном файле дистрибутива, поскольку такая установка не будет работать.

SDKPATH

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

SDKTARGETSYSROOT

Полный путь к каталогу sysroot, используемый для кросс-компиляции в SDK, как при инсталляции в принятый по умолчанию SDKPATH.

SECTION

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

SELECTED_OPTIMIZATION

Задает флаги оптимизации, передаваемые компилятору C при сборке для цели. Флаги передаются в принятом по умолчанию значении TARGET_CFLAGS. Переменная SELECTED_OPTIMIZATION принимает значение FULL_OPTIMIZATION, если на задано DEBUG_BUILD = “1”. В последнем случае используется значение DEBUG_OPTIMIZATION.

SERIAL_CONSOLE

Указывает последовательную консоль (TTY) для использования getty. В значении следует указать скорость, затем устройство TTY через пробел. Указать можно лишь один порт, например, SERIAL_CONSOLE = “115200 ttyS0”. Переменная SERIAL_CONSOLE отменена и взамен следует использовать SERIAL_CONSOLES.

SERIAL_CONSOLES

Указывает последовательные консоли (TTY) для использования getty. В значении следует указать скорость, затем устройство TTY через точку с запятой. Порты разделяются пробелами, например, SERIAL_CONSOLES = “115200;ttyS0 115200;ttyS1”.

SERIAL_CONSOLES_CHECK

Задает последовательные консоли, которые должны быть указаны в SERIAL_CONSOLES, для сравнения с /proc/console перед включением и использованием getty. Переменная поддерживает псевдонимы в формате <device>:<alias>. Если устройство указано как sclp_line0 в /dev/ и ttyS0 задана в /proc/console, нужно указать SERIAL_CONSOLES_CHECK = “slcp_line0:ttyS0”. Переменная поддерживается только с SysVinit (не systemd).

SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS

Список зависимостей задания, которые не должны учитываться при определении подписей задач из одного задания, когда они зависят от задач из другого задания. Например, SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += “intone->mplayer2”, где intone зависит от mplayer2. Можно применять специальный маркер * слава от зависимости, которому будут соответствовать все задания, кроме указанного справа, например, SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += “*->quilt-native”. Здесь все задания, кроме quilt-native игнорируют подписи задач из quilt-native при определении своих подписей. Использование этой переменной является одним из способов удаления зависимостей, влияющих на подписи задач и требующих повторной сборки при изменении заданий. При добавлении в этот список неподходящего задания при работе программ могут возникать ошибки, если интерфейс задания будет изменен после сборки другого задания.

SIGGEN_EXCLUDERECIPES_ABISAFE

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

SITEINFO_BITS

Задает разрядность CPU в целевой системе (32 или 64).

SITEINFO_ENDIANNESS

Задает порядок байтов на целевой системе и может принимать значение le (little-endian) или be (big-endian).

SKIP_FILEDEPS

Включает удаление всех файлов из раздела Provides пакета RPM. Удаление этих файлов требуется для пакетов, включающих заранее собранные исполняемые файлы и библиотеки, такие как libstdc++ и glibc. Чтобы включить удаление, нужно в файле сборочного каталога conf/local.conf задать SKIP_FILEDEPS = “1”.

SOC_FAMILY

Группирует машины на основе семейства SOC² и обычно задается в общем файле .inc,включаемом в конфигурационные файлы всех машин. Нужно включить файл conf/machine/include/soc-family.inc,чтобы эта переменная появилась вMACHINEOVERRIDES.

SOLIBS

Задает суффикс для общих библиотек на целевой платформе. Принятый по умолчанию суффикс .so для систем Linux определен в файле meta/conf/bitbake.conf. Эта переменная используется в принятых по умолчанию значениях FILES_${PN}.

SOLIBSDEV

Задает суффикс для символьной ссылки на общую библиотеку разработки для целевой платформы. Принятый по умолчанию суффикс .so для систем Linux определен в файле meta/conf/bitbake.conf. Эта переменная используется в принятых по умолчанию значениях FILES_${PN}-dev.

SOURCE_MIRROR_FETCH

При выборке файлов для создания зеркала исходных кодов установка SOURCE_MIRROR_FETCH = “1” в файле local.conf обеспечивает выбор исходных кодов всех заданий независимо от совместимости с конфигурацией. Задание считается не совместимым с настроенной в данный момент машиной, когда любая (или обе) из переменных COMPATIBLE_MACHINE и COMPATIBLE_HOSTзадают совместимость с машиной, отличной от выбранной и хоста. Не следует задавать переменную SOURCE_MIRROR_FETCH без наличия зеркала исходных кодов (т. е. при обычной сборке).

SOURCE_MIRROR_URL

Задает свою переменную PREMIRRORS,в соответствии с которой начинается выборка исходных кодов до обращения кSRC_URI. Для использования этой переменной требуется глобальное наследование класса own-mirrors и предоставление URL для зеркал. Ниже показан базовый синтаксис.

INHERIT += "own-mirrors"
     SOURCE_MIRROR_URL = "http://example.com/my_source_mirror"

В переменной SOURCE_MIRROR_URLможно задать лишь один идентификатор URL.

SPDXLICENSEMAP

Отображает общепринятые имена лицензий на идентификаторы SPDX из meta/files/common-licenses/. Подробное описание отображений приведено в файле meta/conf/licenses.conf. См. также описание переменной LICENSE.

SPECIAL_PKGSUFFIX

Список префиксов для PN,используемых системой сборкиOE при создании вариантов заданий или пакетов. Список задает префиксы, вырезаемые при некоторых обстоятельствах (например, создание переменной BPN).

SPL_BINARY

Тип файла для загрузчика SPL³, используемого некоторыми устройствами (например, плата BeagleBone) для загрузки. В таких случаях можно объявить тип двоичного файла SPL в файле u-boot.inc, используемом в задании U-Boot. Тип файла SPL по началу имеет значение null, заданное в файле u-boot.inc,как показано ниже.

     # Some versions of u-boot build an SPL (Second Program Loader) image that
     # should be packaged along with the u-boot binary as well as placed in the
     # deploy directory.  For those versions they can set the following variables
     # to allow packaging the SPL.
     SPL_BINARY ?= ""
     SPL_BINARYNAME ?= "${@os.path.basename(d.getVar("SPL_BINARY"))}"
     SPL_IMAGE ?= "${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}"
     SPL_SYMLINK ?= "${SPL_BINARYNAME}-${MACHINE}"

Переменная SPL_BINARY помогает формировать переменные SPL_*,используемые системой сборкиOE.

Пример конфигурации BeagleBone приведен в разделе Creating a new BSP Layer Using the bitbake-layers Script [6].

SRC_URI

Список исходных файлов (локальных или удаленных). Эта переменная говорит системе сборки OE, что и как нужно извлекать для сборки. Например, если заданию или файлу дополнения нужно лишь загрузить архив из Internet, это задание или файл дополнения использует одну запись SRC_URI. Если же нужно, например, извлечь архив, применить два исправления и включить пользовательский файл, задание или файл дополнения будут включать 4 экземпляра этой переменной.

Ниже приведен список поддерживаемых протоколов URI. Эти протоколы сильно зависят от конкретных субмодулей BitBake Fetcher. В зависимости от применяемого сборщика используются разные параметры URL. Подробное описание работы со сборщиками приведено в разделе Fetchers [4].

file:// извлекает файлы, которые обычно поставляются с метаданными с локальной машины (например, patch-файлы). Путь задается относительно значения переменной FILESPATH. Таким образом, система сборки просматривает по порядку перечисленные ниже каталоги, которые предполагаются подкаталогами места размещения файла задания (.bb) или дополнения (.bbappend):
- ${BPN} – базовое имя задания без специальных суффиксов и номера версии;
- ${BP} – ${BPN}-${PV} – базовое имя задания и версия, но без специального суффикса (имя пакета);
- files – файлы в каталоге files,который размещен вместе с файлом задания или дополнения.
Если вы хотите, чтобы система сборки забрала файлы, указанные оператором SRC_URI в вашем файле дополнения, нужно расширить переменную FILESPATH,используя значениеFILESEXTRAPATHS из вашего файла дополнения.
bzr:// извлекает файлы из репозитория управления версиями Bazaar.
git:// извлекает файлы из репозитория управления версиями Git.
osc:// извлекает файлы из репозитория управления версиями OSC (OpenSUSE Build service).
repo:// извлекает файлы из репозитория repo (Git).
ccrc:// извлекает файлы из репозитория ClearCase.
http:// извлекает файлы из Internet по протоколу http.
https:// извлекает файлы из Internet по протоколу https.
ftp:// извлекает файлы из Internet по протоколу ftp.
cvs:// извлекает файлы из репозитория управления версиями CVS.
hg:// извлекает файлы из репозитория управления версиями (hg).
p4:// извлекает файлы из репозитория управления версиями Perforce (p4).
ssh:// извлекает файлы из защищенной среды (secure shell).
svn:// – извлекает файлы из репозитория управления версиями Subversion (svn).

Имеются стандартные и специфические для заданий SRC_URI. Ниже перечислены стандартные.

apply – нужно ли применять исправления (по умолчанию apply – нужно).
striplevel – уровень разрешения (striplevel) при наложении исправлений (по умолчанию 1).
patchdir – каталог, в котором следует применять исправления (по умолчанию ${S}).

Ниже приведены варианты для заданий по сборке кода из системы контроля версий.

mindate – применять исправление лишь в случаях, когда SRCDATE не меньше mindate.
maxdate – применять исправление лишь в случаях, когда SRCDATE не больше maxdate.
minrev – применять исправление лишь в случаях, когда SRCREV не меньше minrev.
maxrev – применять исправление лишь в случаях, когда SRCREV не больше maxrev.
rev – применять исправление лишь в случаях, когда SRCREV = rev.
notrev – применять исправление лишь в случаях, когда SRCREV отличается от rev.

Имеется также ряд дополнительных опций, перечисленных ниже.

unpack – управляет распаковкой файла, если он является архивом (по умолчанию архивы распаковываются).
destsuffix – помещать файл (или извлекать его содержимое) в указанный подкаталог WORKDIR при использовании сборщика Git.
subdir – помещать файл (или извлекать его содержимое) в указанный подкаталог WORKDIR при использовании локального сборщика (file://).
localdir – помещать файл (или извлекать его содержимое) в указанный подкаталог WORKDIR при использовании сборщика CVS.
subpath – ограничивать извлечение конкретным путем в дереве при использовании сборщика Git.
name – задает имя, применяемое для привязки к контрольным суммам SRC_URI при указании в SRC_URI нескольких файлов.
downloadfilename – задает имя, используемое при записи загружаемого файла.

SRC_URI_OVERRIDES_PACKAGE_ARCH

По умолчанию система сборки OE автоматически обнаруживает наличие в SRC_URI машинозависимых файлов и в этом случае меняет значение PACKAGE_ARCH. Установка для переменной значения 0 отключает это.

SRCDATE

Дата исходного кода, применяемого для сборки пакета. Эта переменная применяется только для кодов, извлеченных из SCM.

SRCPV

Возвращает строку версии текущего пакета, используемую при определении значения переменной PV. Переменная SRCPV определена в конфигурационном файле meta/conf/bitbake.conf дерева исходных кодов, как SRCPV = “${@bb.fetch2.get_srcrev(d)}”.

Задания, которым нужно определить PV, делают это с помощью SRCPV. Например, задание (ofono_git.bb) в каталоге meta/recipes-connectivity дерева исходных кодов задает PV в виде PV = “0.12-git${SRCPV}”.

SRCREV

Выпуск исходных кодов, используемых для сборки пакета. Эта переменная применима лишь к исходным кодам Subversion, Git, Mercurial и Bazaar. Если нужно собрать фиксированную версию без запросов к удаленному репозиторию всякий раз, когда BitBake анализирует задание, следует указать в переменной SRCREV полный идентификатор версии, а не просто тег. Информация об ограничениях при наследовании последней версии программы из SRCREV приведена в описании переменной AUTOREV и разделе Automatically Incrementing a Binary Package Revision Number [2].

SSTATE_DIR

Каталог для кэша общих состояний.

SSTATE_MIRROR_ALLOW_NETWORK

Установка значения 1 разрешает выборку из «зеркал», указанных в переменной SSTATE_MIRRORS, даже в случаях, когда выборка из сети отключена установкой BB_NO_NETWORK = “1”. применение переменной SSTATE_MIRROR_ALLOW_NETWORK полезно с тех случаях, когда нужно указать в SSTATE_MIRRORS внутренний сервер для общего кэше состояний, но требуется запретить другие выборки из сети.

SSTATE_MIRRORS

Настраивает систему сборки OE на поиск других зеркал с подготовленными объектами данных кэша перед сборкой. Эта переменная работает как сборщики MIRRORS и PREMIRRORS,указывая расположение кэша для поиска общих объектов состояния (sstate).

Можно указать каталог файловой системы или идентификатор URL, такой как HTTP или FTP. Заданное место должно содержать результаты кэширования общего состояния (sstate-cache) из предшествующей сборки. В качестве sstate-cache могут служить результаты сборки на другой машине.

При указании на данные sstate на другой машине, использующей другую версию GCC для естественной сборки, нужно указать в SSTATE_MIRROR регулярное выражение для отображения локального пути поиска в путь на сервере. В путях нужно учитывать значение NATIVELSBSTRING,установленное классом uninative. Например, отображение локального пути поиска universal-4.9 на серверный путь server_url_sstate_pathимеет видSSTATE_MIRRORS ?= file://universal-4.9/(.*) http://server_url_sstate_path/universal-4.8/\1 \n.

Если зеркало использует такую же структуру, как SSTATE_DIR, нужно добавить PATH в конце, как показано в примере ниже. Система сборки подставит корректный путь поиска в структуре каталогов.

SSTATE_MIRRORS ?= "\
     file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \ file://.* file:///some-local-dir/sstate/PATH"

SSTATE_SCAN_FILES

Управляет списком файлов, сканируемых системой сборки OE для жестко заданных путей установки. Переменная содержит список разделенных пробелами имен файлов (не путей) с возможностью использования стандартных символов-шаблонов. При сборке система OE создает объект общего состояния (sstate) на первом этапе подготовки sysroot. Объект сканируется на предмет жестко заданных путей для исходных мест установки. Список файлов, для которых сканируются пути, определяет переменная SSTATE_SCAN_FILES. Обычно задания добавляют файлы для сканирования в переменную SSTATE_SCAN_FILES, а не в переменную, задающую полный набор. Принятый по умолчанию список файлов задает класс sstate. Детали процесса даны в описании класса staging.

STAGING_BASE_LIBDIR_NATIVE

Задает путь к каталогу /lib в sysroot для сборочного хоста.

STAGING_BASELIBDIR

Задает путь к каталогу /lib в sysroot для целевой платформы текущего задания (STAGING_DIR_HOST).

STAGING_BINDIR

Задает путь к каталогу /usr/bin внутри sysroot целевой системы, для которой собирается текущее задание (STAGING_DIR_HOST).

STAGING_BINDIR_CROSS

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

STAGING_BINDIR_NATIVE

Задает путь к каталогу /usr/bin в каталоге sysroot для хоста сборки.

STAGING_DATADIR

Задает путь к каталогу /usr/share в sysroot для целевой платформы текущего задания (STAGING_DIR_HOST).

STAGING_DATADIR_NATIVE

Задает путь к каталогу /usr/share в каталоге sysroot для хоста сборки.

STAGING_DIR

Помогает создавать для заданий каталоги sysroot, используемые при подготовке пакетов. Информация о подготовке sysroot для заданий приведена в параграфе 7.1.22. do_populate_sysroot, разделах Sharing Files Between Recipes [2] и Configuration, Compilation, and Staging [1], а также в описании переменной SYSROOT_DIRS. Заданиям не следует писать напрямую в каталог STAGING_DIR, поскольку система сборки OE поддерживает каталог автоматически. Задания должны устанавливаться в ${D} задачей do_install в задании, а система сборки OE будет помещать часть файлов в sysroot.

STAGING_DIR_HOST

Указывает путь к каталогу sysroot для системы, на которой выполняется сборка компонент (системы, где размещаются компоненты). Для большинства заданий sysroot – это один из каталогов, куда задача do_populate_sysroot копирует файлы. Исключениями являются задания -native, где задача do_populate_sysroot использует каталог STAGING_DIR_NATIVE. В зависимости от типа задания и цели сборки STAGING_DIR_HOST может принимать одно из двух значений:

${STAGING_DIR}/${MACHINE} для заданий, собираемых для целевой машины;
при сборке заданий для сборочного хоста значение пусто, если используются каталоги сборочного хоста.

Задания -native не устанавливаются в естественные пути хоста, такие как /usr, а помещаются в STAGING_DIR_NATIVE. При сборке таких заданий стандартные переменные окружения (такие как CPPFLAGS и CFLAGS) устанавливаются так, что поиск библиотек и заголовочных файлов выполняется по путям хоста и STAGING_DIR_NATIVE с использованием, например опции GCC -isystem. Таким образом, делается акцент на то, что переменные STAGING_DIR* должны рассматриваться как входные такими задачами, как do_configure, do_compile и do_install. Наличие реальной корневой системы, соответствующей STAGING_DIR_HOST, имеет концептуальный смысл для заданий -native, поскольку они используют двоичные и заголовочные файлы хоста.

STAGING_DIR_NATIVE

Задает путь к каталогу sysroot, используемому при сборке компонент, работающих на самом сборочном хосте.

STAGING_DIR_TARGET

Задает путь к sysroot в системе, для которой генерируется код. Для компонент, не создающих код (их большинство), переменная STAGING_DIR_TARGET совпадает с STAGING_DIR_HOST. Некоторые задания создают код для использования в целевой системе, но эти двоичные файлы в свою очередь генерируют код для другой отличающейся системы (например, задания cross-canadian). В терминологии GNU первичная система называется хостом (HOST), а вторичная – целью (TARGET). Таким образом, двоичные файлы хоста создают двоичные файлы для целевой платформы (TARGET). Переменная STAGING_DIR_HOST указывает каталог sysroot, используемый хост-системой, а STAGING_DIR_TARGET указывает sysroot для TARGET.

STAGING_ETCDIR_NATIVE

Задает путь к каталогу /etc в sysroot сборочного хоста.

STAGING_EXECPREFIXDIR

Задает путь к каталогу /usr в sysroot целевой платформы, для которой собирается текущее задание (STAGING_DIR_HOST).

STAGING_INCDIR

Задает путь к каталогу /usr/include в sysroot целевой платформы, для которой собирается текущее задание (STAGING_DIR_HOST).

STAGING_INCDIR_NATIVE

Задает путь к каталогу /usr/include в sysroot сборочного хоста.

STAGING_KERNEL_BUILDDIR

Указывает каталог, содержащий элементы сборки (artifact) ядра. Задания, собирающие программы, которым нужен доступ к таким элементам (например, systemtap-uprobes) могут просматривать STAGING_KERNEL_BUILDDIR для поиска нужных элементов после сборки ядра.

STAGING_KERNEL_DIR

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

STAGING_LIBDIR

Задает путь к каталогу /usr/lib в sysroot целевой платформы, для которой собирается текущее задание (STAGING_DIR_HOST).

STAGING_LIBDIR_NATIVE

Задает путь к каталогу /usr/lib в sysroot сборочного хоста.

STAMP

Задает базовый путь для создания штампов задания. Фактический путь к штампам определяется путем преобразования этой строки и добавления в нее дополнительной информации. В настоящее время переменная задается файлом meta/conf/bitbake.conf в виде STAMP = “${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}”. Дополнительная информация об использовании штампов для решения вопроса о повторном запуске задач приведена в разделе Stamp Files and the Rerunning of Tasks [1].

STAMPS_DIR

Задает каталог, в который система сборки OE помещает штампы сборки (по умолчанию ${TMPDIR}/stamps).

STRIP

Сокращенное имя и аргументы для команды strip, используемой для исключения символов из файлов.

SUMMARY

Короткое (до 72 символов) описание двоичного пакета для системы установки (например, opkg, rpmилиdpkg). По умолчанию значение SUMMARY служит значением переменной DESCRIPTION,если она не указана в задании.

SVNDIR

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

SYSLINUX_DEFAULT_CONSOLE

Задает консоль, используемую по умолчанию при загрузке ядра. Для использования другой консоли следует установить нужное значение в файле конфигурации задания. Например, SYSLINUX_DEFAULT_CONSOLE = “console=ttyX”, где X указывает номер нужной консоли. Класс syslinux исходно устанавливает для переменной пустое значение, но затем проверяет его.

SYSLINUX_OPTS

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

SYSLINUX_SERIAL

Задает дополнительный последовательный порт или отключает порт при пустом значении переменной в задании. Принятое по умолчанию значение переменной задает класс syslinux в виде SYSLINUX_SERIAL ?= “0 115200”. Этот класс проверяет и при необходимости использует переменную.

SYSLINUX_SPLASH

Указывает файл .LSS,используемый в качестве фона загрузочного менюVGA. Переменная устанавливается в задании. Класс syslinux проверяет переменную и при наличии файла система сборки OE устанавливает заставку.

SYSLINUX_SERIAL_TTY

Задает дополнительную консоль (console=tty…) для загрузки ядра. По умолчанию для этой переменной класс syslinux устанавливает SYSLINUX_SERIAL_TTY ?= “console=ttyS0,115200”, проверяя и используя затем эту переменную.

SYSROOT_DESTDIR

Указывает временный каталог внутри рабочего каталога (по умолчанию ${WORKDIR}/sysroot-destdir), где собираются файлы, помещаемые в sysroot, в процессе выполнения задачи do_populate_sysroot.

SYSROOT_DIRS

Каталоги, помещаемые в sysroot задачей do_populate_sysroot. Принятые по умолчанию каталоги приведены ниже.

     SYSROOT_DIRS = " \
         ${includedir} \
         ${libdir} \
         ${base_libdir} \
         ${nonarch_base_libdir} \
         ${datadir} \
     "

SYSROOT_DIRS_BLACKLIST

Каталоги, не помещаемые в sysroot задачей do_populate_sysroot. Переменная может служить для исключения некоторых каталогов, указанных в SYSROOT_DIRS. По умолчанию исключаются приведенные ниже каталоги.

     SYSROOT_DIRS_BLACKLIST = " \
         ${mandir} \
         ${docdir} \
         ${infodir} \
         ${datadir}/locale \
         ${datadir}/applications \
         ${datadir}/fonts \
         ${datadir}/pixmaps \
     "

SYSROOT_DIRS_NATIVE

Каталоги, помещаемые в sysroot задачей do_populate_sysroot для заданий-native, в дополнение к каталогам из SYSROOT_DIRS. Включаемые по умолчанию дополнительные каталоги приведены ниже.

     SYSROOT_DIRS_NATIVE = " \
         ${bindir} \
         ${sbindir} \
         ${base_bindir} \
         ${base_sbindir} \
         ${libexecdir} \
         ${sysconfdir} \
         ${localstatedir} \
     "

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

SYSROOT_PREPROCESS_FUNCS

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

SYSTEMD_AUTO_ENABLE

При наследовании класса systemd эта переменная определяет, нужно ли автоматически запускать службу, указанную в SYSTEMD_SERVICE. Ао умолчанию службы запускаются при загрузке автоматически, что задается классом systemd в форме SYSTEMD_AUTO_ENABLE ??= “enable”. Эту настройку можно изменить, указав disable.

SYSTEMD_BOOT_CFG

При установке EFI_PROVIDER = “systemd-boot” эта переменная задает конфигурационный файл, который следует использовать. По умолчанию класс systemd-boot устанавливает SYSTEMD_BOOT_CFG ?= “${S}/loader.conf”. Информация о Systemd-boot доступна по ссылке Systemd-boot.

SYSTEMD_BOOT_ENTRIES

При EFI_PROVIDER = “systemd-boot” переменная задает список файлов (*.conf) для установки, содержащих по одной загрузочной записи в строке. По умолчанию класс systemd-boot задает SYSTEMD_BOOT_ENTRIES ?= “” (см. документацию Systemd-boot).

SYSTEMD_BOOT_TIMEOUT

При установке EFI_PROVIDER = “systemd-boot” задает время ожидания меню загрузки в секундах. По умолчанию класс systemd-boot устанавливает SYSTEMD_BOOT_TIMEOUT ?= “10” (см. документацию Systemd-boot).

SYSTEMD_PACKAGES

При наследовании класса systemd указывает файлы блоков systemd, когда они не найдены в основном задании пакета. По умолчанию переменная устанавливается так, что файлы блоков systemd предполагаются в основном задании пакета, – SYSTEMD_PACKAGES ?= “${PN}”. Если это не так, в переменной SYSTEMD_PACKAGES нужно указать список пакетов, в которых система сборки будет искать файлы блоков systemd.

SYSTEMD_SERVICE

При наследовании класса systemd задает имя службы systemd для пакета. При указании этого файла в задании нужно использовать переопределение имени пакета, к которому применяется значение, в форме SYSTEMD_SERVICE_${PN} = “connman.service”.

SYSVINIT_ENABLED_GETTYS

При использовании SysVinit задает список разделенных пробелами виртуальных терминалов, которые должны запускать getty (разрешая login), если USE_VT отлична от 0. По умолчанию принято SYSVINIT_ENABLED_GETTYS = “1” (getty запускается лишь на первом виртуальном терминале).

T

Указывает каталог, где BitBake размещает временные файлы (в основном log-файлы задач и сценариев при сборке конкретных заданий). Для этой переменной обычно устанавливается значение T = “${WORKDIR}/temp”

Переменная WORKDIR указывает каталог, в который BitBake распаковывает и собирает задание. По умолчанию эта переменная задается в файле bitbake.conf.

Переменную T не следует путать с переменной TMPDIR, которая указывает корень дерева, куда BitBake размещает вывод всего процесса сборки.

TARGET_ARCH

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

TARGET_AS_ARCH

Задает зависимые от архитектуры флаги ассемблера для целевой системы и по умолчанию инициализируется значением TUNE_ASARGS в конфигурационном файле BitBake (meta/conf/bitbake.conf) как TARGET_AS_ARCH = “${TUNE_ASARGS}”

TARGET_CC_ARCH

Задает зависимые от архитектуры флаги компилятора C для целевой системы и по умолчанию инициализируется значением TUNE_CCARGS. Это общий подход для добавления LDFLAGS в TARGET_CC_ARCH в заданиях, собирающих программы для целевой системы, которые иначе не учитывали бы экспортируемую переменную LDFLAGS.

TARGET_CC_KERNEL_ARCH

Это специальный флаг компилятора ядра для настройки CPU или ABI. Флаг применяется редко и лишь в случаях, где значение TUNE_CCARGS не совместимо с компиляцией ядра. Переменная позволяет ядру (и связанным с ним модулям) использовать другую конфигурацию. Примером может служить файл meta/conf/machine/include/arm/feature-arm-thumb.inc в дереве исходных кодов.

TARGET_CFLAGS

Задает флаги для передачи компилятору C c при сборке для целевой системы. При сборке в контексте целевой системы CFLAGS по умолчанию получает значение этой переменной. Сценарий настройки окружения SDK устанавливает для переменной CFLAGS в среде значение TARGET_CFLAGS, чтобы при сборке исполняемых файлов с использованием SDK также применялись эти флаги.

TARGET_CPPFLAGS

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

TARGET_CXXFLAGS

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

TARGET_FPU

Задает метод обработки кода FPU. Для платформ без FPU, к которым относится большинство ARM CPU, эта переменная должна иметь значение “soft”. В противном случае применяется эмуляция ядра, что снижает производительность.

TARGET_LD_ARCH

Задает зависимые от архитектуры флаги компоновщика для целевой системы и по умолчанию инициализируется значением TUNE_LDARGS в конфигурационном файле BitBake (meta/conf/bitbake.conf) как TARGET_LD_ARCH = “${TUNE_LDARGS}”.

TARGET_LDFLAGS

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

TARGET_OS

Задает операционную систему целевой платформы. Переменная получает значение linux для систем на основе glibc (библиотека GNU C) и linux-musl для систем с библиотекой musl. Для платформ ARM/EABI возможны значения linux-gnueabi и linux-musleabi.

TARGET_PREFIX

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

Для заданий, собирающих целевую машину применяется “${TARGET_SYS}-“.
Для естественных заданий устанавливается значение BUILD_PREFIX.
Для заданий nativesdk устанавливается значение SDK_PREFIX.

TARGET_SYS

Задает систему (включая архитектуру и ОС), для которой выполняется сборка в контексте текущего задания. Система сборки OE автоматически устанавливает эту переменную на основе TARGET_ARCH, TARGET_VENDOR, и TARGET_OS. Менять переменную самостоятельно не требуется.

Для естественного задания для 32-битовой машины x86 с Linux переменная будет иметь значение i686-linux, для платформы little-endian MIPS с Linux – mipsel-linux.

TARGET_VENDOR

Задает имя производителя целевой платформы.

TCLIBC

Задает вариант стандартной библиотеки GNU C (libc) для использования при сборке. Переменная заменила POKYLIBC, которая больше не поддерживается. Возможны варианты glibc, musl, newlib или baremetal.

TCLIBCAPPEND

Задает суффикс, добавляемый к значению TMPDIR и указывающий вариант libc для сборки. При сборке нескольких вариантов в одном сборочном каталоге этот механизм обеспечивает предотвращение конфликтов. В файле defaultsetup.conf задано принятое по умолчанию значение TCLIBCAPPEND = “-${TCLIBC}”. Однако такие дистрибутивы, как poky, обычно поддерживают один вариант libc и устанавливают TCLIBCAPPEND = “” в своем файле конфигурации.

TCMODE

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

Если для TCMODE установлено другое значение, нужно обеспечить совместимость указанного инструментария с принятым по умолчанию. Использование слишком старых или новых компонент может вызвать проблемы при сборке. Совместимость разных компонент описывается в замечанию к выпускам YP (Release Notes), доступным на странице Downloads по ссылкам RELEASE INFORMATION для соответствующих выпусков.

Переменная TCMODE похожа на TCLIBC, которая контролирует вариант стандартной библиотеки GNU C (libc), используемый при сборке (glibc или musl).

При использовании дополнительных уровней можно задать внешний инструментарий. Примером может служить Sourcery G++ Toolchain, поддержка которого задана в отдельном уровне Mentor Graphics® meta-sourcery, доступном по ссылке http://github.com/MentorEmbedded/meta-sourcery/. Файл README для этого уровня описывает использование Sourcery G++ Toolchain в качестве внешнего инструментария. Вам нужно добавить уровень в свой файл bblayers.conf перед мета-уровнем и установить переменную EXTERNAL_TOOLCHAIN в файле local.conf, указав место размещения инструментов.

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

TEST_EXPORT_DIR

Место, используемое системой сборки OE для экспорта тестов при установке TEST_EXPORT_ONLY = “1” (по умолчанию ${TMPDIR}/testimage/${PN}).

TEST_EXPORT_ONLY

Задает лишь экспорт тестов. Установка значение 1 приведет к тому, что тесты будут экспортированы, но не будут запускаться в системе сборки.

TEST_LOG_DIR

Указывает место хранения журналов загрузки и SSH для машин QEMU (по умолчанию ${WORKDIR}/testimage). Фактические результаты теста сохраняются в журнале задачи log.do_testimage в каталоге ${WORKDIR}/temp/.

TEST_POWERCONTROL_CMD

При автоматизированном тестировании оборудования задает команду, применяемую для управления питанием на тестируемой целевой машине. Обычно эта команда указывает сценарий, который выполняет нужные действия (например, взаимодействует с управляемым через web сетевым удлинителем). Указанная команда должна ожидать в качестве последнего аргумента значение “off”, “on” или “cycle” для включения, выключения или цикла (выключение с последующим включением).

TEST_POWERCONTROL_EXTRA_ARGS

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

TEST_QEMUBOOT_TIMEOUT

Время в секундах с начала загрузки, по истечение которого начнется автоматизированное тестирование образа. Используемый по умолчанию тайм-аут 500 секунд позволяет процессу загрузки дойти до приглашения на вход в систему (login). Можно указать иное время ожидания в файле local.conf. Дополнительные сведения о тестировании образов приведены в разделе Performing Automated Runtime Testing [2].

TEST_SERIALCONTROL_CMD

При автоматизированном тестировании оборудования задает команду, применяемую для подключения последовательной консоли на тестируемой платформе. Команда просто должна подключиться к консоли и перенаправить в это соединение стандартный-ввод-вывод, как это делает обычная терминальная программа. Например, для использования терминала Picocom с устройством /dev/ttyUSB0 на скорости 115200 бит/с можно указать TEST_SERIALCONTROL_CMD = “picocom /dev/ttyUSB0 -b 115200”.

TEST_SERIALCONTROL_EXTRA_ARGS

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

TEST_SERVER_IP

IP-адрес сборочной машины, который обычно определяется автоматически и при отказе детектирования нужно установить его вручную. Переменная применяют лишь немногими тестами, такими как dnf, которым нужно загружать пакеты из WORKDIR/oe-rootfs-repo.

TEST_TARGET

Указывает целевой контроллер для выполнения тестов образа (по умолчанию TEST_TARGET = “QemuTarget”). Целевым контроллером служит класс, определяющий развертывание образа на целевой платформе и запуск платформы. Уровень может расширять контроллеры путем добавления модулей в свой каталог /lib/oeqa/controllers и наследования абстрактного класса BaseTarget, который не может служить значением TEST_TARGET.

Поддерживаемые TEST_TARGETзначения описаны ниже.

“QemuTarget” – загрузка образа QEMU и запуск тестов (см. раздел Enabling Runtime Tests on QEMU ).
“SimpleRemoteTarget” – запуск тестов на целевой платформе, которая уже работает. Оборудование может находиться в сети или эмулироваться в QEMU. Требуется установка переменной TEST_TARGET_IP. Этот параметр определен в файле meta/lib/oeqa/controllers/simpleremote.py.

Сведения о запуске тестов на оборудовании приведены в разделе Enabling Runtime Tests on Hardware [2].

TEST_TARGET_IP

IP-адрес тестируемого оборудования. TEST_TARGET_IP не работает при установке TEST_TARGET = “qemu”.

Вместе с адресом IP можно указать порт, например, TEST_TARGET_IP = “192.168.1.4:2201”. Указание порта полезно при работе SSH через нестандартный порт, например, при размещении тестируемого устройства за межсетевым экраном или транслятором адресов и портов.

TEST_SUITES

Упорядоченный список тестов (модулей) для запуска применительно к образу с целью автоматического тестирования при работе. Система сборки OE обеспечивает базовый набор тестов для проверки образов. В настоящее время эти тесты работают только в QEMU. Тесты включают ping, ssh, df и др. Можно расширить список тестов, добавляя их в переменную TEST_SUITES в виде TEST_SUITES_append = ” mytest“. Можно также указать TEST_SUITES_append = ” auto” для применения всех доступных тестов.

Использование этой опции заставляет систему сборки автоматически запускать применимые к образу тесты. Порядок тестов имеет значение и зависящие от других тестов проверки должны выполняться после проверки от которой они зависят. Например, при добавлении в список тестов test_A и test_B,гдеtest_B зависит от test_Aследует указыватьTEST_SUITES = ” test_A test_B”.

Дополнительные сведения о тестировании образов приведены в разделе Performing Automated Runtime Testing [2].

TESTIMAGE_AUTO

Управляет запуском серии автоматизированных тестов для образов после успешной сборки. TESTIMAGE_AUTO = “1” вызывает автоматическую загрузку созданного образа в QEMU. Использование переменной также добавляет зависимости, поэтому сначала автоматически собираются все SDK, для которых запрошено тестирование.

Тесты написаны на Python с использованием модуля unittest и основная часть тестов запускает команды на целевой системе по протоколу ssh. Можно установить для переменной значение 1 в файле local.conf каталога сборки, чтобы система сборки OE автоматически выполнила тесты после сборки образа. Дополнительные сведения о включении, запуске и создании тестов приведены в разделе Performing Automated Runtime Testing [2] и параграфе 6.132. testimage*.bbclass.

THISDIR

Каталог, в котором в данный момент выполняется разбор BitBake. Не меняйте эту переменную.

TIME

Время начала сборки в формате HMS (например, 140159 для 14 часов, одной минуты и 59 секунд).

TMPDIR

Эта переменная указывает базовый каталог, используемый системой сборки OE для всего вывода результатов и промежуточных файлов (кроме общего кэша состояний). По умолчанию переменная TMPDIR указывает каталог tmp в каталоге сборки. Если нужно разместить временный каталог в другом месте, можно убрать знак комментария и отредактировать показанную ниже строку файла conf/local.conf в дереве исходных кодов.

     #TMPDIR = "${TOPDIR}/tmp"

Примером такого использования служит указание в переменной TMPDIR локального диска, который не использует NFS, при размещении каталога сборки на NFS.

Файловая система, указанная TMPDIR, должна поддерживать стандартную семантику (например, различать регистр символов в именах, поддерживать блокировки POSIX и сохраняющиеся значения inode). С учетом имеющихся в NFS проблем и наличия ошибок в некоторых реализациях, NFS не соответствует этим требованиям, поэтому TMPDIR не может указывать NFS.

TOOLCHAIN_HOST_TASK

Эта переменная указывает пакеты, которые система сборки OE использует при создании SDK со средой кросс-компиляции. Эти пакеты являются частью инструментария, работающего на SDKMACHINE, и обычно каждый пакет должен иметь префикс nativesdk-. Рассмотрим в качестве примера команду сборки SDK

$ bitbake -c populate_sdk imagename

В этом случае в переменной указан принятый по умолчанию список пакетов, но его можно расширить (см. раздел Adding Individual Packages to the Standard SDK [7]). Базовые сведения о кросс-разработке в среде YP приведены в разделе Cross-Development Toolchain Generation [1], а организация среды разработки описана в [7].

TOOLCHAIN_OUTPUTNAME

Задает имя, используемое для вывода инструментария. Класс populate_sdk_base устанавливает TOOLCHAIN_OUTPUTNAME ?= “${SDK_NAME}-toolchain-${SDK_VERSION}“. Дополнительная информация приведена в описаниях переменных SDK_NAME и SDK_VERSION.

TOOLCHAIN_TARGET_TASK

Перечисляет пакеты, используемые системой сборки OE при создании целевой части SDK (т. е. части, собираемой для целевой платформы), включающей библиотеки и файлы заголовков. Дополнительная информация о добавлении пакетов в SDK приведена в разделе Adding Individual Packages to the Standard SDK [7]. Базовые сведения об инструментах кросс-разработки в среде YP можно найти в разделе Cross-Development Toolchain Generation [1], организация среды кросс-разработки описана в [7].

TOPDIR

Верхний уровень каталога сборки. BitBake автоматически инициализирует переменную при установке рабочей среды с помощью oe-init-build-env (параграф 5.1.9.1 oe-init-build-env).

TRANSLATED_TARGET_ARCH

Очищенный (sanitized) вариант TARGET_ARCH. Переменная применяется в тех случаях, где архитектура должна указываться в значениях, не поддерживающих символы подчеркивания (например, в именах пакетов). Эти символы в TARGET_ARCH заменяются символами дефиса. Не меняйте эту переменную.

TUNE_ARCH

Каноническая архитектура GNU (arm, armeb, mips, mips64 и т. п.), которую BitBake использует для настройки конфигурации. Определения TUNE_ARCH зависят от конкретной архитектуры и могут быть статическими или динамическими. Детали для конкретного семейства CPU можно найти в файле README для архитектуры. Например, файл meta/conf/machine/include/mips/README в дереве исходных кодов содержит информацию для TUNE_ARCH в архитектуре mips.

TUNE_ARCH тесно связана с переменной TARGET_ARCH, задающей архитектуру целевой машины. Конфигурационный файл BitBake (meta/conf/bitbake.conf) устанавливает переменную в форме TARGET_ARCH = “${TUNE_ARCH}”.

Список поддерживаемых архитектур включает arm, i586, x86_64, powerpc, powerpc64, mips, mipsel и др.

TUNE_ASARGS

Задает зависящие от архитектуры флаги ассемблера для целевой системы. Набор флагов основывается на выбранных настройках. Переменная TUNE_ASARGS задается с использованием включаемых файлов настройки, которые размещаются обычно в meta/conf/machine/include/, и зависит от TUNE_FEATURES. Например, файл meta/conf/machine/include/x86/arch-x86.inc определяет флаги для архитектуры x86 в форме TUNE_ASARGS += “${@bb.utils.contains(“TUNE_FEATURES”, “mx32″, “-x32”, “”, d)}”. Пакеты BSP выбирают настройку (tune), которая, в свою очередь, влияет на сами переменные настройки, которые передаются набором флагов.

TUNE_CCARGS

Задает зависящие от архитектуры флаги компилятора C для целевой системы. Набор флагов основывается на выбранных настройках. Переменная TUNE_CCARGS задается с использованием включаемых файлов настройки, которые размещаются обычно в meta/conf/machine/include/, и зависит от TUNE_FEATURES. Пакеты BSP выбирают настройку (tune), которая, в свою очередь, влияет на сами переменные настройки, которые передаются набором флагов.

TUNE_LDARGS

Задает зависящие от архитектуры флаги компоновщика для целевой системы. Набор флагов основывается на выбранных настройках. Переменная TUNE_LDARGS задается с использованием включаемых файлов настройки, которые размещаются обычно в meta/conf/machine/include/, и зависит от TUNE_FEATURES. Например, файл meta/conf/machine/include/x86/arch-x86.inc определяет флаги для архитектуры x86 в форме TUNE_LDARGS += “${@bb.utils.contains(“TUNE_FEATURES”, “mx32”, “-m elf32_x86_64”, “”, d)}”. Пакеты BSP выбирают настройку (tune), которая, в свою очередь, влияет на сами переменные настройки, которые передаются набором флагов.

TUNE_FEATURES

Свойства, применяемые для «настройки» компилятора с целью оптимизации для конкретного процессора. Свойства определяются в файлах настройки и позволяют динамически создавать аргументы (TUNE_*ARGS) на основе свойств. Система сборки OE проверяет свойства на предмет их поддержки и отсутствия конфликтов.

Конфигурационный файл BitBake (meta/conf/bitbake.conf) задает TUNE_FEATURES ??= “${TUNE_FEATURES_tune-${DEFAULTTUNE}}”. Дополнительная информация приведена в описании переменной DEFAULTTUNE.

TUNE_PKGARCH

Архитектура пакета, воспринимаемая системой подготовки пакетов для выбора архитектуры, ABI и настройки выходных пакетов. Конкретная настройка задается переопределением _tune в форме TUNE_PKGARCH_tune-tune = “tune“. Эти зависящие от настройки варианты архитектуры определяются во включаемых файлах для машин. Например, файл meta/conf/machine/include/tune-core2.inc указывает архитектуру в виде TUNE_PKGARCH_tune-core2-32 = “core2-32”.

TUNEABI

Базовый интерфейс ABI, применяемый конкретной настройкой для данного уровня инструментов (по умолчанию разрешены все настройки). Провайдеры, использующие готовые библиотеки могут применять переменные TUNEABI_WHITELIST, TUNEABI_OVERRIDE и TUNEABI для проверки совместимости настройки с выбором библиотек. Использование переменной рассмотрено в параграфе 6.116. sanity.bbclass.

TUNEABI_OVERRIDE

При установленной переменной система сборки игнорирует TUNEABI_WHITELIST.
Провайдеры, использующие готовые библиотеки могут применять переменные TUNEABI_WHITELIST, TUNEABI_OVERRIDE и TUNEABI для проверки совместимости настройки с выбором библиотек. Использование переменной рассмотрено в параграфе 6.116. sanity.bbclass.

TUNEABI_WHITELIST

Список разрешенных значений TUNEABI (по умолчанию разрешены все настройки). Провайдеры, использующие готовые библиотеки могут применять переменные TUNEABI_WHITELIST, TUNEABI_OVERRIDE и TUNEABI для проверки совместимости настройки с выбором библиотек. Использование переменной рассмотрено в параграфе 6.116. sanity.bbclass.

TUNECONFLICTS[feature]

Задает функции тестирования CPU или ABI, конфликтующие со свойством. Известные конфликты указываются во включаемых файлах машин внутри дерева исходных кодов. Примером может служить файл meta/conf/machine/include/mips/arch-mips.inc,в котором указан конфликтo32 и n64 с n32 в виде TUNECONFLICTS[n32] = “o32 n64”.

TUNEVALID[feature]

Задает действительную функцию настройки CPU или ABI, сохраняемую как флаг. Действительные функции указаны во включаемых файлах машин (например, meta/conf/machine/include/arm/arch-arm.inc) в дереве исходных кодов. Ниже приведен пример из такого файла.

     TUNEVALID[bigendian] = "Enable big-endian mode."

U

UBOOT_CONFIG

Настраивает UBOOT_MACHINE и может также определять IMAGE_FSTYPES в отдельных случаях. Ниже приведен пример с уровня meta-fsl-arm.

     UBOOT_CONFIG ??= "sd"
     UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard"
     UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config"
     UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs"
     UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config"

В этом примере выбран вариант sd из 4 возможных для UBOOT_MACHINE. Конфигурация sd определяет “mx6qsabreauto_config” как значение UBOOT_MACHINE, а “sdcard” задает IMAGE_FSTYPES для образа U-boot.

Обработка UBOOT_CONFIG рассмотрена в описании класса uboot-config (параграф 6.139. uboot-config.bbclass).

UBOOT_ENTRYPOINT

Задает точку входа для образа U-Boot, при создании которого эта переменная передается в качестве параметра команде uboot-mkimage.

UBOOT_LOADADDRESS

Задает адрес загрузки для образа U-Boot, при создании которого эта переменная передается в качестве параметра команде uboot-mkimage.

UBOOT_LOCALVERSION

Добавляет строку к имени локальной версии образа U-Boot. Например, для образа U-Boot версии 2013.10 можно задать полное имя 2013.10-yocto с помощью UBOOT_LOCALVERSION = “-yocto”.

UBOOT_MACHINE

Задает значение, передаваемое команде make при сборке образа U-Boot и указывающее конфигурацию целевой платформы. Обычно эта переменная задается в файле конфигурации машины conf/machine/machine_name.conf.

Возможные значения переменной приведены в разделе Selection of Processor Architecture and Board Type файла U-Boot README.

UBOOT_MAKE_TARGET

Задает цель, указанную в Makefile (по умолчанию all).

UBOOT_SUFFIX

Указывает создаваемое расширение U-Boot. Например, u-boot.sb имеет расширение .sb. По умолчанию U-Boot использует расширение .bin

UBOOT_TARGET

Задает цель для сборки U-Boot, которая передается напрямую как часть команды make (например, SPL и AIS). Если эта переменная не задана, система сборки OE передает и использует значение all при сборке U-Boot.

UNKNOWN_CONFIGURE_WHITELIST

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

Проверка аргументов configure с использованием UNKNOWN_CONFIGURE_WHITELIST является частью класса insane и включается лишь в заданиях, наследующих класс autotools.

UPDATERCPN

Для задания, наследующих класс update-rc.d, переменная UPDATERCPN задает включаемый пакет initscript. По умолчанию используется значение ${PN}. С учетом того, что почти все задания, устанавливающие пакет initscripts, упаковывают его в основной пакет задания, эту переменную редко приходится устанавливать для заданий.

UPSTREAM_CHECK_GITTAGREGEX

Можно проверить использование каждым заданием последней версии разрабатываемого кода с помощью bitbake -c checkpkg. Если исходный код взят из репозитория Git, система сборки OE определяет последнюю версию, указывая самый новый тег для репозитория. Переменная UPSTREAM_CHECK_GITTAGREGEX позволяет задать регулярное выражение для фильтрации тегов, если принятый по умолчанию фильтр работает некорректно.

     UPSTREAM_CHECK_GITTAGREGEX = "git_tag_regex"

UPSTREAM_CHECK_REGEX

Служит для задания регулярного выражения вместо принятого по умолчанию, когда система проверки пакетов анализирует страницу, найденную с помощью UPSTREAM_CHECK_URI., Например, UPSTREAM_CHECK_REGEX = “package_regex”.

UPSTREAM_CHECK_URI

Можно проверить использование последней версии разрабатываемого кода для каждого задания с помощью команды bitbake -c checkpkg. Если исходные коды взяты из архива, последняя версия определяется просмотром списка в каталоге, где размещен архив с попыткой найти самый новый. Когда такой подход не работает, можно использовать UPSTREAM_CHECK_URI для указания URI со ссылкой на последнюю версию архива в форме UPSTREAM_CHECK_URI = “recipe_url”.

USE_DEVFS

Управляет использованием devtmpfs для заполнения /dev. По умолчанию применяется USE_DEVFS = “1”, но обычно указывается USE_DEVFS = “0” для статически заполняемого каталога /dev(см. раздел Selecting a Device Manager [2]).

USE_VT

При использовании SysVinit определяет, нужно ли запускать программу getty на любом из виртуальных терминалов для записи журнала через эти терминалы. По умолчанию используется USE_VT = “0” в файле конфигурации машины для систем без подключенного графического дисплея, не поддерживающих функции виртуального терминала.

USER_CLASSES

Список классов для глобального наследования, которые используются системой сборки OE для включения дополнительных свойств (например, buildstats, image-mklibsи т. п.). Принятый по умолчанию список задается в файле local.conf как USER_CLASSES ?= “buildstats image-mklibs image-prelink”. Примером может служить файл meta-poky/conf/local.conf.sample в каталоге исходных кодов.

USERADD_ERROR_DYNAMIC

При установке значения error заставляет систему сборки OE выдавать сообщение об ошибке, если идентификаторы пользователя (uid) и группы (gid) не заданы в файлах files/passwd и files/group. При установке значения warn будут выводиться предупреждения.

По умолчанию система сборки динамически применяет значения uid и gid,поэтому переменнаяUSERADD_ERROR_DYNAMIC не устанавливается. Если нужны статические идентификаторы, следует задать в файле local.conf переменную USERADD_ERROR_DYNAMIC = “error”. Переопределение принятого по умолчанию поведения предполагает установку статических значений uid и gid с помощью переменных USERADDEXTENSION, USERADD_UID_TABLESиUSERADD_GID_TABLES.

USERADD_GID_TABLES

Задает файл паролей, используемый для получения статических идентификаторов групп (gid) при добавлении группы системой сборки OE в процессе установки пакета. При использовании статических значений gidсистема сборкиOE ищет в пути BBPATH файл files/groupи применяет значения идентификаторов. Переменная задается в файле local.confкакUSERADD_GID_TABLES = “files/group”. Для использования статических значений gid устанавливаетсяUSERADDEXTENSION = “useradd-staticids”.

USERADD_PACKAGES

При наследовании класса useradd эта переменная задает отдельные пакеты задания, для которых нужно добавлять пользователей или группы. Например, для добавления пользователя в основном пакете задания служит строка USERADD_PACKAGES = “${PN}”.

При использовании переменной USERADD_PACKAGES нужно задать одну или несколько переменных USERADD_PARAM, GROUPADD_PARAMилиGROUPMEMS_PARAM.

USERADD_PARAM

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

     USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
                            --no-create-home --shell /bin/false \
                            --user-group messagebus"

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

USERADD_UID_TABLES

Задает файл паролей, используемый для получения статических идентификаторов пользователей (uid) при добавлении системой сборки OE пользователя в процессе установки пакета. При использовании статических значений uidсистема сборкиOE ищет в пути BBPATH файл files/passwd и применяет найденные значения uid. Переменная задается в файле local.conf как USERADD_UID_TABLES = “files/passwd”. Для использования статических идентификаторов указывается USERADDEXTENSION = “useradd-staticids”.

USERADDEXTENSION

Значение useradd-staticids заставляет систему сборки OE при добавлении пользователей и групп применять статические файлы passwd и group найденные в пути BBPATH. Для этого в файл local.conf включается строка USERADDEXTENSION = “useradd-staticids”, в результате чего система сборки OE реализует класс useradd-staticids. При использовании статических значений uid и gid нужно указать файлы files/passwd и files/group в переменных USERADD_UID_TABLES и USERADD_GID_TABLES,а также задать переменнуюUSERADD_ERROR_DYNAMIC.

V

VOLATILE_LOG_DIR

Задает постоянное наличие на целевой платформе каталога /var/log, используемого для записи журналов операций пост-установки. По умолчанию задано VOLATILE_LOG_DIR = “yes”, что означает временные файлы журналов, а для постоянного их хранения следует установить значение “no”.

W

WARN_QA

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

WKS_FILE_DEPENDS

При включении в задание, создающее образ, эта переменная указывает зависимости при сборке. Переменная используется только при активных образах Wic (IMAGE_FSTYPES содержит связанные с Wic записи).

WKS_FILE_DEPENDS похожа на переменную DEPENDS и может применяться в заданиях, собирающих образы Wic, добавляя зависимости к указанным в DEPENDS. Переменная позволяет задать список дополнительных зависимостей (например, естественные инструменты, загрузчики и т. п.), которые нужны для сборки образов Wic. Например, WKS_FILE_DEPENDS = “some-native-tool” указывает тот или иной естественный инструмент, от которого зависит сборка образа.

WKS_FILE

Задает расположение файла Wic kickstart, используемого системой сборки OE для создания образа с разделами (image.wic). Информация о работе с такими образами приведена в разделе Creating Partitioned Images Using Wic [2], а формат kickstart описывает Глава 9. Справочник по OpenEmbedded Kickstart (.wks).

WORKDIR

Имя рабочего каталога, в котором система OE собирает задание. Этот каталог размещается в структуре TMPDIRи относится к собираемому заданию. Каталог WORKDIR определяется выражением ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}

Реальный каталог зависит от нескольких аспектов:

TMPDIR -выходной каталог верхнего уровня для сборки;
MULTIMACH_TARGET_SYS – идентификатор целевой системы;
PN - имя задания;
EXTENDPE - эпоха (если переменная PE не задана, как в большинстве заданий, значение EXTENDPE пусто);
PV - версия задания;
PR - выпуск (revision) задания.

В качестве примера рассмотрим Source Directory верхнего уровня с именем poky, заданный по умолчанию каталог сборки poky/build и целевую систему qemux86-poky-linux. Пусть задание называется foo_1.3.0-r0.bb. В этом случае рабочим каталогом для сборки будет poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0

X

XSERVER

Указывает пакеты, которые нужно установить для поддержки X-сервера и драйверов для текущей машины при условии непосредственного включения в образ packagegroup-core-x11-xserver или опосредованного включения x11-base в IMAGE_FEATURES. По умолчанию значением XSERVERбудет xserver-xorg xf86-video-fbdev xf86-input-evdev, если в конфигурации машины не указано иное.

Глава 14. Контекст переменных

Хотя большинство переменных может применяться почти в любом контексте (файлы .conf, .bbclass, .inc, .bb), некоторые из них зачастую связаны с конкретным местом или контекстом. В этой главе описаны базовые привязки переменных к контексту.

14.1. Конфигурация

В последующий параграфах перечислены переменные конфигурации с контекстом distribution, machine и local.

14.1.1. Дистрибутив (Distro)

Переменные, контекстом которых служит конфигурация дистрибутива (distro), включают DISTRO, DISTRO_NAME, DISTRO_VERSION, MAINTAINER, PACKAGE_CLASSES, TARGET_OS, TARGET_FPU, TCMODE, TCLIBC.

14.1.2. Машина

Переменные, контекстом которых служит конфигурация машины, включают TARGET_ARCH, SERIAL_CONSOLES, PACKAGE_EXTRA_ARCHS, IMAGE_FSTYPES, MACHINE_FEATURES, MACHINE_EXTRA_RDEPENDS, MACHINE_EXTRA_RRECOMMENDS, MACHINE_ESSENTIAL_EXTRA_RDEPENDS, MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS.

14.1.3. Локальные переменные

Переменные, контекстом которых служит локальная конфигурация в файле local.conf,включаютDISTRO, MACHINE, DL_DIR, BBFILES, EXTRA_IMAGE_FEATURES, PACKAGE_CLASSES, BB_NUMBER_THREADS, BBINCLUDELOGS, ENABLE_BINARY_LOCALE_GENERATION.

14.2. Задания

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

14.2.1. Требуемые переменные

В заданиях должны присутствовать переменные LICENSE, LIC_FILES_CHKSUMиSRC_URI (для заданий, извлекающих локальные или удаленные файлы).

14.2.2. Зависимости

Зависимости между заданиями указываются в переменных DEPENDS, RDEPENDS, RRECOMMENDS, RCONFLICTSиRREPLACES.

14.2.3. Пути

Переменные, определяющие пути в заданиях, включают WORKDIR, S, FILES.

14.2.4. Дополнительная информация для сборки

Переменные, определяющие дополнительные данные для сборки заданий, включают DEFAULT_PREFERENCE, EXTRA_OECMAKE, EXTRA_OECONF, EXTRA_OEMAKE, PACKAGECONFIG_CONFARGS, PACKAGES.

Глава 15. Ответы на вопросы

15.1. Различия между Poky и OpenEmbedded

Термин Poky относится к конкретной системе сборки, предоставляемой YP и основанной на OE-Core и BitBake. Таким образом, базовым термином для систем сборки является «система сборки OE». Работа в YP с использованием Poky тесно связана с OE, при этом изменения сначала передаются в OE-Core или BitBake, а затем возвращаются в Poky. Это полезно для обоих проектов.

15.2. Выполнение требований к Git, tar и Python

Нужны версии программ для сборочного хоста можно получить разными способами, описанными в параграфе 1.3. Требуемые версии Git, tar и Python.

15.3. Стабильность работы Poky/OpenEmbedded-Core

Команда YP поддерживает уровень OE-Core компактным и целенаправленным, включая в него около 830 заданий в отличие от тысяч других, доступных в сообществе OE. Это упрощает тестирование и поддержку.
Команда YP проводит ручное и автоматизированное тестирование для небольшого набора эталонного оборудования и эмулируемых платформ.
В YP применяется автоматический сборщик, который обеспечивает тестирование сборки и интеграции.

15.4. Включение поддержки платы в YP

Поддержка новой платы добавляется созданием уровня BSP для нее. Создание уровня BSP описано в разделах Understanding and Creating Layers [2] и Yocto Project Board Support Package (BSP) Developer’s Guide [6]. Если плата не является совсем экзотической, добавление ее поддержки в YP достаточно просто.

15.5. Продукция, использующая систему сборки OE

Программы, работающие на Vernier LabQuest, используют систему сборки OE (см. сайт Vernier LabQuest). Существует множество подготовленных к производству (pre-production) устройств, использующих систему сборки OE и команда YP анонсирует их по мере выпуска.

15.6. Вывод системы сборки OE

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

15.7. Добавление своего пакета в YP

Для добавления пакета нужно создать задание BitBake, как описано в разделе Writing a New Recipe [2].

15.8. Обновление программ на целевой платформе

Система сборки OE может создавать пакеты в разных форматах, включая IPK для OPKG, Debian (.deb) и RPM. Можно обновлять пакеты с помощью менеджера пакетов на устройстве, как в обычных дистрибутивах Linux. Однако управление пакетами на целевой платформе реализуется не всегда.

15.9. Ошибки chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x

Возможно вы запустили сборку на файловой системе NTFS, хотя следует применять ext2, ext3 или ext4.

15.10. Ошибка 404 при загрузке исходных кодов в систему сборки OE

Ничего страшного! Система сборки OE проверяет все указанные зеркала исходных кодов в поисках архивов и заранее выбранных версий управляемых SCM программ. Эта проверка помогает при крупных инсталляциях, поскольку может снизить нагрузку на серверы SCM. Указанный в ошибке адрес просто является одним из настроенных в системе сборки зеркал.

15.11. Машинозависимые данные в пакете

Установите SRC_URI_OVERRIDES_PACKAGE_ARCH = “0” в файле .bb и обеспечьте маркировку файла как машинозависимого вручную, если это нужно. Код обработки SRC_URI_OVERRIDES_PACKAGE_ARCH содержится в файле meta/classes/base.bbclass.

15.12. Работа через межсетевой экран

Большая часть выборок исходных кодов системой сборки OE выполняется с помощью утилиты wget, поэтому следует указать настройки прокси в файле .wgetrc, который может размещаться в домашнем каталоге или в /usr/local/etc/wgetrc.

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

     # You can set the default proxies for Wget to use for http, https, and ftp.
     # They will override the value in the environment.
     #https_proxy = http://proxy.yoyodyne.com:18023/
     #http_proxy = http://proxy.yoyodyne.com:18023/
     #ftp_proxy = http://proxy.yoyodyne.com:18023/

     # If you do not want to use proxy at all, set this to off.
     #use_proxy = on

YP также включает файл meta-poky/conf/site.conf.sample, показывающий настройки прокси-серверов для CVS и Git. Дополнительная информация о настройке разных типов прокси приведена на странице Working Behind a Network Proxy.

15.13. Различие между `target` и `target-native`

Цели *-native предназначены для работы на системах, применяемых для сборки. Обычно это инструменты, требуемые для помощи при сборке (например, quilt-native
служит для применения patch-файлов). Не относящиеся к естественные (non-native) задания работают на целевых платформах.

15.14. Непонятные отказы при сборке

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

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

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

15.15. Проблемы с `iconv.h` при сборке естественных заданий

При получении сообщения об ошибке, указывающего, что библиотека GNU libiconv не применяется, но файл iconv.h включен из libiconv, нужно проверить наличие ранее установленной версии в файлах заголовков /usr/local/include.

     #error GNU libiconv not in use but included iconv.h is from libiconv

Если такой файл найден, следует удалить прежнюю установку (uninstall) или временно переименовать файл.

Эта проблема является проявлением «утечки системы», когда система сборки OE находит и использует установленные ранее файлы при сборке естественного кода. Такая ошибка может быть связана не только с iconv.h. Убедитесь, что утечка не происходит из каталогов /usr/local/include и /opt.

15.16. Лицензионные требования

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

Информация о лицензировании представлена в разделе Licensing [1] и Maintaining Open Source License Compliance During Your Product’s Lifecycle [2].

15.17. Отключение курсора на сенсорном экране

Нужно добавить файл форм-фактора, как описано в разделе Miscellaneous BSP-Specific Recipe Files [6]. Для переменной HAVE_TOUCHSCREEN устанавливается значение 1.

15.18. Активизация сетевых интерфейсов

Используемый по умолчанию файл interfaces из задания netbase не активизирует сетевые интерфейсы автоматически. Поэтому нужно добавить зависящее от BSP задание netbase, которое включает файл interfaces (см. раздел Miscellaneous BSP-Specific Recipe Files [6]). Например, можно добавить на свой уровень файлы

     meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
     meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend

15.19. Увеличение свободного пространства для образа

По умолчанию система сборки OE использует коэффициент 1,3 при расчете размера корневой файловой системы. Для изменения размера нужно установить несколько параметров, описанных ниже.

Размер образа. Система сборки OE использует переменную IMAGE_ROOTFS_SIZE для задания размера образа в килобайтах. Размер определяется с учетом начальной корневой файловой системы до внесения каких-либо изменений (таких как запрошенный размер и дополнительное свободное место).
Служебное пространство. Переменная IMAGE_OVERHEAD_FACTOR задает коэффициент, применяемый при расчете размера (по умолчанию 1,3).
Дополнительное свободное пространство. Переменная IMAGE_ROOTFS_EXTRA_SPACE служит для добавления свободного пространства в образ после определения IMAGE_ROOTFS_SIZE.

15.20. Поддержка имен файлов и каталогов с пробелами

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

15.21. Использование внешнего инструментария

Настройка инструментария обеспечивает достаточную гибкость и контролируется в основном переменной TCMODE,которая указывает файлtcmode-*.inc file для включения каталога meta/conf/distro/include в дереве исходных кодов. По умолчанию переменная TCMODE имеет значение default, которое задает системе сборки OE использование встроенного инструментария (файл tcmode-default.inc). Однако можно задать и другие инструменты. В частности, значения external-* позволяют применять внешний инструментарий. Примером может служить использование Sourcery G++ Toolchain, поддержка которого задана в отдельном уровне meta-sourcery,доступном по ссылке http://github.com/MentorEmbedded/meta-sourcery/.

В дополнение к настройке инструментов можно задать и файл задания для инструментария, который должен упаковать заранее собранные объекты, такие как libgcc, libstdcc++, файлы locale и libc.

15.22. Работа OE через межсетевой экран и прокси

Способ получения системой сборки исходных кодов поддерживает множество настроек. Вы можете обеспечить ее доступ к исходным кодам в большинстве случаев, если доступен транспорт HTTP.

При поиске исходных кодов система сборки сначала просматривает локальный каталог загрузки, затем используется переменная PREMIRRORS, «восходящий» источник и переменная MIRRORS в указанном порядке.

Для дистрибутива poky система сборки OE использует источники YP из переменной PREMIRRORS по умолчанию в качестве источников SCM и обновлений для обычных архивов, а затем возвращается к другим зеркалам, если с зеркалом YP возникает отказ.

Например, можно добавить конкретный сервер, который система сборки будет проверять раньше других, путем включения в файл local.conf строк, подобных приведенным ниже.

     PREMIRRORS_prepend = "\
     git://.*/.* http://www.yoctoproject.org/sources/ \n \
     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
     http://.*/.* http://www.yoctoproject.org/sources/ \n \
     https://.*/.* http://www.yoctoproject.org/sources/ \n"

Эти изменения заставят систему сборки перехватывать запросы Git, FTP, HTTP, HTTPS и направлять из зеркалу http://. Можно использовать URL file://для указания локальных или сетевых каталогов.

Существует также другой вариант BB_NO_NETWORK = “1”.

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

Еще одним решением служит BB_FETCH_PREMIRRORONLY = “1”.

Этот оператор ограничивает систему сборки извлечением файлов лишь из источников, заданных переменной PREMIRRORS.Этот метод полезен для воспроизведения сборок.

Можно также использовать оператор BB_GENERATE_MIRROR_TARBALLS = “1”.

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

В заключение рассмотрим пример работы через межсетевой экран, пропускающий только трафик HTTP. Можно внести приведенные ниже изменения в файл local.conf,если по умолчанию используется сервер изPREMIRRORS.

     PREMIRRORS_prepend = "\
     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
     http://.*/.* http://www.yoctoproject.org/sources/ \n \
     https://.*/.* http://www.yoctoproject.org/sources/ \n"
     BB_FETCH_PREMIRRORONLY = "1"

Это заставит систему сборки извлекать все источники по протоколу HTTP, а все обращения к источникам, не указанным в PREMIRRORS будут приводить к отказу.

Система сборки также принимает во внимание стандартные переменные окружения http_proxy, ftp_proxy, https_proxy и all_proxy для перенаправления запросов на промежуточные серверы (proxy). Дополнительную информацию можно найти на странице Working Behind a Network Proxy.

15.23. Очистка результатов предыдущей сборки

Очистить результаты предыдущей сборки достаточно просто. При использовании BitBake для сборки образа весь вывод помещается в каталог, созданный при запуске сценария настройки окружения (например. oe-init-build-env). По умолчанию сборочный каталог называется build,но можно назвать его иначе. В сборочном каталоге имеется подкаталог tmp. Для удаления вывода сборки с сохранением исходных кодов и загруженных файлов достаточно удалить содержимое каталога tmp.

15.24. Странные значения `${bindir}` и `${libdir}` для заданий `-native`

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

Этот случай является фундаментальной проблемой для людей, поддерживающих пакеты основных дистрибутивов Linux, а также для системы сборки OE. Поэтому имеется устоявшееся решение проблемы. Предполагается, что файлы Makefile, инструменты автоматической настройки и другие системы сборки будут учитывать переменные окружения, такие как bindir, libdirиsysconfdir,указывающие расположение исполняемых файлов, библиотек и данных при фактическом выполнении программы. Также предполагается учет переменнойDESTDIR, которая добавляется перед всеми другими переменными при установке файлов системой сборки. Понятно, что на деле программа не запускается из DESTDIR.

Когда система OE использует задание для сборки программу под целевую архитектуру (т. е. одно из предназначенных для включения в создаваемый образ), эта программа в конечно итоге запускается из корневой файловой системы этого образа. Таким образом, система сборки подставляет значение /usr/bin для bindir, /usr/lib для libdirи т. д.

DESTDIR является путем в каталоге сборки. Однако при сборке заданием естественной (т. е. предназначенной для сборочного хоста) программы она не будет устанавливаться в корневую систему сборочного хоста. Поэтому система сборки использует пути внутри сборочного каталога для DESTDIR, bindir и связанных переменных. Чтобы лучше понять это, рассмотрим два пути, из которых первый представляется обычным, а второй – нет.

     /home/maxtothemax/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/
        1.2.8-r0/sysroot-destdir/usr/bin

     /home/maxtothemax/poky-bootchart2/build/tmp/work/x86_64-linux/
        zlib-native/1.2.8-r0/sysroot-destdir/home/maxtothemax/poky-bootchart2/
        build/tmp/sysroots/x86_64-linux/usr/bin

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

15.25. Проблемы с заданиями `*-native`

Заданиене доступно для других заданий. Файлы отсутствуют в естественном sysroot, задание устанавливается в некорректное место или возникают ошибки с правами доступа в задаче do_install.

Такая ситуация возникает, когда система сборки не распознает переменные окружения, предоставленные ей программой BitBake. Такая проблема возникала с файлом Makefile, в котором использовалась переменная окружения BINDIR вместо стандартной переменной bindir. Жестко заданное значение /usr/bin работает в большинстве случаев, но не вариантом -native для задания. Ошибки с правами доступа могут быть вызваны файлом Makefile, который игнорирует DESTDIR или использует иное имя для этой переменной окружения.

Глава 16. Участие в разработке и дополнительная информация

16.1. Введение

Команда YP рада людям, экспериментирующим с YP. Имеется множество способов получения помощи при возникновении трудностей или ошибок. Здесь также представлена информация об участии в работе YP.

16.2. Вклад в разработку

YP с удовольствие принимает вклад других людей. Вы можете представить свои изменения в проект путем создания о и отправки запроса (pull) или прислав patch-файлы по электронной почте. Информация об обоих способах и определении ответственного за поддержку каждой области кода приведена в разделе Submitting a Change to the Yocto Project [2].

16.3. Yocto Project Bugzilla

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

Иногда полезно зафиксировать, исследовать или отследить ошибку в самом YP (например, при возникновении проблем с поведением системы сборки, не соответствующим документации или ожиданиям).

Существуют базовые процедуры и рекомендации по представлению ошибок в Bugzilla. Информацию о фиксации ошибок в YP можно найти:

в разделе Submitting a Defect Against the Yocto Project [2];
на странице Bugzilla wiki.

Информация о системе Bugzilla в целом доступна по ссылке http://www.bugzilla.org/about/.

16.4. Списки рассылки

Имеется множество списков рассылки, поддерживаемых YP, а также списки OE для обсуждения, представления правок и анонсов. Подписаться на интересующую рассылку можно с помощью приведенных ниже ссылок.

http://lists.yoctoproject.org/listinfo/yocto – общие вопросы YP.
http://lists.openembedded.org/mailman/listinfo/openembedded-core – обсуждение OpenEmbedded-Core.
http://lists.openembedded.org/mailman/listinfo/openembedded-devel – обсуждение OE.
http://lists.openembedded.org/mailman/listinfo/bitbake-devel – обсуждение BitBake.
http://lists.yoctoproject.org/listinfo/poky – обсуждение Poky.
http://lists.yoctoproject.org/listinfo/yocto-announce – анонсы выпусков YP и другие важные сообщения.

Дополнительная информация о рассылках приведена на сайте Yocto Project.

16.5. Дополнительная информация

Сайт Yocto Project
Страница Yocto Project Wiki. Основная страница wiki для YP, содержащая сведения о планировании проекта, устройстве выпусков, контроле качества и автоматизации и т. п.
OpenEmbedded – сборочная система YP, служащая основой для Poky.
BitBake – инструмент для обработки метаданных.
Yocto Project Mega-Manual – один файл HTML, включающий все руководства YP. Удобен для контекстного поиска.
FAQ – ответы на часто задаваемые вопросы.
Release Notes. Свойства, обновления и возможные проблемы для текущего выпуска YP. Документы Release Notes доступны на странице Downloads сайта YP по ссылке RELEASE INFORMATION для нужного выпуска.
Bugzilla – система отслеживания ошибок в YP, позволяющая каждому сообщить о возникшей проблеме.
Bugzilla Configuration and Bug Tracking Wiki Page. Информация об установке и использовании YP Bugzilla для записи и отслеживания дефектов YP.
Internet Relay Chat (IRC). Два канала IRC для обсуждения YP (#yocto) и Poky (#poky).
Quick EMUlator (QEMU). Система эмуляции и виртуализации с открытым исходным кодом.

Литература

[1] Yocto Project Overview and Concepts Manual⁴, https://www.yoctoproject.org/docs/2.7.1/overview-manual/overview-manual.html.

[2] Yocto Project Development Tasks Manual, http://www.yoctoproject.org/docs/2.7.1/dev-manual/dev-manual.html.

[3] Yocto Project Linux Kernel Development Manual⁵, http://www.yoctoproject.org/docs/2.7.1/kernel-dev/kernel-dev.html.

[4] BitBake User Manual⁶, https://www.yoctoproject.org/docs/2.7.1/bitbake-user-manual/bitbake-user-manual.html.

[5] Yocto Project Quick Build, https://www.yoctoproject.org/docs/2.7.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html.

[6] Yocto Project Board Support Package (BSP) Developer’s Guide, http://www.yoctoproject.org/docs/2.7.1/bsp-guide/bsp-guide.html.

[7] Yocto Project Application Development and the Extensible Software Development Kit (eSDK)⁷, http://www.yoctoproject.org/docs/2.7.1/sdk-manual/sdk-manual.html.

[8] Toaster User Manual, https://www.yoctoproject.org/docs/2.7.1/toaster-manual/toaster-manual.html.

[9] Yocto Project Profiling and Tracing Manual, https://www.yoctoproject.org/docs/2.7.1/profile-manual/profile-manual.html.

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1GNU Project Debugger – отладчик проекта GNU.

2System On Chip – система на кристалле.

3Secondary Program Loader – вторичный загрузчик программ.

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

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

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

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

O

P

R

S

T

U

V

W

X

Глава 14. Контекст переменных

14.1. Конфигурация

14.1.1. Дистрибутив (Distro)

14.1.2. Машина

14.1.3. Локальные переменные

14.2. Задания

14.2.1. Требуемые переменные

14.2.2. Зависимости

14.2.3. Пути

14.2.4. Дополнительная информация для сборки

Глава 15. Ответы на вопросы

15.1. Различия между Poky и OpenEmbedded

15.2. Выполнение требований к Git, tar и Python

15.3. Стабильность работы Poky/OpenEmbedded-Core

15.4. Включение поддержки платы в YP

15.5. Продукция, использующая систему сборки OE

15.6. Вывод системы сборки OE

15.7. Добавление своего пакета в YP

15.8. Обновление программ на целевой платформе

15.9. Ошибки chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x

15.10. Ошибка 404 при загрузке исходных кодов в систему сборки OE

15.11. Машинозависимые данные в пакете

15.12. Работа через межсетевой экран

15.13. Различие между target и target-native

15.14. Непонятные отказы при сборке

15.15. Проблемы с iconv.h при сборке естественных заданий

15.16. Лицензионные требования

15.17. Отключение курсора на сенсорном экране

15.18. Активизация сетевых интерфейсов

15.19. Увеличение свободного пространства для образа

15.20. Поддержка имен файлов и каталогов с пробелами

15.21. Использование внешнего инструментария

15.22. Работа OE через межсетевой экран и прокси

15.23. Очистка результатов предыдущей сборки

15.24. Странные значения ${bindir} и ${libdir} для заданий -native

15.25. Проблемы с заданиями *-native

Глава 16. Участие в разработке и дополнительная информация

16.1. Введение

16.2. Вклад в разработку

16.3. Yocto Project Bugzilla

16.4. Списки рассылки

16.5. Дополнительная информация

Литература

Рубрики

Свежие записи

Архивы

Мета

15.13. Различие между `target` и `target-native`

15.15. Проблемы с `iconv.h` при сборке естественных заданий

15.24. Странные значения `${bindir}` и `${libdir}` для заданий `-native`

15.25. Проблемы с заданиями `*-native`