Исследование систем автоматической сборки на базе Linux на примере Open WRT

команда

...

...

Обычно, цель (target) представляет собой имя файла, который генерируется в процессе работы утилиты make. Примером могут служить объектные и исполняемый файлы собираемой программы. Цель также может быть именем некоторого действия, которое нужно выполнить (например, `clean' - очистить). Подробнее это обсуждает в разделе Абстрактные цели ).

Пререквизит (prerequisite) - это файл, который используется как исходдные данные для порождения цели. Очень часто цель зависит сразу от нескольких файлов.

Команда - это действие, выполняемое утилитой make. В правиле может содержаться несколько команд - каждая на свое собственной строке. Важное замечание: строки, содержащие команды обязательно должны начинаться с символа табуляции! Это - "грабли", на которые наступают многие начинающие пользователи.

Обычно, команды находятся в правилах с пререквизитами и служат для создания файла-цели, если какой-нибудь из пререквизитов был модефицирован. Однако, правило, имеющее команды, не обязательно должно иметь пререквизиты. Например, правило с целью `clean' ("очистка"), содержащее команды удаления, может не иметь пререквизитов.

Правило (rule) описывает, когда и каким образом следует обновлять файлы, указанные в нем в качестве цели. Для создания или обновления цели, make исполняет указанные в правиле команды, используя пререквизиты в качестве исходных данных. Правило также может описывать каким образом должно выполняться некоторое действие. Подробно это обсуждается в разделе Составление правил

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

http://rus-linux.net/nlib.php?name=/MyLDP/algol/gnu_make/gnu_make_3-79_russian_manual.html - TOC6

Пример простого make-файла

http://rus-linux.net/nlib.php?name=/MyLDP/algol/gnu_make/gnu_make_3-79_russian_manual.html - TOC6

Вот пример простого make-файла, в котором описывается, что исполняемый файл edit зависит от восьми объектных файлов, которые, в свою очередь, зависят от восьми соответствующих исходных файлов и трех заголовочных файлов.

В данном примере, заголовочный файл `defs.h' включается во все файлы с исходным текстом. Заголовочный файл `command.h' включается только в те исходные файлы, которые относятся к командам редактирования, а файл`buffer.h' - только в "низкоуровневые" файлы, непосредственно оперирующие буфером редактирования.

edit : main.o kbd.o command.o display.o \

insert.o search.o files.o utils.o

cc -o edit main.o kbd.o command.o display.o \

insert.o search.o files.o utils.o

main.o : main.c defs.h

cc -c main.c

kbd.o : kbd.c defs.h command.h

cc -c kbd.c

command.o : command.c defs.h command.h

cc -c command.c

display.o : display.c defs.h buffer.h

cc -c display.c

insert.o : insert.c defs.h buffer.h

cc -c insert.c

search.o : search.c defs.h buffer.h

cc -c search.c

files.o : files.c defs.h buffer.h command.h

cc -c files.c

utils.o : utils.c defs.h

cc -c utils.c

clean :

rm edit main.o kbd.o command.o display.o \

insert.o search.o files.o utils.o

Для повышения удобочитаемости, мы разбили длинные строки на две части с помощью символа обратной косой черты, за которым следует перевод строки.

Для того, чтобы с помощью этого make-файла создать исполняемый файл `edit', наберите:

make

Для того, чтобы удалить исполняемый и объектные файлы из директории проекта, наберите:

make clean

В приведенном примере, целями, в частности, являются объектные файлы `main.o' и `kbd.o', а также исполняемый файл `edit'. К пререквизитам относятся такие файлы, как `main.c' и `defs.h'. Каждый объектный файл, фактически, является одновременно и целью и пререквизитом. Примерами команд могут служить `cc -c main.c' и `cc -c kbd.c'.

В случае, если цель является файлом, этот файл должен быть перекомпилирован или перекомпонован всякий раз, когда был изменен какой-либо из его пререквизитов. Кроме того, любые пререквизиты, которые сами генерируются автоматически, должны быть обновлены первыми. В нашем примере, исполняемый файл `edit' зависит от восьми объектных файлов; объектный файл `main.o' зависит от исходного файла `main.c' и заголовочного файла `defs.h'.

За каждой строкой, содержащей цель и пререквизиты, следует строка с командой. Эти команды указывают, каким образом надо обновлять целевой файл. В начале каждой строки, содержащей команду, должен находится символ табуляции. Именно наличие символа табуляции является признаком, по которому make отличает строки с командами от прочих строк make-файла. Имейте ввиду, что make не имеет ни малейшего представления о том, как работают эти команды. Поэтому, ответственность за то, что выполняемые команды нужным образом обновят целевой файл, целиком ложится на вас. Утилита make просто исполняет указанные в правиле команды если цель нуждается в обновлении.

Цель `clean' является не файлом, а именем действия. Поскольку, при обычной сборке программы это действие не требуется, цель `clean' не является пререквизитом какого-либо из правил. Следовательно, make не будет "трогать" это правило, пока вы специально об этом не попросите. Заметьте, что это правило не только не является пререквизитом, но и само не содержит каких-либо пререквизитов. Таким образом, единственное предназначение данного правила - выполнение указанных в нем команд. Цели, которые являются не файлами, а именами действий называются абстрактными целями (phony targets).

http://rus-linux.net/nlib.php?name=/MyLDP/algol/gnu_make/gnu_make_3-79_russian_manual.html - TOC8

Упрощение make-файла с помощью переменных

http://rus-linux.net/nlib.php?name=/MyLDP/algol/gnu_make/gnu_make_3-79_russian_manual.html - TOC8

В приведенном выше примере, в правиле для `edit' нам дважды пришлось перечислять список объектных файлов программы:

edit : main.o kbd.o command.o display.o \

insert.o search.o files.o utils.o

cc -o edit main.o kbd.o command.o display.o \

insert.o search.o files.o utils.o

Подобное дублирование чревато ошибками. При добавлении в проект нового объектного файла, можно добавить его в один список и забыть про другой. Мы можем устранить подобный риск, и, одновременно, упростить make-файл, используя переменные. Переменные (variables) позволяют, один раз определив текстовую строку, затем использовать ее многократно в нужных местах.

Обычной практикой при построении make-файлов является использование переменной с именем objects, OBJECTS, objs, OBJS, obj, или OBJ, которая содержит список всех объектных файлов программы. Мы могли бы определить подобную переменную с именем objects таким образом:

objects = main.o kbd.o command.o display.o \

insert.o search.o files.o utils.o

Далее, всякий раз, когда нам нужен будет список объектных файлов, мы можем использовать значение этой переменной с помощью записи `$(objects)' .

Вот как будет выглядеть наш простой пример с использованием переменной для хранения списка объектных файлов:

objects = main.o

edit : $(objects)

cc -o edit $(objects)

main.o : main.c

cc -c main.c

clean :

rm edit $(objects)

http://rus-linux.net/nlib.php?name=/MyLDP/algol/gnu_make/gnu_make_3-79_russian_manual.html - TOC9

Неявные правила упрощают make-файл

http://rus-linux.net/nlib.php?name=/MyLDP/algol/gnu_make/gnu_make_3-79_russian_manual.html - TOC9

На самом деле, нет необходимости явного указания команд компиляции отдельно для каждого из исходных файлов. Утилита make сама может "догадаться" об использовании нужных команд, поскольку у нее имеется, так называемое, неявное правило (implicit rule) для обновления файлов с расширением `.o' из файлов с расширеним `.c', с помощью команды `cc -c'. Например, она бы использовала команду `cc -c main.c -o main.o' для преобразования файла `main.c' в файл `main.o'. Таким образом, можно убрать явное указание команд компиляции из правил, описывающих построение объектных файлов.

Когда файл с расширением `.c' автоматически используется подобным образом, он также автоматически добавляется в список пререквизитов "своего" объектного файла. Таким образом, мы вполне можем убрать файлы с расширением `.c' из списков пререквизитов объектных файлов.

Вот новый вариант нашего примера, в который были внесены оба описанных выше изменения, а также используется переменная objects:

objects = main.o kbd.o command.o display.o \

insert.o search.o files.o utils.o

edit : $(objects)

cc -o edit $(objects)

main.o : defs.h

kbd.o : defs.h command.h

command.o : defs.h command.h

display.o : defs.h buffer.h

insert.o : defs.h buffer.h

search.o : defs.h buffer.h

files.o : defs.h buffer.h command.h

utils.o : defs.h

.PHONY : clean

clean :

-rm edit $(objects)

Примерно так и выглядят make-файлы в реальной практике. /3/

2.Встраиваемые системы на базе Linux

2.1 Buildroot

Buildroot это набор файлов сборки и корректировок, которые позволяют просто сгенерировать под разные платформы, полный набор инструментальных средств и корневую файловую систему Вашей целевой Linux системы. Инструментарий кросс-компиляции использует uClibc, небольшую стандартную C библиотеку.

Buildroot, в основном, используется людьми, работающими с маленькими или встроенными системами. Встроенные системы часто предназначаются не для распространенных x86 процессоров. Это могут быть PowerPC процессоры, MIPS процессоры, ARM процессоры и так далее.

Инструментарий компиляции это набор инструментов, которые позволяют скомпилировать код для системы. Этот инструментарий состоит из компилятора (в нашем случае, gcc), бинарных утилит, таких как ассемблер и компоновщик и стандартной C библиотеки. В системе, установленной на станцию разработки, конечно уже есть инструментарий компиляции такой, что можете компилировать приложение, которое выполняется на системе. Если использовать PC платформу, инструментарий компиляции выполняется на некотором x86 процессоре и генерирует код для x86 процессора. Под большинством Linux систем, инструментарий компиляции использует GNU libc, как стандартную C библиотеку. Этот инструментарий компиляции называется "host compilation toolchain" (главный инструментарий компиляции), и в более общем случае, система, на которой он выполняется, называется "host (главная) система". инструментарий компиляции предоставляется посредством дистрибутива, который Вы используете, и Buildroot ничего не может в нем нарушить.

Как было сказано выше, инструментарий компиляции, который поставляется с системой, выполняется и генерирует код для процессора Вашей host (главной) системы. Так как встроенная система, может иметь другой процессор, необходим инструментарий кросс-компиляции: это инструментарий компиляции, который выполняется на Вашей host (главной) системе, но, который генерирует код для целевой системы (и целевого процессора). Например, если главная система использует x86, и целевая система использует ARM, обычный инструментарий компиляции главной системы выполняется на x86 и генерирует код для x86, в то время, как кросс-компиляции инструментарий выполняется на x86 и генерирует код для ARM.

Даже если встроенная система использует x86 процессор, может быть интересен Buildroot, по двум причинам:

· инструментарий компиляции Главной системы несомненно использует GNU Libc, которая является полной, но огромной стандартной C библиотекой. Взамен использования GNU Libc на target системе, можно использовать uClibc, которая является небольшой стандартной C библиотекой. Если использовать эту C библиотеку, будет необходим инструментарий компиляции для генерации бинарных кодов, скомпонованных с ней. Buildroot может сделать это.

· Buildroot автоматизирует построение root filesystem со всеми необходимыми инструментами, например, как busybox. Так гораздо легче, чем собирать все вручную.

Зачем такие инструменты необходимы, когда можно скомпилировать gcc, binutils, uClibc и все инструменты вручную. Конечно, сделать так возможно. Но иметь дело со всеми конфигурационными параметрами, со всеми проблемами каждой gcc или binutils версии это очень затратно по времени и неинтересно. Buildroot автоматизирует этот процесс посредством использования Makefiles (сборочных файлов), и имеет коллекцию исправлений для каждой gcc и binutils версии так, чтобы сборки могли работать на большинстве архитектур. /4/

2.2 OpenWrt

OpenWrt -- производная Buildroot, прошивка, основанная на Linux, для домашних маршрутизаторов (роутеров). Изначально поддержка ограничивалась серией Linksys WRT54G, но сейчас расширилась и включает в себя чипсеты других производителей, в том числе и x86. Наиболее популярными является серия Linksys WRT54G и Asus WL500G. OpenWrt в основном использует интерфейс командной строки, но одной из опций является веб-интерфейс. Техническая поддержка осуществляется с помощью форума и IRC канала.

Разработка OpenWrt стала возможной благодаря использованию производителем программного обеспечения лицензии GNU General Public License (GNU GPL), которая требует от разработчиков публиковать все производные продукты под той же лицензией.

Одна из трех самых популярных альтернативных прошивок для WiFi роутеров.

Главное в OpenWrt - это полная поддержка файловой системы JFFS2( структурированная файловая система, используемая в устройствах флеш-памяти), которая позволяет использовать для управления пакетами менеджер пакетов ipkg. Всё это делает OpenWrt легко настраиваемой и адаптируемой системой для каждого конкретного случая.

Базовая прошивка предоставляет небольшое количество функций, для расширения используются дополнительные пакеты. Отмечается неудобство веб-интерфейса (особенно для неопытных пользователей).

Вместо того, чтобы создать одну статическую прошивку, OpenWrt обеспечивает полную запись файловой системы с помощью управления пакетами. Это освобождает Вас от ограничения в выборе приложений и конфигураций, предоставленной продавцом и позволит использовать пакеты для изменения встроенных устройств, чтобы работать с любыми приложениями. Для разработчиков, OpenWrt обеспечивает основу для создания приложений без необходимости создания полного образа прошивки и распределения вокруг него. Для пользователей это означает, что это полная свобода настройки, позволяющая использовать встроенное устройство таким образом, что поставщики никогда не смогут предположить. /5/

Основные достоинства в пользовании OpenWrt :

1) Он Бесплатный и с открытым исходным кодом. Проект является полностью бесплатным, под лицензией GPL. Он намерено всегда будет размещен в легком доступе, с полным легкодоступным исходным кодом и легким в построении.

2) Простой и бесплатный доступ. Проект всегда будет открыт для новых участников. Любой должен иметь возможность внести свой вклад. Нынешние разработчики, активно предоставлять доступ на запись всем, кто интересуется имея ее.

3) Поддержка общества. Речь идет не о "нас", говорят - "вы", речь идет о всех кто соберется вместе, чтобы работать и сотрудничать для достижения общей цели. /6/

3. Описание структуры пакета Buildroot

· package/Makefile

· package/patches

Каталог patches не является обязательным и обычно содержит исправления ошибок или оптимизацию размера исполняемого файла. Makefile пакета является важной составляющей и описывает шаги необходимые чтобы получить исходный код и скомпилировать пакет.

Глядя на Makefile из какого либо пакета, вряд ли можно узнать в нем обычный Makefile. Это может быть охарактеризовано как вопиющее пренебрежение и жестокое обращение с традиционным форматом make, однако, преобразование Makefile пакета в объектно-ориентированный шаблон позволило упростить весь процесс портирования приложений.

Приведем пример package/bridge/Makefile

3.1 Переменные BuildPackage

Как можно заметить, необходимо сделать совсем не много. Все скрыто в других make-файлах и нужно только определить несколько переменных.

· PKG_NAME -Название пакета, которое будет видно в конфигурационном меню и ipkg

· PKG_VERSION -Версия пакета, которую необходимо загрузить из репозитория проекта

· PKG_RELEASE -Версия данного Makefile

· PKG_BUILD_DIR -Каталог для сборки пакета

· PKG_SOURCE -Названия архива с исходным кодом

· PKG_SOURCE_URL -Адрес, с которого необходимо загрузить архив с исходным кодом

· PKG_MD5SUM -Контрольная сумма архива с исходным кодом

· PKG_CAT -Метод разархивирования исходного кода (zcat, bzcat, unzip)

· PKG_BUILD_DEPENDS -Пакеты, которые необходимо собрать перед сборкой данного пакета (не используются во время работы на устройстве).

Переменные PKG_* определяют откуда загружать исходный код; @SF - это ключевое слово для загрузки исходников с sourceforge. Контрольная сумма md5sum используется для проверки корректности загрузки архива, а PKG_BUILD_DIR определяет где находится исходный код после разархивирования полученного архива в $(BUILD_DIR).

В конце файла происходит настоящее волшебство: функция "BuildPackage" настраивает процесс сборки пакета на основании ранее определенных переменных. BuildPackage принимает только один аргумент напрямую - имя пакета, который будет собран, в данном случае "bridge". Вся остальная информация берется из блоков define. Это способ позволяет обеспечить необходимый уровень читаемости кода, как следствие остается ясным значение переменной DESCRIPTION в Package/bridge, а не теряется как в случае, если бы мы передали эту информацию непосредственно в N-ый аргумент BuildPackage.

3.2 Блоки define BuildPackage

Package/

соответствует аргументу передоваемому в buildroot, описание пакета для menuconfig и ipkg. В блоке Package/ вы можете определить следующие переменные:

· SECTION - Тип пакета (в данный момент не используется)

· CATEGORY - В каком пункте menuconfig отображать данный пакет

· TITLE - Краткое описание пакета

· DESCRIPTION - (устарело) Полное описание пакета

· URL - Ссылка на сайт пакета

· MAINTAINER - (опционально) Кто поддерживает пакет

· DEPENDS - (опционально) Какие пакеты должны быть собраны и установлены перед текущим пакетом

Package/conffiles

Перечень конфигурационных файлов устанавливаемых данным пакетом, каждый файл на отдельной строке.

Package/description

Полное описание пакета

Build/Prepare

Перечень команд необходимых для разархивирования и наложения патчей на исходный код. Можно не определять.

Build/Configure

Можно не определять, если не используется configure или есть стандартный конфигурационный скрипт, иначе можно прописать необходимые команды или использовать "$(call Build/Configure/Default,)" чтобы передать дополнительные параметры стандартному конфигурационному скрипту.

Build/Compile

Перечень команд необходимых для компиляции исходного кода; в большинстве случаев не нужно определять.

Package/install

Перечень команд необходимых для копирования собранных файлов в ipkg, который представлен как директория $(1).

Package/preinst

Текст скрипта выполняемого перед установкой. Не забудьте написать #!/bin/sh. Если необхомо прервать установку, скрипт должен вернуть false.

Package/postinst

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

написать #!/bin/sh.

Package/prerm

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

написать #!/bin/sh. Если необхомо прервать удаление, скрипт должен вернуть false.

Package/postrm

Текст скрипта выполняемого после удаления. Не забудьте написать #!/bin/sh . /7/

4. Пример пакета Openwrt

В практической части я создал пробный пакет Openwrt. Он состоит из одной тестовой программы который выводит на консоль текст сообщение.

Есть простая программа на языке C, hello.c

#include <stdio.h>

int main(){

printf("Hello world from Utils/hello package \r\n");

return(0);

}

В которой есть текст Hello World

Далее я Написал пакет Makefile который использует сценарий для самой сборки исходников

CFLAGS?=-O2

CFLAGS+=

SFLAGS:=--std=gnu99

WFLAGS:=-Wall -Werror -pedantic

LDFLAGS?=

BINARY:=hello

all: $(BINARY)

$(BINARY): *.c

$(CC) -I. $(CFLAGS) $(SFLAGS) $(WFLAGS) $(LDFLAGS) -o $@ $+

clean:

rm -f $(BINARY)

А затем написал Шаблон сценария для сборки пакета Makefile

Заключение

Неотъемлемой частью научно-технического прогресса является автоматизация процессов как на производстве, так и в повседневной жизни. Физически она реализуется посредством микропроцессоров и микроконтроллеров. Для обеспечения направленной и корректной работы процессора и управления его ресурсами, он должен управляться операционной системой. Чаще всего в роли такой ОС выступает Linux. Она содержит в себе базовый пакет Buildroot, позволяющий создавать модификаций под определённое компьютерное железо Цели Работы: создание программы для автоматизации создания пакета Buildroot, изучение скрипов Shell и Make которые помогают автоматизировать создание пакетов и наглядная реализация программы.

Список использованных источников

1 Долятовский В.А., Долятовская В.Н. Исследование систем управления: Учеб.-практ. Пособие. - М.: ИКЦ «МарТ». 2009 год.

2 Маклаков С. В. Моделирование бизнес-процессов с AllFusion Process Modeler - М.: Диалог-МИФИ. 2014г. - 236 стр.

3 Матвеева, Л.Г. Управление проектами. - Ростов н/Дону: Феникс. 2009. - 422с.

4 Шепталин, Г.А. Основы информационного менеджмента: Учебное пособие. - Челябинск: Издательский центр ЮУрГУ. 2009. - 92 с.

Приложения

Приложение 1

Пример package/bridge/Makefile

include $(TOPDIR)/rules.mk

PKG_NAME:=bridge

PKG_VERSION:=1.0.6

PKG_RELEASE:=1

PKG_BUILD_DIR:=$(BUILD_DIR)/bridge-utils-$(PKG_VERSION)

PKG_SOURCE:=bridge-utils-$(PKG_VERSION).tar.gz

PKG_SOURCE_URL:=@SF/bridge

PKG_MD5SUM:=9b7dc52656f5cbec846a7ba3299f73bd

PKG_CAT:=zcat

include $(INCLUDE_DIR)/package.mk

define Package/bridge

SECTION:=base

CATEGORY:=Network

DEFAULT:=y

TITLE:=Ethernet bridging configuration utility

#DESCRIPTION:=This variable is obsolete. use the Package/name/description

define instead!

URL:=http://bridge.sourceforge.net/

endef

define Package/bridge/description

Ethernet bridging configuration utility

Manage ethernet bridging; a way to connect networks together to

form a larger network.

endef

define Build/Configure

$(call Build/Configure/Default,--with-linux-headers=$(LINUX_DIR))

endef

define Package/bridge/install

$(INSTALL_DIR) $(1)/usr/sbin

$(INSTALL_BIN) $(PKG_BUILD_DIR)/brctl/brctl $(1)/usr/sbin/

endef

$(eval $(call BuildPackage,bridge))

Приложение 2

Шаблон сценария makefile

include $(TOPDIR)/rules.mk

PKG_NAME:=hello

PKG_RELEASE:=1

PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)

include $(INCLUDE_DIR)/package.mk

define Package/hello

SECTION:=utils

CATEGORY:=Utilities

TITLE:=Test package

MAINTAINER:=Alex Z <mail@mail.ru>

endef

define Package/hello/description

hello package is a hello world program

endef

define Build/Prepare

mkdir -p $(PKG_BUILD_DIR)

$(CP) ./src/* $(PKG_BUILD_DIR)/

endef

define Package/hello/install

$(INSTALL_DIR) $(1)/usr/sbin

$(INSTALL_BIN) $(PKG_BUILD_DIR)/hello $(1)/usr/sbin/hello

endef

$(eval $(call BuildPackage,hello))

Размещено на Allbest.ru