Читаем Внутреннее устройство Linux полностью

Помните о том, что утилита GNU make обладает множеством таких расширений, встроенных правил и функций, каких нет у других вариантов. Это замечательно, пока вы работаете в Linux, но, если вы окажетесь за компьютером с Solaris или BSD и будете рассчитывать, что все станет работать так же, вас может поджидать сюрприз. Однако с этой проблемой можно разобраться, если применить такую многоплатформенную систему сборки, как GNU autotools.

15.2.7. Обычные цели

Большинство файлов Makefiles содержит некоторые стандартные цели, которые выполняют вспомогательные задачи, относящиеся к компиляции.

• clean. Цель clean является повсеместной; команда make clean обычно дает утилите make указание удалить все объектные и исполняемые файлы, чтобы можно было начать все заново или подготовить пакет ПО. Вот пример правила для файла Makefile программы myprog:

clean:

       rm -f $(OBJS) myprog

• distclean. В файле Makefile, созданном с помощью системы GNU autotools всегда есть цель distclean, чтобы удалить все, что не является частью исходного дистрибутива, включая и сам файл Makefile. Подробнее об этом вы узнаете из главы 16. В очень редких случаях вы обнаружите, что разработчик предпочитает удалять исполняемые файлы не с помощью этой цели, а чем-либо вроде цели realclean.

• install. Копирует файлы и скомпилированные программы в местоположение системы, которое файл Makefile считает надлежащим. Это может быть опасным, поэтому всегда сначала запустите команду make –n install, чтобы увидеть, что произойдет, не выполняя в действительности никаких команд.

• test или check. Некоторые разработчики предусматривают цели test или check, чтобы убедиться в том, что все работает после выполнения сборки.

• depend. Создает зависимости, вызывая компилятор с параметром -M для проверки исходного кода. Эта цель выглядит необычно, поскольку часто она изменяет сам файл Makefile. Это больше не является общепринятой практикой, но, если вам встретятся инструкции, в которых говорится об использовании этого правила, следуйте им.

• all. Часто является первой целью в файле Makefile. Вам много раз будут попадаться ссылки на эту цель, а не на исполняемый файл.

15.2.8. Устройство файла Makefile

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

MYPACKAGE_INCLUDES=-I/usr/local/include/mypackage

MYPACKAGE_LIB=-L/usr/local/lib/mypackage -lmypackage

PNG_INCLUDES=-I/usr/local/include

PNG_LIB=-L/usr/local/lib -lpng

Каждый тип флагов компилятора и компоновщика часто оформляется в виде таких макроопределений:

CFLAGS=$(CFLAGS) $(MYPACKAGE_INCLUDES) $(PNG_INCLUDES)

LDFLAGS=$(LDFLAGS) $(MYPACKAGE_LIB) $(PNG_LIB)

Объектные файлы обычно группируются в соответствии с исполняемыми файлами. Допустим, например, что у вас есть пакет, который создает исполняемые файлы boring и trite. У каждого из них есть файл .c с исходным кодом и необходимый код в файле util.c. Вы можете увидеть нечто вроде следующего:

UTIL_OBJS=util.o

BORING_OBJS=$(UTIL_OBJS) boring.o

TRITE_OBJS=$(UTIL_OBJS) trite.o

PROGS=boring trite

Остальная часть файла Makefile могла бы выглядеть так:

all: $(PROGS)

boring: $(BORING_OBJS)

        $(CC) -o $@ $(BORING_OBJS) $(LDFLAGS)

trite: $(TRITE_OBJS)

       $(CC) -o $@ $(TRITE_OBJS) $(LDFLAGS)

Вы могли бы скомбинировать две цели для исполняемых файлов в виде одного правила, но обычно так поступать не следует, поскольку вам было бы непросто перенести правило в другой файл Makefile и удалить исполняемый файл или группу исполняемых файлов в отдельности. Более того, зависимости стали бы некорректными: если бы у вас было лишь одно правило для файлов boring и trite, файл trite зависел бы от файла boring.c, файл boring — от файла trite.c, и утилита make всегда пыталась бы собрать заново обе программы, если вы изменили один из файлов с исходным кодом.

примечание

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

15.3. Отладчики

Стандартным отладчиком в системах Linux является gdb; доступны также системы с дружественным к пользователю интерфейсом, например Eclipse IDE и Emacs. Чтобы включить полную отладку ваших программ, запустите компилятор с параметром -g для записи таблицы имен и другой отладочной информации в исполня­емый файл. Чтобы запустить отладчик gdb для исполняемого файла program, выполните такую команду:

$ gdb program

Вы должны получить приглашение (gdb). Чтобы запустить программу program с параметром командной строки options, введите следующую команду после приглашения отладчика:

(gdb) run options