Разработка приложений в среде Linux. Второе издание

4.2. make

Основой программирования под Unix является make — средство, которое существенно упрощает описание компиляции программ. Даже притом, что небольшим программам порой достаточно одной команды для компиляции их исходного кода в исполняемый файл, все же намного легче написать make, чем строку вроде gcc -02 -ggdb -DSOME DEFINE -о foo foo.c. Более того, если имеется множество файлов для компиляции, а код был изменен лишь в некоторых из них, make создаст новые объектные файлы только для тех файлов, на которые повлияли изменения. Чтобы make совершила это "чудо", потребуется описать все файлы в make-файле (Makefile), пример которого показан ниже.

 1: # Makefile

 2:

 3: OBJS = foo.о bar.о baz.o

 4: LDLIBS = -L/usr/local/lib/ -lbar

 5:

 6: foo: $(OBJS)

 7:       gcc -o foo $ (OBJS) $ (LDLIBS)

 8:

 9: instalname = "note" foo

10:       install -m 644 foo /usr/bin

11: .PHONY: install

• Строка 1 — это комментарий; make следует обычной традиции Unix определения комментариев с помощью символа #.

• В строке 3 определяется переменная по имени OBJS как foo.о bar.о baz.о.

• В строке 4 определяется другая переменная — LDLIBS.

• В строке 6 начинается определение правила, которое указывает на то, что файл foo зависит от (в этом случае, собран из) файлов, имена которых содержатся в переменной OBJS. foo называется целевым объектом, а $(OBJS) — списком зависимостей. Обратите внимание на синтаксис расширения переменной: имя переменной помещается в $(...).

Строка 7 — это командная строка, указывающая на то, как построить целевой объект из списка зависимостей. Командных строк может быть много, и первым символом в командной строке должна быть табуляция.

• Строка 9 — довольно интересный целевой объект. Фактически тут не предпринимается попытка создать файл по имени install; вместо этого (как видно в строке 10) foo инсталлируется в /usr/bin с помощью стандартной программы install. Эта строка вызывает неоднозначность в make: что, если файл install уже существует и является более новым, нежели foo? В этом случае запуск команды make install приведет к выдаче сообщения 'install' is up to date (install является новее) и завершению работы.

• Строка 11 указывает make на то, что install не является файлом, и что необходимо игнорировать любой файл по имени install при вычислении зависимости install. Таким образом, если зависимость install была вызвана (как это сделать мы рассмотрим далее), команда в строке 10 всегда будет выполняться. .PHONY — это директива, которая изменяет операцию make; в этом случае она указывает make на то, что целевой объект install не является именем файла. Целевые объекты .PHONY часто используются для совершения действий вроде инсталляции или создания одиночного имени целевого объекта, которое основывается на нескольких других уже существующих целевых объектов, например:

alname = "note" foo bar baz

.PHONY: all

К сожалению, .PHONY не поддерживается некоторыми версиями make. Менее очевидный, не такой эффективный, но более переносимый способ для этого показан ниже.

alname = "note" foo bar baz FORCE

FORCE:

Это срабатывает только тогда, когда нет файла по имени FORCE.

Элементы в списках зависимостей могут быть именами файлов, но, поскольку это касается make, они являются целевыми объектами. Элемент foo в списке зависимости install — это целевой объект. При попытке make вычислить зависимость install становится ясно, что в первую очередь необходимо вычислить зависимость foo. А для этого make потребуется вычислить зависимости foo.о, bar.о и baz.о.

Обратите внимание на отсутствие строк, явно указывающих make, как строить foo.о, bar.о или baz.о. Вы не будете определять эти строки непосредственно в редакторе. make обеспечивает предполагаемые зависимости, которые записывать не нужно. Если в файле есть зависимость, заканчивающаяся на .о, и есть файл с таким же именем, но он заканчивается на .с, make предполагает, что этот объектный файл зависит от исходного файла. Встроенные суффиксные правила, которые поддерживаются make, позволяют значительно упростить многие make-файлы и, если встроенное правило не соответствует требованиям, можно создать свои собственные суффиксные правила (речь об этом пойдет ниже).

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

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

Если известно, что какая-то одна команда будет всегда возвращать ошибку, но вы хотите проигнорировать ее, можно воспользоваться "магией" командной оболочки. Команда /bin/false всегда возвращает ошибку, таким образом, /bin/false всегда будет вызывать прекращение работы, если только не указана опция -k. С другой стороны, конструкция любая_команда || /bin/true никогда не вызовет прекращение работы; даже если любая_команда возвращает false, оболочка затем запускает /bin/true, которая вернет успешный код завершения.

make интерпретирует нераспознанные аргументы командной строки, которые не начинаются с минуса (-), как целевые объекты для сборки. Таким образом, make install приводит к сборке целевого объекта install. Если целевой объект foo устарел, make сначала соберет зависимости foo, а затем инсталлирует его. Если требуется собрать целевой объект, начинающийся со знака минус, этот знак перед именем целевого объекта должен быть продублирован (--).

4.2.1 Сложные командные строки

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

 1: cd первый_ каталог; \

 2:  сделать что-то с файлом $ (FOO) ; \

 3:  сделать еще что-то

 4: cd второй_каталог; \

 5:  if [ -f некоторый_файл ] ; then\

 6:   сделать что-то другое; \

 7:  done; \

 8:  for i in * ; do \

 9:   echo $$i >> некоторый__файл ; \

10:  done

make находит в этом фрагменте кода только две строки. Первая командная строка начинается в строке 1 и продолжается до строки 3, а вторая начинается в строке 4 и заканчивается в строке 10. Здесь следует отметить несколько моментов.

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

• Строки, образующие каждую командную строку, передаются оболочке в виде одной строки. Таким образом, все символы ;, которые нужны оболочке, должны присутствовать, включая даже те, которые обычно в сценариях оболочки опускаются, поскольку их наличие подразумевается благодаря символам новой строки. Более детально о программировании программной оболочки рассказывается в [22].

• Если требуется разыменовывать переменную make, это делается обычным образом (то есть $(переменная)), но если нужно разыменовывать переменную оболочки, необходимо применять двойной символ $: $$i.

4.2.2. Переменные

Часто бывает необходимо определить только один компонент переменной за раз. Можно написать, например, такой код:

OBJS = foo.о

OBJS = $(OBJS) bar.о

OBJS = $(OBJS) baz.о

Ожидается, что здесь OBJS будет определен как foo.о bar.о baz.о, но в действительности он определен как $(OBJS) baz.о, поскольку make не разворачивает переменные до момента их использования[4]. При ссылке в правиле на OBJS make войдет в бесконечный цикл[5]. Во избежание этого во многих make-файлах разделы организуются следующим образом:

OBJS1 = foo.о

OBJS2 = bar.о

OBJS3 = baz.о

OBJS = $(OBJS1) $(OBJS2) $(OBJS3)

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

Развертывание переменной вызывает типичный вопрос, который программист в Linux должен решить. Инструменты GNU, распространяемые с Linux, обычно более функциональны, чем версии инструментов, включенных в другие системы, и GNU make — не исключение. Авторы GNU make предусмотрели альтернативный способ присваивания переменных, но не все версии make понимают эти альтернативные формы. К счастью, GNU make можно собрать для любой системы, в которую можно перенести исходный код, написанных под Linux. Существует форма простого присваивания переменных, которая показана ниже.

OBJS := foo.о

OBJS := $(OBJS) bar.о

OBJS := $(OBJS) baz.о

Операция := заставляет GNU make вычислить выражение переменной при присваивании, а не ждать вычисления выражения при его использовании в правиле. В результате выполнения этого кода OBJS действительно получит foo.о bar.о baz.о.

Простое присваивание переменной используется очень часто, но в GNU make есть еще и другой синтаксис присваивания, который позаимствован из языка С:

OBJS := foo.о

OBJS += bar.о

OBJS += baz.о

4.2.3. Суффиксные правила

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

.c.o:

$(CC) -с $ (CFLAGS) $ (CPPFLAGS) -о $<

.SUFFIXES: .с .о

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

Это суффиксное правило демонстрирует другую возможность make — автоматические переменные. Понятно, что нужно найти способ подставить зависимость и целевой объект в командную строку. Автоматическая переменная $@ выступает в качестве целевого объекта, $< выступает в качестве первой зависимости, а $^ представляет все зависимости.

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

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

Шаблонные правила более мощные и, следовательно, немного сложнее, чем суффиксные правила. Ниже приведен пример эквивалентного шаблонного правила для показанного выше суффиксного правила.

% .о: % .с

$(CC) -с $(CFLAGS) $(CPPFLAGS) -о $<

Дополнительные сведения о make можно получить в [26]. GNU make также включает замечательное и удобное в обращении руководство в формате Texinfo, которое можно почитать на сайте FSF, распечатать или заказать у них в форме книги.

Большинство крупных проектов с открытым исходным кодом используют инструменты Automake, Autoconf и Libtool. Эти инструменты представляют собой коллекцию знаний об особенностях различных систем и стандартах сообщества, которая может помочь в построении проектов. Таким образом, потребуется писать лишь немного кода, специфического для проекта. Например, Automake пишет целевые объекты install и uninstall, Autoconf автоматически определяет возможности системы и настраивает программное обеспечение для его соответствия системе, a Libtool отслеживает различия в управлении совместно используемыми библиотеками на разных системах.

По этим трем инструментам написана целая книга — [41]; здесь мы даем лишь основу, которая понадобится для работы с GNU Autoconf, Automake и Libtool.

4.3. Отладчик GNU

gdb — это отладчик, рекомендуемый Free Software Foundation, gdb представляет собой хороший отладчик командной строки, на котором строятся некоторые инструменты, включая режим gdb в Emacs, графический отладчик Data Display Debugger (http://www.gnu.org/software/ddd/) и встроенные отладчики в некоторых графических интерфейсах IDE. В этом разделе рассматривается только gdb.

Запустите gdb с помощью команды gdb имя_программы. gdb не будет просматривать значение PATH в поисках исполняемого файла. Отладчик загрузит символьную информацию для исполняемого файла и запросит дальнейших действий.

Существует три способа проверить процесс с помощью gdb.

• Используя команду run для обычного выполнения программы.

• Используя команду attach для начала проверки уже запущенного процесса. При подключении к процессу, последний останавливается.

• Исследуя существующий файл ядра для определения состояния процесса при его завершении. Для исследования файла ядра gdb потребуется запустить с помощью команды имя_программы файл_ядра.

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

gdb не требует написания полного имени команды; указание r достаточно для run, n — для next, s — для step. Более того, для повторения наиболее часто употребляемой команды, нужно просто нажать клавишу <Enter>. Таким образом, пошаговое выполнение программы становится проще.

Ниже предложен небольшой набор полезных команд gdb; gdb включает полное онлайновое руководство в формате GNU info (запустите info gdb), в котором детально объясняются все опции gdb. В [19] содержится неплохое подробное руководство по работе с gdb. gdb также поддерживает оперативную справку, ссылки на которую можно найти внутри gdb; доступ к справочным файлам можно получить, введя команду help. Можно также получить справку по каждой определенной команде, набрав help команда или help тема.

Подобно командам оболочки, команды gdb могут принимать аргументы. "Вызвать help с аргументом команда" означает то же самое, что и "набрать help команда".

Некоторые команды gdb также принимают идентификаторы формата для спецификации вывода значений. Идентификаторы формата располагаются за именем команды и отделяются от него косой чертой. После выбора формата необходимость использовать его каждый раз при повторе команды отпадает; gdb запоминает выбранный формат и использует его по умолчанию.

Идентификаторы формата отделены от команд символом / и состоят из трех элементов: цифра, буква формата и буква, отражающая размер. Цифра и буква размера не обязательны; по умолчанию в качестве цифры устанавливается 1, а размер получает подходящее значение по умолчанию, основанное на букве формата.

Буквы формата следующие: о для обозначения восьмеричного числа, x для шестнадцатеричного числа, d для десятичного числа, и для беззнакового десятичного числа, t для двоичных данных, f для числа с плавающей запятой, а для адреса, i для инструкций, с для символа, s для строки.

Символы, отображающие размер, таковы: b — байт, h — полуслово (2 байта), w — слово (4 байта), g — слово-гигант (8 байт).

attach, at

Подключает отладчик к уже запущенному процессу. Единственным аргументом является идентификатор процесса (pid), к которому осуществляется подключение. Процессы, с которыми установлено подключение, останавливаются, прерывая любые ожидающие или текущие системные вызовы, которые разрешено прерывать. См. detach.