Вначале в директории, где должна быть создана статическая библиотека, создайте make-файл и объявите фиктивную цель all, единственным пререквизитом которой будет статическая библиотека. Затем объявите цель статической библиотеки. Ее пререквизитами должны быть объектные файлы, входящие в состав библиотеки, а ее командный сценарий должен представлять собой командную строку для сборки библиотеки из набора объектных файлов, аналогично показанному в рецепте 1.3. При использовании GCC или компилятора с похожим синтаксисом командной строки настройте, если требуется, неявные правила шаблонов, изменив одну или более переменных CXX, CXXFLAGS и т.п., используемых в базе данных неявных правил make, как показано в рецепте 1.15. В противном случае, используя синтаксис шаблонных правил, описанный в рецепте 1.16, напишите шаблонное правило, говорящее make, как с помощью командной строки из табл. 1.8 компилировать .cpp-файлы в объектные. Далее явно или неявно объявите цели, указывающие, как каждый из исходных файлов библиотеки зависит от включаемых в него заголовков. Эти зависимости можно описать вручную или сгенерировать их автоматически. Наконец, добавьте цели install и clean, как показано в рецепте 1.15.
Например, чтобы с помощью GCC в Unix собрать из исходных файлов, перечисленных в примере 1.2, статическую библиотеку, создайте в директории johnpaul make-файл, показанный в примере 1.20.
Пример 1 20. make-файл для создания libjohnpaul.a с помощью GCC в Unix
# Укажите расширения файлов, удаляемых при очистке
CLEANEXTS - о а
# Укажите целевой файл и директорию установки
OUTPUTFILE = libjohnpaul.a
INSTALLDIR = ../binaries
# Цель по умолчанию
.PHONY: all
alclass="underline" $(OUTPUTFILE)
# Соберите libjohnpaul.a из john.o. paul.o и johnpaul.с
$(OUTPUTFILE): john.o paul.o johnpaul.о
ar ru $@ $^
ranlib $@
# Для сборки john.o, paul.o и johnpaul.о из файлов .cpp
# правила не требуются; этот процесс обрабатывается базой данных
# неявных правил make
.PHONY: install
instalclass="underline"
mkdir -p $(INSTALLDIR)
cp -p $(OUTPUTFILE) $(INSTALLDIR)
.PHONY: clean
clean:
for file in $(CLEANEXTS); do rm -f *.$$file; done
# Укажите зависимости файлов cpp от файлов .hpp
john.o: john.hpp
paul.o: paul.hpp
johnpaul.o: john.hpp paul.hpp johnpaul.hpp
Аналогично, чтобы собрать статическую библиотеку с помощью Visual С++, ваш make-файл должен выглядеть, как показано в примере 1.21.
Пример 1.21. make-файл для создания libjohnpaul.lib с помощью Visual C++
# Укажите расширения файлов, удаляемых при очистке
CLEANEXTS = obj lib
# Specify the target file and the install directory
OUTPUTFILE = libjohnpaul.lib
INSTALLDIR = ./binaries
# Шаблонное правило для сборки объектного файла из файла .cpp
%.obj: %.cpp
"$(MSVCDIR)/bin/cl" -с -nologo -EHsc -GP -Zc:forScope -Zc:wchar_t \
$(CXXFLAGS) S(CPPFLAGS) -Fo"$@" $<
# Фиктивная цель
.PHONY: all
alclass="underline" $(OUTPUTFILE)
# Соберите libjohnpaul.lib из john.obj, paul.obj и johnpaul.obj
$(OUTPUTFILE): john.obj paul.obj johnpaul.obj
"$(MSVCDIR)/bin/link" -lib -nologo -out:"$@" $^
.PHONY: install
instalclass="underline"
mkdir -p $(INSTALLDIR)
cp -p $(OUTPUTFILE) $(INSTALLDIR)
.PHONY: clean
clean:
for file in $(CLEANEXTS); do rm -f *.$$file; done
# Укажите зависимости файлов .cpp от файлов .hpp
john.obj: john.hpp
paul.obj: paul.hpp
johnpaul.obj: john.hpp paul.hpp johnpaul.hpp
В примере 1.21 я с помощью переменной среды MSVCDIR, устанавливаемой в vcvars32.bat, показал команду Visual C++ link.exe как "$(MSVCDIR)/bin/link". Это позволяет избежать путаницы между компоновщиком Visual C++ и командой Unix link, поддерживаемой Cygwin и MSYS. Для полноты картины я также использовал MSVCDIR для команды компиляции Visual С++.
Давайте подробно рассмотрим пример 1.20. Вначале я определяю переменные, представляющие выходной файл, директорию установки и расширения файлов, которые должны удаляться при сборке цели clean. Затем я объявляю цель по умолчанию all, как в примере 1.14.
Правило для сборки статической библиотеки выглядит так.
$(OUTPUTFILE): john.o paul.o johnpaul.о
ar ru $@ $^
ranlib $@
Это непосредственная адаптация записи для GCC из табл. 1.10. Здесь $(OUTPUTFILE) и $@ раскрываются как libjohnpaul.a, а $^ раскрывается в виде списка пререквизитов john.o paul.o johnpaul.о.
Следующие два правила объявляют цели install и clean, как в рецепте 1.15. Единственное отличие состоит в том, что в примере 1.20 для удаления всех файлов, чьи расширения имеются в списке о а — т. е. все объектные файлы и файлы статической библиотеки, - я использую цикл оболочки.
for file in $(CLEANEXTS); do rm -f *.$$file; done
Двойной знак доллара я использовал для того, чтобы запретить make раскрывать переменную $$file при передаче ее оболочке.
Три последних правила указывают отношения зависимостей между файлами .cpp библиотеки и включаемыми в них заголовочными файлами. Здесь указано по одному правилу для каждого .cpp-файла. Целью такого правила является объектный файл, собираемый из .cpp-файла, а пререквизитами являются заголовочные файлы, явно или неявно включаемые .cpp-файлом.
john.o: john.hpp
paul.o: paul.hpp
johnpaul.o. john.hpp paul.hpp johnpaul.hpp
Это можно понять следующим образом. Если .cpp-файл явно или косвенно включает заголовочный файл, то он должен быть пересобран при каждом изменении этого заголовочного файла. Однако, так как .cpp-файл существует и не является целью какого-либо правила, он никогда не устаревает, как описано в рецепте 1.15. Следовательно, при изменении заголовочного файла перекомпиляции не происходит. Чтобы исправить эту ситуацию, требуется объявить правило, сделав эти зависимости явными; когда один из используемых заголовочных файлов изменяется, объектный файл, соответствующий .cpp-файлу, устаревает, что приводит к перекомпиляции .cpp-файла.
Это решение удобно только для очень небольших проектов, так как очень сложно постоянно отслеживать зависимости целей, представляющих собой исходные файлы, входящие в большую базу кода. К счастью, имеется несколько способов автоматической генерации этих зависимостей. Например, три последних правила примера 1.20 можно заменить на следующие.