Пример package/bridge/Makefile

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

	Руководитель __________доц.Моховиков А.Ю. Студент гр. 01321-Д ________________Лысекно А.В. Работа защищена с оценкой______________ «_____» ______________ 2013 г. Протокол №________________ Нормоконтролер ________________Конецкая Е.В.

Иркутск 2013

Реферат

В данной работе рассмотрены методы упрощения создания пакетов Buildroot такие как скрипты Shell и Make.

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

Также приведен пример пакета Openwrt.

Работа содержит : 26 страниц текста, 2 приложения, список источников из 7 наименований

Содержание

Введение....................................................................................................................................... 4

1.Базовые инструменты Linux Shell и Make........................................................................ 5

1.1 Скриптовый язык Shell........................................................................................................ 5

1.2 Утилита Make........................................................................................................................ 5

Make — утилита, автоматизирующая процесс преобразования файлов из одной формы в другую. Чаще всего это компиляция исходного кода в объектные файлы и последующая компоновка в исполняемые файлы или библиотеки /2/..................................................... 5

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

2.1 Buildroot............................................................................................................................... 12

2.2 OpenWrt............................................................................................................................... 13

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

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

3.2Блоки define BuildPackage................................................................................................ 15

Заключение................................................................................................................................ 19

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

Приложение 1 24

Приложение 2. 26

Введение

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

1. Базовые инструменты Linux Shell и Make

1.1 Скриптовый язык Shell

Shell -- это командная оболочка. Но это не просто промежуточное звено между пользователем и операционной системой, это еще и мощный язык программирования. Программы на языке shell называют сценариями, или скриптами. Фактически, из скриптов доступен полный набор команд, утилит и программ UNIX. Если этого недостаточно, то к вашим услугам внутренние команды shell -- условные операторы, операторы циклов и пр., которые увеличивают мощь и гибкость сценариев. Shell-скрипты исключительно хороши при программировании задач администрирования системы и др., которые не требуют для своего создания полновесных языков программирования.

Знание языка командной оболочки является залогом успешного решения задач администрирования системы. Даже если вы не предполагаете заниматься написанием своих сценариев. Во время загрузки Linux выполняется целый ряд сценариев из /etc/rc.d, которые настраивают конфигурацию операционной системы и запускают различные сервисы, поэтому очень важно четко понимать эти скрипты и иметь достаточно знаний, чтобы вносить в них какие либо изменения.

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

Shell-скрипты очень хорошо подходят для быстрого создания прототипов сложных приложений, даже не смотря на ограниченный набор языковых конструкций и определенную "медлительность". Такая метода позволяет детально проработать структуру будущего приложения, обнаружить возможные "ловушки" и лишь затем приступить к кодированию на C, C++, Java, или Perl.

Скрипты возвращают нас к классической философии UNIX -- "разделяй и влавствуй" т.е. разделение сложного проекта на ряд простых подзадач. Многие считают такой подход наилучшим или, по меньшей мере, наиболее эстетичным способом решения возникающих проблем, нежели использование нового поколения языков -- "все-в-одном", таких как Perl.

Если выполняется хотя бы одно из вышеперечисленных условий, то вам лучше обратиться к более мощным скриптовым языкам программирования, например Perl, Tcl, Python, Ruby или к высокоуровневым компилирующим языкам -- C, C++ или Java. Но даже в этом случае, создание прототипа приложения на языке shell может существенно облегчить разработку.

Название BASH -- это аббревиатура от "Bourne-Again Shell" и игра слов от, ставшего уже классикой, "Bourne Shell" Стефена Бурна (Stephen Bourne). В последние годы BASH достиг такой популярности, что стал стандартной командной оболочкой de facto для многих разновидностей UNIX. Большинство принципов программирования на BASH одинаково хорошо применимы и в других командных оболочках, таких как Korn Shell (ksh), от которой Bash позаимствовал некоторые особенности, и C Shell и его производных. /1/

1.2 Утилита Make

Программа make выполняет команды согласно правилам, указанным в специальном файле. Этот файл называется make-файл (makefile, мейкфайл). Как правило, make-файл описывает, каким образом нужно компилировать и компоновать программу.

make-файл состоит из правил и переменных. Правила имеют следующий синтаксис:

цель1 цель2 ...: реквизит1 реквизит2 ...

команда1

команда2

...

Правило представляет собой набор команд, выполнение которых приведёт к сборке файлов-целей из файлов-реквизита.

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

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

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

Рассмотрим несложную программу на Си. Пусть программа program состоит из пары файлов кода — main.c и lib.c, а также из одного заголовочного файла — defines.h, который подключён в оба файла кода. Поэтому, для создания program необходимо из пар (main.c defines.h) и (lib.c defines.h) создать объектные файлы main.o и lib.o, а затем скомпоновать их в program. При сборке вручную требуется дать следующие команды:

cc -c main.c

cc -c lib.c

cc -o program main.o lib.o

Если в процессе разработки программы в файл defines.h будут внесены изменения, потребуется перекомпиляция обоих файлов и линковка, а если изменим lib.c, то повторную компиляцию main.о можно не выполнять.

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

· собирает из этой информации правильную последовательность команд для получения требуемых результирующих файлов;

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

Если при запуске make явно не указать цель, то будет обрабатываться первая цель в make-файле, имя которой не начинается с символа «.».

Для программы program достаточно написать следующий make-файл:

program: main.o lib.o

cc -o program main.o lib.o

main.o lib.o: defines.h

Стоит отметить ряд особенностей. В имени второй цели указаны два файла и для этой же цели не указана команда компиляции. Кроме того, нигде явно не указана зависимость объектных файлов от «*.c»-файлов. Дело в том, что программа make имеет предопределённые правила для получения файлов с определёнными расширениями. Так, для цели-объектного файла (расширение «.o») при обнаружении соответствующего файла с расширением «.c» будет вызван компилятор «сс -с» с указанием в параметрах этого «.c»-файла и всех файлов-зависимостей.

Синтаксис для определения переменных:

переменная = значение

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

OBJ = main.o lib.o

program: $(OBJ)

cc -o program $(OBJ)

$(OBJ): defines.h

Нужно отметить, что вычисление значение переменных происходит только в момент использования (используется так называемое ленивое вычисление). Например, при сборке цели all из следующего make-файла на экран будет выведена строка «Huh?».

foo = $(bar)

bar = $(ugh)

ugh = Huh?

all:

echo $(foo)

Предположим, что к проекту добавился второй заголовочный файл lib.h, который включается только в lib.c. Тогда make-файл увеличится ещё на одну строчку:

lib.o: lib.h

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

Как выглядят правила (rules)

Простой make-файл состоит из "правил" (rules) следующего вида:

цель ... : пререквизит ...

команда

...

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

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

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

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

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

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

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

Вот пример простого 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).

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

В приведенном выше примере, в правиле для `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)

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

На самом деле, нет необходимости явного указания команд компиляции отдельно для каждого из исходных файлов. Утилита 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

Одну из целей, которую можно достичь с помощью системы шаблонов OpenWrt, было желание сделать процесс портирования программного обеспечения под OpenWrt максимально простым. Посмотрите на обычный каталог пакета в OpenWrt можно найти две составляющие:

· package/Makefile

· package/patches

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

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

Приведем пример package/bridge/Makefile: (См. Приложение 1)

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/

Пример пакета 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 (Приложение 2 )

Заключение

Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела. Текст раздела.

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

1. Opennet: сайт. – URL: http://www.opennet.ru/docs/RUS/bash_scripting_guide/c118.html (дата обращения: 25.04.2013).

2. Make Материал из Википедии свободной энциклопедии : сайт. – URL: http://ru.wikipedia.org/wiki/Make(дата обращения: 3.05.2013).

3. Linux Виртуальная библиотека по-русски : сайт. – URL: http://rus-linux.net/nlib.php?name=/MyLDP/algol/gnu_make/gnu_make_3-79_russian_manual.html#SEC5(дата обращения: 3.05.2013).

4. Buildroot : сайт. – URL: http://ard01.nichost.ru/files/news/01072005/buildroot-rus_utf8.html#add_software (дата обращения: 10.05.2013).

5. OpenWrt Материал из Википедии свободной энциклопедии : сайт. – URL: http://ru.wikipedia.org/wiki/OpenWrt (дата обращения: 12.04.2013).

6. OpenWrt Wiki на русском языке: сайт. – URL: http://wiki.openwrt.org/about/start (дата обращения: 12.04.2013).

7. OpenWrt Wiki на русском языке: сайт. – URL: http://wiki.openwrt.org/ru/doc/devel/packages

Приложение 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