1.15. Сборка простого приложения «Hello, World» с помощью GNU make
1.15. Сборка простого приложения «Hello, World» с помощью GNU make
Проблема
Вы хотите с помощью GNU make собрать простую программу «Hello, World», подобную приведенной в примере 1.4.
Решение
Прежде чем вы напишете свой первый make-файл, вы должны познакомиться с терминологией, make-файл состоит из набора правил, имеющих вид
цели: пререквизиты
команда-сценарий
Здесь цели и пререквизиты — это строки, разделенные пробелами, а команда-сценарий состоит из нуля или более строк текста, каждая из которых начинается с символа табуляции (Tab). Цели и пререквизиты обычно являются именами файлов, но иногда они представляют собой просто формальные имена действий, выполняемых make. Командный сценарий состоит из последовательности команд, передаваемых в оболочку. Грубо говоря, правило говорит make сгенерировать набор целей из набора пререквизитов, выполнив для этого командный сценарий.
Пробелы в make-файлах значимы. Строки, содержащие командные сценарии, должны начинаться с Tab, а не с пробелов — это источник некоторых наиболее распространенных ошибок новичков. В следующих примерах строки, которые начинаются с Tab, указаны с помощью отступа на четыре символа.
Теперь вы готовы начать. В директории, содержащей исходные файлы, создайте текстовый файл с именем makefile. В этом файле объявите четыре цели. Первую цель назовите all и в качестве ее пререквизита укажите имя собираемого исполняемого файла. Она не должна содержать командного сценария. Второй цели присвойте имя исполняемого файла. В качестве ее пререквизитов укажите имена исходных файлов, а в качестве командного сценария укажите команды, которые требуется выполнить для сборки исполняемого файла из исходных файлов. Третья цель должна называться install. У нее не должно быть пререквизитов и должен быть командный сценарий, копирующий исполняемый файл из директории, содержащей make-файл, в директорию, где он должен быть установлен. Последняя цель должна называться clean. Как и install, она не должна иметь пререквизитов. Ее командный сценарий должен удалять из текущей директории исполняемый файл и промежуточные объектные файлы. Цели clean и install должны быть помечены как phony targets (фиктивные цели), для чего используется атрибут PHONY.
Например, чтобы с помощью GCC собрать исполняемый файл из исходного кода из примера 1.4, make-файл может иметь вид, показанный в примере 1.14.
Пример 1.14. make-файл для сборки исполняемого файла с помощью GCC
# Это цель по умолчанию, которая будет собрана при
# вызове make
.PHONY: all
all: hello
# Это правило говорит make, как собрать hello из hello.cpp
hello: hello.cpp
g++ -o hello hello.cpp
# Это правило говорит make скопировать hello в поддиректорию binaries,
# создав ее, если требуется
.PHONY: install
install:
mkdir -p binaries
cp -p hello binaries
# Это правило говорит make удалить hello и hello.о
.PHONY: clean
clean:
rm -f hello
Чтобы собрать исполняемый файл из исходного кода из примера 1.4 с помощью Visual С++, используйте make-файл, показанный в примере 1.15.
Пример 1.15. make-файл для сборки исполняемого файла с помощью Visual С++.
#цель по умолчанию
.PHONY: all
all: hello.exe
#правило для сборки hello.exe
hello.exe: hello.cpp
cl -nologo -EHsc -GR -Zc:forScope -Zc:wchar_t
-Fehello hello.cpp
.PHONY: install
install:
mkdir -о binaries
cp -p hello.exe binaries
.PHONY: clean
clean:
rm -f hello.exe
Команды и списки целей или пререквизитов могут занимать несколько строк текста make-файла, для чего используется символ продолжения строки , как и в исходных файлах С++.
Чтобы собрать исполняемый файл, установите переменные среды, необходимые для инструментов командной строки, перейдите в директорию, содержащую makefile, и введите make. Чтобы скопировать исполняемый файл в поддиректорию binaries, введите make install. Чтобы удалить из директории make-файла исполняемый файл и промежуточный объектный файл, введите make clean.
Если вы установили среду Cygwin, описанную в рецепте 1.1, можете выполнить make-файл из примера 1.15 непосредственно из оболочки Windows cmd.exe.
Также этот make-файл можно выполнить из оболочки Cygwin, как описано далее. В cmd.exe запустите vcvars32.bat, устанавливающий переменные среды Visual С++. Затем запустите cygwin.bat, запускающий оболочку Cygwin. Если директория установки Cygwin добавлена в PATH, то оболочку Cygwin можно запустить из cmd.exe, просто введя cygwin. Наконец, перейдите в директорию, содержащую make-файл, и введите make.
Аналогично можно выполнить make-файл из оболочки MSYS: в cmd.exe запустите vcvars32.bat, затем запустите msys.bat, запускающий оболочку MSYS.
Если ваш инструментарий предоставляет сценарий для установки переменных среды, запуск make-файла из Cygwin или MSYS несколько более трудоемок, чем его запуск из cmd.exe. Однако для некоторых make-файлов это обязательное условие, так как они не будут работать из-под cmd.exe.
Обсуждение
В нескольких последующих рецептах вы увидите, что GNU make является достаточно мощным инструментом для сборки сложных проектов. Но что же она делает? Вот как она работает. При вызове make без аргументов она просматривает текущую директорию в поисках файла с именем GNUmakefile, makefile или Makefile и пытается собрать первую содержащуюся в нем цель, которая называется целью по умолчанию (default target). Если цель по умолчанию не устарела, что означает, что она существует, все ее пререквизиты существуют и ни один из них не был изменен с момента ее сборки, то работа make закончена. В противном случае она пытается сгенерировать цель по умолчанию из ее пререквизитов, выполнив соответствующий командный сценарий. Аналогично определению устаревания этот процесс рекурсивен: для каждого устаревшего пререквизита make ищет правило, содержащее этот пререквизит в качестве цели, и начинает весь процесс заново. Так продолжается до тех пор, пока цель по умолчанию не будет обновлена или пока не возникнет ошибка.
Из приведенного описания следует, что цель, не имеющая пререквизитов, не устаревает только в том случае, если она соответствует файлу в файловой системе. Следовательно, цель, соответствующая несуществующему файлу, всегда будет устаревшей и может использоваться для безусловного выполнения командного сценария. Такие цели называются phony targets (фиктивными).
Пометив цель атрибутом .PHONY, как в примерах 1.14 и 1.15, можно сказать make, что цель не соответствует файлу, и, таким образом, она всегда должна собираться заново.
И наоборот, пререквизит, соответствующий существующему файлу, никогда не устаревает при условии, что этот файл не указан в качестве цели одного из правил.
Теперь давайте посмотрим на то, что происходит при выполнении make-файла из примера 1.14. Фиктивная цель all всегда устаревшая: единственная ее цель — сказать make собрать hello.exe. В таком простом make-файле нет необходимости в цели all, но в более сложных примерах цель all может иметь несколько пререквизитов, правило с целью hello говорит make собрать, если требуется, hello с помощью g++. Если предположить, что текущая директория не содержит ничего, кроме файлов makefile и hello.cpp, цель hello будет устаревшей. Однако пререквизит не устарел, так как файл hello.cpp существует и так как hello.cpp не является целью одного из правил. Следовательно, make для компиляции и компоновки hello.cpp вызывает g++, генерируя тем самым файл hello. Пререквизит цели all обновляется, так что make собирает цель all — исполняя пустой командный сценарий — и выходит.
При вызове make с аргументом командной строки, соответствующим цели, make пытается собрать эту цель. Следовательно, выполнение make install приводит к выполнению следующих команд:
mkdir -p binaries
cp -p hello binaries
Первая команда создает, если она не существует, директорию binaries, а вторая команда копирует в эту директорию файл hello. Точно так же make clean вызывает команду
rm -f hello
которая удаляет hello.
При использовании Windows команды mkdir, cp и rm, используемые целями install и clean, указывают на инструменты GNU, поставляющиеся в составе Cygwin или MSYS
После того как вы поймете, как make анализирует зависимости, пример 1.14 покажется очень простым. Однако на самом деле он значительно сложнее, чем требуется. Рассмотрение различных методов его упрощения является хорошим способом узнать некоторые из основ make-файлов.
Переменные make
GNU make поддерживает переменные, чьими значениями являются строки. Наиболее часто переменные используются в make-файлах как символьные константы. Вместо того чтобы жестко указывать в нескольких местах make-файла имя файла или команды оболочки, вы можете присвоить имя файла или команды переменной и далее использовать эту переменную. Это дает возможность облегчить сопровождение make-файлов. Например, make-файл из примера 1.14 можно переписать с помощью переменных make так, как показано в примере 1.16.
Пример 1.16. make-файл для сборки исполняемого файла hello с помощью GCC, измененный с помощью переменных
# Указываем целевой файл и директорию установки
OUTPUTFILE=hello
INSTALLDIR=binaries
# Цель по умолчанию
.PHONY all
all: $(OUTPUTFILE)
# Собрать hello из hello.cpp
$(OUTPUTFILE): hello cpp
g++ -o hello hello.cpp
#Скопировать hello в поддиректорию binaries
.PHONY: install
install:
mkdir -p $(INSTALLDIR)
cd -p $(OUTPUTFILE) $(INSTALLDIR)
# Удалить hello
.PHONY: clean
clean:
rm -f $(OUTPUTFILE)
Здесь я ввел две переменные make — OUTPUTFILE и INSTALLDIR. Как вы можете видеть, значения переменным make присваиваются с помощью оператора присвоения =, и они вычисляются с помощью заключения их в круглые скобки с префиксом в виде знака доллара.
Также установить значение переменной make можно в командной строке с помощью записи make X=Y. Кроме того, при запуске make все переменные среды используются для инициализации переменных make с такими же именами и значениями. Значения, указанные в командной строке, имеют приоритет перед значениями, унаследованными от переменных среды. Значения, указанные в самом make-файле, имеют приоритет перед значениями, указанными в командной строке.
Также GNU make поддерживает автоматические переменные (automatic variables), имеющие специальные значения при выполнении командного сценария. Наиболее важные из них — это переменная $@, представляющая имя файла цели, переменная $<, представляющая имя файла первого пререквизита, и переменная $^,представляющая последовательность пререквизитов, разделенных пробелами. Используя эти переменные, мы можем еще сильнее упростить make-файл из примера 1.16, как показано в примере 1.17.
Пример 1.17. make-файл для сборки исполняемого файла hello с помощью GCC, измененный с помощью автоматических переменных
# Указываем целевой файл и директорию установки
OUTPUTFILE=hellо
INSTALLDIR=binaries
# Цель по умолчанию
.PHONY all
all: $(OUTPUTFILE)
# Собрать hello из hello.cpp
$(OUTPUTFILE) hello.cpp
g++ -o $@ $<
# Цели Install и clean как в примере 1 16
В командном сценарии g++ -o $@ $< переменная $@ раскрывается как hello, а переменная $< раскрывается как hello.cpp. Следовательно, make-файл из примера 1.17 эквивалентен файлу из примера 1.16, но содержит меньше дублирующегося кода.
Неявные правила
make-файл в примере 1.17 может быть еще проще. На самом деле командный сценарий, связанный с целью hello, избыточен, что демонстрируется выполнением make-файла из примера 1.18.
Пример 1.18. make-файл для сборки исполняемого файла hello с помощью GCC, измененный с помощью неявных правил
# Указываем целевой файл и директорию установки
OUTPUTFILE=hello
INSTALLDIR=binaries
# Цель по умолчанию
.PHONY: all
all: $(OUTPUTFILE)
# Говорим make пересобрать hello тогда, когда изменяется hello.cpp
$(OUTPUTFILE): hello.cpp
# Цели Install и clean как в примере 1.16
Откуда make знает, как собирать исполняемый файл hello из исходного файла hello.cpp, без явного указания? Ответ состоит в том, что make содержит внутреннюю базу данных неявных правил, представляющих операции, часто выполняемые при сборке приложений, написанных на С и С++. Например, неявное правило для генерации исполняемого файла из файла .cpp выглядит так, как в примере 1.19.
Пример 1.19. Шаблон правила из внутренней базы данных make
%: %.cpp
# исполняемые команды (встроенные):
$(LINK.cpp) $(LOADLIBS) $(LDLIBS) -о $@
Правила, первые строки которых имеют вид %xxx:%yyy, известны как шаблонные правила (pattern rules), а символ % действует как подстановочный знак (wildcard). Когда устаревшему пререквизиту не соответствует ни одно из обычных правил, make ищет доступные шаблонные правила. Для каждого шаблонного правила make пытается найти строку, которая при подстановке подстановочного знака в целевую часть правила даст искомый устаревший пререквизит. Если make находит такую строку, make заменяет подстановочные знаки для цели и пререквизитов шаблонного правила и создает новое правило. Затем make пытается собрать устаревший пререквизит с помощью этого нового правила.
Чтобы напечатать базу данных неявных правил GNU make, используйте make -p.
Например, при первом выполнении make-файла из примера 1.18 пререквизит hello цели по умолчанию all является устаревшим. Хотя hello фигурирует как цель правила $(OUTPUTFILE): hello.cpp, это правило не содержит командного сценария, и, таким образом, оно бесполезно для сборки файла hello. Следовательно, make выполняет поиск в своей внутренней базе данных и находит правило, показанное в примере 1.19. Подставляя в правило из примера 1.19 вместо подстановочного знака строку hello, make генерирует следующее правило с hello в качестве цели.
hello: hello.cpp
$(LINK.cpp) $(LOADLIBS) $(LDLIBS) -o $@
Пока все хорошо, но есть еще кое-что. Повторный взгляд на внутреннюю базу данных make показывает, что переменная LINK.cpp по умолчанию раскрывается как $(LINK.cc). В свою очередь LINK.cc по умолчанию раскрывается как
$(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
Наконец, переменная CXX по умолчанию раскрывается как g++, а четыре другие переменные — $(CXXFLAGS), $(CPPFLAGS), $(LDFLAGS) и $(TARGET_ARCH) — раскрываются как пустые строки. После выполнения всех этих подстановок получается следующее правило, которое теперь выглядит более знакомо.
hello: hello.cpp
g++ $^ -o $@
Запутались? Это не страшно. Если вы изучите приведенное объяснение и потратите некоторое время на изучение внутренней базы данных make, неявные правила приобретут смысл.
Возможности для настройки
Теперь, когда вы увидели, как шаблонное правило из примера 1.19 приводит к тому, что make собирает исполняемый файл hello из исходного файла hello.cpp, вы можете спросить, почему было необходимо использовать столько промежуточных шагов. Почему вместо сложного правила из примера 1.19 во внутреннюю базу данных make просто не добавить правило
%: %.cpp
g++ $^ -о $@
Ответ состоит в том, что промежуточные переменные, такие как $(CXX), $(CXXFLAGS), $(CPPFLAGS) и $(LDFLAGS), служат как точки настройки (customization points). Например, указав значение LDFLAGS в командной строке, в make-файле или установив значение переменной среды, можно указать дополнительные флаги, передаваемые компоновщику. Переменные CPPFLAGS и CXXFLAGS играют схожую роль для опций препроцессора и компилятора C++ соответственно. А установив значение переменной CXX, можно указать компилятор, отличный от GCC. Например, чтобы собрать hello с помощью Intel для Linux и используя make-файл из примера 1.18, вы должны в командной строке ввести make CXX=icpc, предполагая, что переменные среды, необходимые для компилятора Intel, уже установлены.
VPATH и директива vpath
В примере 1.18 make может применить правильное шаблонное правило, потому что файл .cpp находится в той же директории, в которой создается выходной файл. Если исходные файлы находятся в другой директории, то для указания make, где искать цели или пререквизиты, используется переменная VPATH.
VPATH = <путь-к-файлам-cpp>
Чтобы сказать make, что выполнять поиск определенных типов файлов требуется в определенном месте, используйте директиву vpath.
# искать файлы .exp в ../lib
vpath %. exp../lib
Смотри также
Рецепты 1.2 и 1.7.