Yocto. Передача хидера между рецептами через STAGING_DIR не работает

Фух: не вдруг-то и минимальные примеры накидаешь с этой вашей ёктой.

$ cat exampleproducer_1.1.bb 
LICENSE = "CLOSED"

PR = "r0"

do_compile(){
  touch ${S}/some_file
}

do_install(){
  install -m 0755 ${S}/some_file ${STAGING_DIR_TARGET}
}

$ cat exampleconsumer_1.1.bb 
LICENSE = "CLOSED"

PR = "r0"

DEPENDS += "exampleproducer"

do_compile(){
  [ ! -f ${STAGING_DIR_TARGET}/some_file ] && exit 1
}

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

та как-таки это делается?

Понятия не имею, что там в ёкте, но было бы логично предположить, что STAGING_DIR у каждого пакета свой

Штош, похоже ты прав: пока пытался состряпать для тебя ответ, таки разобрался.

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

$ cat exampleproducer_1.1.bb 
LICENSE = "CLOSED"

PR = "r0"

FILES_${PN} += "/usr/include"

do_compile(){
  touch ${S}/some_file
}

do_install(){
  install -d ${D}/usr/include
  install -m 0755 ${S}/some_file ${D}/usr/include
}

$ cat exampleconsumer_1.1.bb 
LICENSE = "CLOSED"

PR = "r0"

DEPENDS += "exampleproducer"

do_compile(){
  [ ! -f ${STAGING_DIR_TARGET}/usr/include/some_file ] && exit 1 || touch some_another_file
}

do_install(){
  sleep 1
}

Довольно интуитивно (нет)

Чтобы пакет А использовал файл от пакета Б, нужно, чтобы пакет Б установил его в сисрут. Что может быть более интуитивно?

А то, что всю жись для этого использовалась складская директория. А устанавливать надо было только файлы, которые должны попасть в итоговый образ: бинари и со-шки, но никак не хидеры и .а-шки.

Зачем тогда здесь стейджин дир вообще нужна, если она личная?

Зачем тогда здесь стейджин дир вообще нужна, если она личная?

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

А устанавливать надо было только файлы, которые должны попасть в итоговый образ: бинари и со-шки, но никак не хидеры и .а-шки.

Когда я работал с STLinux, в нём был отдельно sysroot со всеми файлами, и отдельно target, куда попадали только те файлы, которые должны оказаться в итоговом образе.

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

Если у тебя всё в одном рецепте собирается, то зачем тебе что-то передавать между рецептами?

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

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

Всё правильно. И интуитивно, да.

do_compile(){ [ ! -f ${STAGING_DIR_TARGET}/usr/include/some_file ] && exit 1 || touch some_another_file }

Ты делаешь что-то не то. Для начала ответь на мой первый вопрос, а так же расскажи, чем ты собираешь библиотеку и исполняемый файл (система сборки)

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

Как обычно, все из-за определений терминов )

Если у тебя всё в одном рецепте собирается, то зачем тебе что-то передавать между рецептами?

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

Хороший план: но я уже разобрался :)

Пока видно, что ты чем-то расстроен, но на мой вопрос ты так и не ответил.

В твоём примере у тебя 2 рецепта, а не один. Для обычных библиотек/заголовков есть страндартный подходи, ставить их в {includedir} и они подставятся в sysroot другого рецепта через зависимости. Пока не видно проблем.

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

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

И интуитивно, да.

Ну… видимо, не для всех :)

Нда…

Ты делаешь что-то не то.

Да. Я программируваю за деньги. А рожден я для счастья

Для начала ответь на мой первый вопрос

Терпение: ЛОР устроен так, что я читаю сверху вниз

расскажи, чем ты собираешь библиотеку и исполняемый файл (система сборки)

make

Терпение: ЛОР устроен так, что я читаю сверху вниз

Я никуда не тороплюсь. Это ты программируешь за деньги (я, кстати, тоже)

make

Печаль, конечно. Но я выше уже описал правильный порядок действий. Будешь ли ты пытаться сделать нормально, либо разводить говно в проекте - дело твоё.

Пока видно, что ты чем-то расстроен

Да. Ёкта большая, по 10 переменных под каждую мыслимую и немыслимую подзадачу. Во всем этом надо разбираться, тратить часы на непроизводительную работу. От того что я осознаю что толку воду в ступе, пусть даже и за деньги – я расстроен

но на мой вопрос ты так и не ответил.

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

В твоём примере у тебя 2 рецепта, а не один.

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

Для обычных библиотек/заголовков есть страндартный подходи, ставить их в {includedir} и они подставятся в sysroot другого рецепта через зависимости. Пока не видно проблем.

Ну если это знать, то действительно не видно проблем: проблема в том, что сие знание я не впитал с молоком матери.

А то что в долгосрочной переспективе это сделает поддержку проекта проще для тебя не является аргументом?

Является. (У меня была запланирована эта работа на будущее, как только решим более насущные дела.) Хотя это и дискуссионно: у меня ряд этих программок не просто так вместе собираются, они одна без другой не имеют смысла и по сути представляют собой единую программу. Зачем и кому они нужны по отдельности – загадка. Но тут есть что можно вытащить в отдельные рецепты тупо для скорости пересборки, ибо в одних частях правки происходят часто, а в других – никогда.

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

Полностью согласен про прибыль здесь и сейчас и про пох на будущее, только бизнес ну вот совсем не российский :) (думаешь у нас неправильные капиталисты? а они везде одинаковые)

Нда…

? а что не так? Сходил ради интереса посмотрел как сделано в zlib например, там:

do_install() {
        oe_runmake DESTDIR=${D} install
}

то есть - -так же как сделал я.

Я никуда не тороплюсь. Это ты программируешь за деньги

Так я все равно не тороплюсь: могу себе позволить

make

Печаль, конечно

почему?

Но я выше уже описал правильный порядок действий. Будешь ли ты пытаться сделать нормально, либо разводить говно в проекте - дело твоё.

Так а я, вроде, так и делаю, или я не понял чего? Отдельные рецепты, передача хидеров через инсталл в сисрут.

то есть - -так же как сделал я.

${D} и ${STAGING_DIR_TARGET} по-твоему одно и то же?

Тут я не туда посмотрел. Смутила проверка в do_compile(), которая там в принципе не нужна, если ты DEPENDS правильно выставил

make

Печаль, конечно

почему?

Архаичная система сборки, где кучу действий нужно делать вручную, особенно если у тебя есть зависимости

Смутила проверка в do_compile(), которая там в принципе не нужна, если ты DEPENDS правильно выставил

ну в боевом рецепте – конечно не нужна. Это ж тестовый химически-чистый пример был, я добивался чтоб заработало

FILES_${PN} += «/usr/include»

Это тоже лишнее. По умолчанию всё из /usr/include идёт в dev package.

Архаичная система сборки, где кучу действий нужно делать вручную, особенно если у тебя есть зависимости

То-то в екте ничего делать вручную не надо: по факту что в мейке звал install, что в екте – абсолютно одно и то же. Что в мейке прописывал зависимость одной цели от другой, что в екте одного рецепта от другого депендсом.

Только мейк уже все знают, а екту – учить надо.

Полностью согласен про прибыль здесь и сейчас и про пох на будущее, только бизнес ну вот совсем не российский :) (думаешь у нас неправильные капиталисты? а они везде одинаковые)

Зависит от твоей настойчивости. Если ты говоришь, что надо делать, то надо делать, а не поддаваться на «давайте побыстрее».

Это тоже лишнее

а вот без этого не собирается, говорит: «оно у тебя файлы инсталлит, а ты это не задекларировал»

Только мейк уже все знают, а екту – учить надо.

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

Какая версия yocto?

Зависит от твоей настойчивости

Меня менеджер слушается как правило. Но бывают случаи, когда решает не он, а донести мысль до вышестоящего руководства у него не всегда получается ( тут уж мои полномочия – все )

ну – мне мейк как родной.

Какая версия yocto?

Вот бы знать: poky 4.0.9 – оно?

Ну вроде kirkstone (4.0.x), должно всё работать. Надо весь рецепт смотреть, чтобы понять, почему в dev package заголовки не ушли по умолчанию.

Poky - это reference distribution.

Всё правильно. И интуитивно, да.

Еще вопрос, насчет интуитивности, если позволишь:

А как ёкта отличает какие файлы в таком случае складывать в итоговый образ, а какие файлы нужны только другим рецептам?

У меня часть файлов, установленных в ${D}/somewere появляется в результирующем образе, а часть – нет. Как екта угадывает?

https://docs.yoctoproject.org/ref-manual/variables.html#term-PACKAGES

Смотря о каких файлах речь. По умолчанию в образ идёт только основной пакет. Header’ы и т.п. идут в dev, который не ставится.

То есть, я могу управлять тем, попадет ли файл в итоговый образ или только в sysroot для зависящих рецептов, добавляя файл в FILES:${PN} или, скажем, FILES:${PN}-dev ?

Правильно ли я понимаю саму идею?

Примерно так, да.

Большое спасибо!

если есть желание, то можешь в телегу стукнуться UVV_tg