Почему Yocto SDK не может создать Yocto SDK?

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

Я проработал:

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

В конце концов, похоже, что это и есть Святой Грааль Yocto / OE.

Похоже, что наиболее функциональная среда x86_64 получена из:

git clone git://git.yoctoproject.org/poky

Он более эффективен, чем SDK, но как мне создать кросс-платформу для другой платформы?

Есть ли такой же функциональный SDK, как эта git clone'd среда? Это означает, что у него есть рабочий битовый код, и я могу создавать загрузочные образы для разных целей?

Вопросов:

  • Почему SDK не может создать SDK? (например, http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/buildtools/)

    • Why doesn't an SDK even include bitbake? (The ext SDK does, but doesn't like to add it to the path).
    • Почему расширяемый SDK с правильно подобранным env (и bitbake, добавленным в путь), похоже, предпочитает инструменты сборки, установленные в дистрибутиве, а не те, что в SDK? (при прямом использовании bitmake вместо devtool)

  • Почему SDK явно привязан к сборке для конкретной машины или архитектуры и, по-видимому, не может выполнять кросс-сборку для разных архитектур? Процесс создания SDK даже желает, чтобы окончательная архитектура была определена заранее.

То, к чему я привык, это build-sysroot с кросс-инструментальной цепочкой, работающей под своего рода псевдо / proot / chroot с моими вмонтированными в него исходниками.

Я понимаю, что Yocto / bitbake делает это под капотом, все кеширование рецептов кажется отличным, проверка клонирования git кажется мощной, рабочий процесс devtool кажется отличным, но затем все падает, когда я пытаюсь стандартизировать генерацию этой среды или сделать это кросс-компиляция.

(Я ожидаю получить файл среды из целевого каталога, содержащего некоторые локальные файлы conf для специализации сборки, а затем использовать bitbake для создания сборки)

Что я пропустил? - спасибо, что дочитали до этого места ;-)


yocto sdk extensible
person Sam Liddicott    schedule 14.03.2019    source источник
comment
Я никогда не пробовал ext-sdk, но обычно я работаю напрямую со слоями и рецептами Yocto, с poky, meta-openembedded плюс слой производителя, то есть meta-intel. Затем я добавляю персональный слой для специфики дистрибутива и еще один для модификаций BSP. Если я хочу поддерживать несколько машин, я добавляю соответствующий уровень поставщика + личный уровень BSP. Я (Дженкинс Джобс) создаю только стандартный SDK для разработчиков, и они обычно работают только на одной конкретной машине. Не знаю, поможет ли это.   -  person Nayfe    schedule 16.03.2019

Ответы (2)


arrow_upward
1
arrow_downward

SDK - это такое общее слово, что в контексте yocto его можно не интерпретировать, поэтому ваш вопрос является законным.

Yocto - замечательный инструмент для создания полностью настраиваемых образов, который можно настраивать на всех уровнях (загрузчик, ядро, приложения) на основе исходного кода, полученного из Интернета. SDK, который вы можете создать с помощью yocto, указан в документации:

Стандартный SDK предоставляет набор инструментов для кросс-разработки и библиотеки, адаптированные к содержимому конкретного изображения.

Исходя из моего небольшого опыта работы с Yocto, вы используете метаслои для создания и настройки вашей среды. Когда ваша среда настроена, вы можете сгенерировать SDK для простой кросс-компиляции ваших прикладных программ для вашей целевой машины. Инструмент Yocto слишком мощный, тяжелый и сложный для разработчиков, которые просто сосредотачиваются на прикладной части проекта. SDK с другой стороны идеально подходит для этого использования, но с его помощью вы не можете ничего изменить в цепочке инструментов, вы можете только использовать его. Если, например, необходимо применить ошибку или исправление в библиотеках времени выполнения, вам необходимо повторно сгенерировать SDK и предоставить эти новые версии разработчикам.

С этими краткими пояснениями:

Он более эффективен, чем SDK, но как мне создать кросс-платформу для другой платформы?

Вам необходимо настроить мета-слои Yocto для перехода с одной платформы на другую.

Есть ли такой же функциональный SDK, как эта среда git clone'd? Это означает, что у него есть рабочий битовый код, и я могу создавать загрузочные образы для разных целей?

Нет я так не думаю

Почему SDK не может создать SDK?

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

Почему SDK даже не включает bitbake?

Bitbake - это инструмент для анализа рецепта yocto (то есть мета-слоев), поэтому нет необходимости иметь этот инструмент в SDK.

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

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

person Martin    schedule 17.03.2019
comment
Спасибо за подробный ответ ... В качестве продолжения, что построило то, что проверено poky clone? Есть ли набор мета-слоев, к которым можно было бы применить SDK для создания этого наиболее функционального клона? Я имею в виду, что если мне нужен этот самый функциональный и убогий клон для ARM? Благодарность - person Sam Liddicott; 19.03.2019

arrow_upward
0
arrow_downward

Чтение из https://www.yoctoproject.org/docs/2.6.1/ref-manual/ref-manual.html#cross-development-toolchain

кажется, что SDK и eSDK являются примерами перемещаемой инструментальной цепочки;

Перемещаемый набор инструментов, используемый разработчиками за пределами BitBake при разработке приложений, которые будут работать на целевом устройстве.

Это предложение особенно выделяет игру:

Вы также можете найти дополнительную информацию об использовании перемещаемого набора инструментов в руководстве Yocto Project Application Development и Extensible Software Development Kit (eSDK).

Итак, я предполагаю, что проверка git-clone-poky, которая создает SDK и eSDK, выглядит следующим образом:

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

Без сомнения, меня интересуют:

концепции инструментальных средств применительно к Yocto Project

и должен:

см. раздел «Создание цепочки инструментов для кросс-разработки» в Руководстве по обзору и концепциям проекта Yocto https://www.yoctoproject.org/docs/2.6.1/overview-manual/overview-manual.html#cross-development-toolchain-generation

Конечно, первое изображение дает понять, что SDK предназначен для создания приложений, а не изображения. Я хочу создать образ (который, конечно, может содержать приложения).

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

Также может случиться так, что цепочка инструментов, используемая для создания образа, может быть запущена в SDK, чтобы использовать цепочку инструментов SDK, а не цепочку инструментов основного дистрибутива Linux нет, вы не можете

person Sam Liddicott    schedule 20.03.2019