Существует огромное количество систем автоматизации сборки, как собственно отдельных пакетов программ, так и целых наборов, которые можно называть по-разному: прошивка, образ, дистрибутив. К числу последних относятся такие средства, как BuildRoot, OpenEmbedded, Yocto. Мы не будем сейчас углубляться в детальный сравнительный анализ подобных систем. Это требует отдельной серии статей, охватывающих отдельные области применения. И хотя сообщество все заметнее стремится в сторону Yocto, сужая тем самым предметную область, хочется сказать, что мир остается большим и разнообразным. Более того, разнообразие требований к системам сборки, со стороны различных коллективов, не снимает актуальности создания новых средств автоматизации.

Поэтому, здесь, я хочу представить систему сборки программного обеспечения Radix.pro, которая может служить основой для разработки различных дистрибутивов ПО встраиваемых систем. Система сборки включает в себя набор Make-файлов и скриптов, которые предоставляют средства для работы с архивами исходных пакетов, сборки пакетов, управления межпакетными зависимостями, а также средствами инсталляции пакетов, как во временное окружение, так и на целевой носитель. Разумется, существует возможность собирать отдельные программы, исходные коды которых не собраны в отчуждаемый пакет, построенный, например, с помощью утилит autoconf, automake.


Тестирование системы осуществляется на собственном дистрибутиве Linux, периодические сборки которого доступны для устройств на базе процессоров с архитектурами ARM (Cubieboard, Cubietrack, OMAP5 uEVM, Firefly-RK3288, Nitrogen6X), MIPS (MIPS Creator CI20) и x86/x86_64.



Особенности системы сборки:

• позволяет создавать проекты, удовлетворяющие современным требованиям управления конфигурациями (CM) и непрерывной интеграции (CI);
• ориентирована на одновременную, многопоточную сборку конечного продукта для нескольких целевых устройств с различной архитектурой;
• позволяет создавать как встроенное ПО для микроконтроллеров, так и дистрибутивы общего назначения;
• предоставляет механизмы управления межпакетными зависимостями и управления пакетами, как на стадии сборки продукта, так и во время работы на целевой машине;
• встроеные инструменты управления пакетами, которые позволяют автоматизировать создание временной целевой файловой системы во время процесса сборки, что можно использовать для тестирования создаваемого дистрибутива;
• все компоненты размещаются в одном каталоге, который монтируется в исходное дерево разрабатываемого продукта.

Вообще, на сайте Radix.pro развернута среда разработки ПО, включающая:

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

Однако система сборки представляет собой вполне отчуждаемый продукт и может быть использована в любых проектах. В разделе Build System in Practice, даются подробные пояснения, как быстро и довольно просто можно начать работу над собственным проектом. Здесь следует сказать, что помимо средств, упрощающих создание пользовательских Make-файлов, система сборки, во время инициализации, приготавливает такие утилиты как fakeroot, pseudo, genext2sf и populatefs, позволяющие создавать образы целевых файловых систем. Данные утилиты доступны пользователям, как во время сборки отдельных пакетов, так и в качестве средств пригтовления релизов.

Пользовательские сценарии сборки

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

Все вы знаете, что изучение средств программирования занимает огромную долю рабочего времени и, порой, настолько сильно отвлекает программиста от выполнения непосредственной задачи, что это становится уже неприемлемым с экономической точки зрения. Поэтому подход здесь такой. Программист должен оставаться в своей привычной среде и не должен быть обременен необходимостью изучать, либо применять, дополнительные языки, описывающие сценарии сборки и, поскольку речь идет о создании пакетов программ, то все остается в рамках средств утилиты GNU Make. Более того, в репозитории платформы Radix.pro уже насчитывается несколько сотен сценариев сборки, которые можно использовать в собственных проектах путем простого копирования с минимальными исправлениями под специальные нужды.

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

Большие проекты

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

Изначально, система ориентирована на производство ПО для линеек собственных аппаратных устройств коллективами разработчиков, насчитывающими большое число программистов. Поэтому основными задачами здесь были: обеспечение многопоточной, быстрой сбоки продукта, одновременно на несколько аппаратных платформ; обеспечение гибкости с точки зрения управления конфигурациями, высочайшая скорость создания локальных копий веток репозиториев (check out); скорость загрузки исходных пакетов перед сборкой; моментальное распространение положительного опыта в коллективе разработчиков.

Принципы, на которых базируется решение данных задач, отчасти изложены в разделе Development Environment и отражаются в исходных кодах репозитория платформы Radix.pro.

Межпакетные зависимости

На данный момент в мире не существует формального алгоритма построения дерева зависимостей пакетов друг от друга. Обусловлено это, прежде всего многообразием систем автоматизации процесса сборки, относящихся к разряду средств, используемых в рамках одного пакета, таких как GNU Autotools, CMake, qmake, Ant, Maven. Даже если усовершенствовать утилиту autoconf на предмет создания дерева зависимостей в форме, доступной формальному анализатору, то ошибки авторов проектов, все равно не дадут гарантированного результата, не говоря уже о том, что подобные усовершенствования необходимы всем средствам автоматизации.

Кроме того, изменение конфигурации одного из пакетов (например, отказ от отрисовки шрифтов с помощью пакета Cairo, или отказ от использования 3D графики, тем же Cairo), немедленно приведет к реорганизации дерева зависимостей всего дистрибутива.

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

В качестве заключения

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

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

Ведь после того, как вы собрали или просто установили какой-либо дистрибутив на Cubieboard или Raspberry Pi, вопросов не становится меньше. Разумеется, если Вы предпочитаете ВЛАДЕТЬ, а не ПОЛЬЗОВАТЬСЯ.