OpenEmbedded/Рабочий каталог
Материал из b4wiki
Содержание |
Что живет в tmp?
Если заглянуть в директорию tmp, которую создал BitBake в процессе сборки, мы увидим кучу непонятных каталогов:
tmp/ |-- abi_version |-- cache |-- cross |-- deploy |-- distro_pr |-- pkgdata |-- rootfs |-- saved_tmpdir |-- staging |-- stamps `-- work
Попробуем разобраться что это такое.
tmp/work
Тут происходит все самое интересное. При сборке пакета, его исходники из ${DL_DIR} копируются в tmp/work/<PACKAGE_ARCH>/<PACKAGE-NAME_VERSION_ARCH>/ и уже в этом каталоге происходит конфигурирование, накладывание патчей и компиляция и сборка в пакет.Этот путь для каждого пакета доступен через переменную ${WORKDIR} (о переменный в следующих сериях). Причем у каждого пакета в ${WORKDIR} есть еще и подкаталоги:
temp - тут живут логи и скрипты, запускающие отдельные задачи для пакета. Если какой-либо из этапов сборки не получился, нам прямая дорога сюда - читать логи и много думать.
<name>-<version> - это, собственно, исходный код пакета. Внутри *.bb файла этого пакета, данный путь доступен через переменную ${S}
image - вместо того, чтобы инсталлить собранные программы в / вашего компьютера (я бы расстроился, если бы тот же busybox собранный под arm заменил половину бинарников на моем компе), BitBake использует эту папку как корневую файловую систему. И все собранные проги копируются сюда. Внутри *.bb файла этот путь доступент как ${D}.
install - Из одного *.bb файла можно собрать несколько пакетов (foo, foo-doc, foo-dev например). В общем задача этой директории сводится к разделению файлов по пакетам. Соотвественно для трех пакетов foo, foo-doc, foo-dev будут созданы три папки: install/foo, install/foo-doc, install/foo-dev и в них из ${D} (она же image) будут скопированы нужные файлы. А уж потом из этих папок будут собраны пакеты.
tmp/staging
Если для сборки пакета А.bb необходимы библиотеки или хедеры, которые содержаться в пакете B.bb - то сначала будет собран пакет B.bb, все необходимые файлы из него будут скопирвованиы в tmp/staging/ в разные папки для разных архитектур и операционных систем:
tmp/staging
|-- armv5te-linux
| `-- usr
|-- armv5te-linux-gnueabi
| |-- etc
| |-- lib
| |-- sbin
| |-- shlibs
| `-- usr
|-- b4-linux-gnueabi
| `-- kernel
`-- i686-linux
|-- etc
|-- shlibs
`-- usr
Т.е. если для сборки пакета b4-drv-base необходимы хедеры из ядра, подключаться они будут в tmp/staging/b4-linux-gnueabi.
tmp/deploy
Когда исходники скомпилированы, необходимые библиотеки/хедеры/etc положены в tmp/staging и программы запакованы в пакеты - эти пакеты копируется в tmp/deploy/ipk в соотвествии с архитектурой и ОС:
tmp/deploy/ipk/ |-- Packages |-- Packages.filelist |-- Packages.gz |-- Packages.stamps |-- all |-- armv5te |-- b4 `-- i686
Packages.* - это список пакетов и их версий и зависимостей, доступных в этом репозитории.
А если мы собираем не пакет, а образ файловой системы - по окончанию сборки он будет храниться в tmp/deploy/images
tmp/stamps
Тут вообще ничего интересного нет. Тут BitBake хранит временные метки для различных задач. В общем остлеживает что завершено, а что все еще ожидает завершения. Скукота.
tmp/cache
Интересно примерно так же как и tmp/stamps - после того, как BitBake распарсит все *.bb файлы - сюда он положит кеш, ускоряющий повторный парсинг.
tmp/rootfs
Образ файловой системы (rootfs или initramfs например). ACHTUNG - нельзя использовать нпрямую! Не надо пытаться загружаться прямо с нее! Для тех кому всеже захочется - она не содержит правильных файлов-устройств (/dev/*) и прав доступа.
tmp/cross
Тут живет тулчейн. Все что мы собираем под наше устройство собирается именно им. Цитирую OpenEmbedded Manual - это gcc и binutils, которые запускаются на нашем компе и генерят бинарники и либы под таргет девайс (в нашем случае под B4)
