Внутреннее устройство Linux - Уорд Брайан - Страница 106

«Цепные реакции» такого типа весьма характерны.

15.2.5. Аргументы и параметры командной строки

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

Один из самых полезных параметров позволяет указать единичную цель в командной строке. Для предыдущего файла Makefile можно запустить команду make aux.o, если вам необходим только файл aux.o.

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

$ make CC=clang

Здесь утилита make использует ваше определение переменной CC вместо соб­ственного компилятора по умолчанию cc. Макроопределения из командной строки становятся полезны при тестировании определений и библиотек препроцессора, в особенности с макроопределениями CFLAGS и LDFLAGS, о которых мы вкратце поговорим.

На самом деле вам даже не требуется файл Makefile для запуска утилиты make. Если встроенные в утилиту правила соответствуют цели, можно просто попросить утилиту создать цель. Например, если у вас есть исходный код для очень простой программы blah.c, попробуйте запустить команду make blah. Работа утилиты будет выглядеть так:

$ make blah

cc   blah.o -o blah

Подобный вариант использования утилиты подходит только для очень простых программ. Если же вашей программе необходимы библиотека или специальный каталог для включаемых файлов, то, вероятно, потребуется написать файл Makefile. Запуск утилиты без файла Makefile в действительности наиболее полезен в том случае, когда вы имеете дело с чем-либо вроде языка Fortran, Lex или Yacc и не знаете, как работает компилятор или утилита. Почему бы не дать возможность утилите make выяснить это за вас? Даже если ей не удастся создать цель, она, вероятно, снабдит вас очень хорошей подсказкой о том, как применять данный инструмент.

Среди ряда параметров утилиты make особо выделяются следующие:

• -n — выводит список команд, которые необходимы для сборки, но удерживает утилиту make от запуска каких-либо команд;

• -f file — дает утилите make указание на чтение из файла file вместо файлов Makefile или makefile.

15.2.6. Стандартные макроопределения и переменные

У команды make есть много специальных макроопределений и переменных. Сложно уловить различия между макроопределением и переменной, поэтому мы будем использовать термин «макроопределение» для обозначения чего-либо, что обычно не изменяется, когда утилита приступает к сборке целей.

Как вы видели ранее, можно назначить макроопределения в начале файла Makefile. Вот самые распространенные из них.

• CFLAGS. Параметры компилятора C. При создании объектного кода из файла .c утилита make передает этот параметр компилятору в качестве аргумента.

• LDFLAGS. Подобны параметрам CFLAGS, но они предназначены для компоновщика при создании исполняемого файла из объектного кода.

• LDLIBS. Если вы используете параметры LDFLAGS, но не желаете комбинировать параметры имени библиотеки с путем поиска, поместите параметры имени библиотеки в этот файл.

• CC. Компилятор C. По умолчанию это команда cc.

• CPPFLAGS. Параметры препроцессора C. Когда утилита make каким-либо образом запускает препроцессор, она передает ему в качестве аргумента это макроопределение.

• CXXFLAGS. Утилита GNU make использует эти параметры в качестве флагов для компилятора C++.

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

• $@ — внутри правила эта переменная развертывается в имя текущей цели;

• $* — развертывается в базовое имя текущей цели. Например, если вы собираете файл blah.o, эта переменная будет развернута в blah.

Наиболее полный перечень переменных Linux можно найти в info-руководстве к утилите make.

примечание

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