Пакет Userspace, созданный для и вместе с образом корневой файловой системы некоторой встроенной системы на базе Linux (с использованием проекта Yocto), очевидно, использует автоинструменты - можно увидеть Makefile.am и configure.ac в исходных кодах пакета. pkg-config или его преемник, похоже, тоже используется (присутствует .pc.in), но здесь он выходит за рамки. Пакет, находящийся в фокусе здесь, делает это таким образом (с привлечением автоинструментов), поскольку в начале его разработки, по-видимому, это была линия наименьшего сопротивления копированию и принятию сценариев сборки из аналогичного, но уже существующего пакета. На самом деле автоинструменты кажутся незаменимыми при сборке с помощью Yocto, поскольку метаданные системы сборки Yocto указывают цель достаточно точно для каждой цели. Не зря стандартный процесс сборки в Yocto - это загрузка, распаковка, исправление, настройка, сборка и т. Д., При этом сканирование и обнаружение целевой среды не включены в эту цепочку.
Теперь мне интересно, было ли хорошо упростить процесс сборки пакета, удалив этап автоинструментов. Я собираюсь выполнить это, выполнив последовательность из нескольких шагов, начиная с замены файла .am на настоящий make-файл. Вопрос в том, хватит ли этого, чтобы найти env. переменные, определенные и используемые в .am и .ac, а затем передать их в make-файл? Оставшаяся спецификация целевого устройства должна фактически быть получена из метаданных системы сборки Yocto. Возможно, это будет работать так просто, если собрать пакет в рамках сборки образа корневой файловой системы. Но как обеспечить полную спецификацию целевого устройства в среде сборки при сборке только этого пакета bitbake package-name?
