Основы программирования в Linux
вернуться

Мэтью Нейл
Шрифт:

$ rm -f myapp *.o mylib.a

$ make -f Makefile5

gcc -g -Wall -ansi -с -o main.о main.c

gcc -g -Wall -ansi -с -o 2.о 2.c

ar rv mylib.a 2.o

a - 2.o

gcc -g -Wall -ansi -с -о 3.o 3.c

ar rv mylib.a 3.o

a - 3.о

gcc -o myapp main.о mylib.a

$ touch c.h

$ make -f Makefile5

gcc -g -Wall -ansi -с -о 3.o 3.c

ar rv mylib.a 3.o

r - 3.о

gcc -o myapp main.о mylib.a

$

Как это работает

Сначала вы удаляете все объектные файлы и библиотеку и разрешаете команде

make
создать файл myapp, что она и делает, откомпилировав и создав библиотеку перед тем, как компоновать файл main.о с библиотекой для создания исполняемого файла myapp. Далее вы тестируете зависимость для файла 3.o, которая информирует команду
make
о том, что, если меняется файл c.h, файл 3.c следует заново откомпилировать. Она делает это корректно, откомпилировав файл и обновив библиотеку перед перекомпоновкой, создающей новую версию исполняемого файла myapp.

Более сложная тема: make-файлы и подкаталоги

При работе над большими проектами порой бывает удобно отделить от основных файлов файлы, формирующие библиотеку, и поместить их в подкаталог. С помощью команды

make
можно сделать это двумя способами.

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

mylib.a:

 (cd mylibdirectory;$(MAKE))

Это правило гласит, что вы всегда должны пытаться создать mylib.a с помощью команды

make
. Когда
make
инициирует правило создания библиотеки, она изменяет каталог на mylibdirectory и затем запускает новую команду
make
для управления библиотекой. Поскольку для этого запускается новая командная оболочка, программа, применяющая make-файл, не выполняет команду
cd
. А командная оболочка, запущенная для выполнения правила построения библиотеки, находится в другом каталоге. Скобки обеспечивают выполнение всего процесса в одной командной оболочке.

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

D
для каталога или символа
F
для имени файла к тем макросам, которые мы уже обсуждали. Вы можете переписать встроенное правило с суффиксами .с.о

.c.o:

 $(СС) $(CFLAGS) -с $(@D)/$(<F) -о $(@D)/$(@F)

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

mylib.a: mydir/2.o mydir/3.о

 ar -rv mylib.a $?

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

make
можно использовать с подкаталогами и сложность возрастает при этом лишь незначительно.

Версия GNU команд make и gcc

Для GNU-команды

make
и GNU-компилятора
gcc
существуют две интересные дополнительные опции.

 Первая — опция

– jN
("jobs") команды
make
. Она позволяет
make
выполнять
N
команд одновременно. Там, где несколько разных частей проекта могут компилироваться независимо, команда
make
запускает несколько правил в одно и то же время. В зависимости от конфигурации вашей системы эта возможность может существенно сократить время, затраченное на перекомпиляцию. Если у вас много исходных файлов, может быть стоит воспользоваться этой опцией. Как правило, небольшие числа, например
– j3
, — хорошая отправная точка. Если вы делите компьютер с другими пользователями, применяйте эту опцию с осторожностью. Другие пользователи могут не одобрить запуск большого количества процессов при каждой вашей компиляции!

Второе полезное дополнение — опция

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