Каталог встроенных правил

Вот каталог предопределенных неявных правил, которые всегда доступны, если makefile явно не переопределяет или не отменяет их. См. Отмена неявных правил для получения информации об отмене или переопределении неявного правила. Опция ‘-r’ или ‘--no-builtin-rules’ отменяет все предопределенные правила.

В данном руководстве документированы только правила по умолчанию, доступные в операционных системах на основе POSIX. Другие операционные системы, такие как VMS, Windows, OS/2 и т. д., могут иметь разные наборы правил по умолчанию. Чтобы увидеть полный список правил и переменных по умолчанию, доступных в вашей версии GNU make, выполните ‘make -p’ в каталоге без makefile.

Не все эти правила всегда будут определены, даже если опция ‘-r’ не задана. Многие из предопределенных неявных правил реализованы в make как правила по суффиксу, поэтому какие из них будут определены, зависит от списка суффиксов (списка предшественников специальной цели .SUFFIXES). Список суффиксов по умолчанию: .out, .a, .ln, .o, .c, .cc, .C, .cpp, .p, .f, .F, .m, .r, .y, .l, .ym, .lm, .s, .S, .mod, .sym, .def, .h, .info, .dvi, .tex, .texinfo, .texi, .txinfo, .w, .ch .web, .sh, .elc, .el. Все неявные правила, описанные ниже, предшественники которых имеют один из этих суффиксов, фактически являются правилами по суффиксу. Если вы измените список суффиксов, единственными действующими предопределенными правилами по суффиксу будут те, которые названы одним или двумя суффиксами, которые присутствуют в указанном вами списке; правила, суффиксы которых не попали в список, будут отключены. См. Правила суффикса устаревшей формы для получения подробной информации о правилах суффикса.

Компиляция программ C

n.o автоматически создается из n.c с рецептом в форме ‘$(CC) $(CPPFLAGS) $(CFLAGS) -c’.

Компиляция программ C++

n.o автоматически создается из n.cc, n.cpp или n.C с рецептом в форме ‘$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c’. Рекомендуется использовать суффикс ‘.cc’ или ‘.cpp’ для файлов исходного кода C++ вместо ‘.C’, чтобы лучше поддерживать регистронезависимые файловые системы.

Компиляция программ Pascal

n.o автоматически создается из n.p с рецептом ‘$(PC) $(PFLAGS) -c’.

Компиляция программ Fortran и Ratfor

n.o автоматически создается из n.r, n.F или n.f путём запуска компилятора Fortran. Точный рецепт следующий:

‘.f’

‘$(FC) $(FFLAGS) -c’.

‘.F’

‘$(FC) $(FFLAGS) $(CPPFLAGS) -c’.

‘.r’

‘$(FC) $(FFLAGS) $(RFLAGS) -c’.

Предварительная обработка программ Fortran и Ratfor

n.f автоматически создается из n.r или n.F. Это правило запускает только препроцессор для преобразования программы Ratfor или обрабатываемой Fortran программы в строгую программу Fortran. Точный рецепт следующий:

‘.F’

‘$(FC) $(CPPFLAGS) $(FFLAGS) -F’.

‘.r’

‘$(FC) $(FFLAGS) $(RFLAGS) -F’.

Компиляция программ Modula-2

n.sym создается из n.def с рецептом в форме ‘$(M2C) $(M2FLAGS) $(DEFFLAGS)’. n.o создается из n.mod; форма: ‘$(M2C) $(M2FLAGS) $(MODFLAGS)’.

Ассемблирование и предварительная обработка программ ассемблера

n.o автоматически создается из n.s с помощью ассемблера, as. Точный рецепт: ‘$(AS) $(ASFLAGS)’.

n.s автоматически создается из n.S путём запуска препроцессора C, cpp. Точный рецепт: ‘$(CPP) $(CPPFLAGS)’.

Компиляция одного объектного файла

n автоматически создается из n.o с помощью компилятора C для компиляции программы. Точный рецепт: ‘$(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)’.

Это правило работает правильно для простой программы с одним исходным файлом. Оно также будет работать правильно, если существуют несколько объектных файлов (вероятно, полученных из различных других исходных файлов), один из которых имеет имя, соответствующее имени исполняемого файла. Таким образом,

x: y.o z.o

когда x.c, y.c и z.c все существуют, выполняется:

cc -c x.c -o x.o
cc -c y.c -o y.o
cc -c z.c -o z.o
cc x.o y.o z.o -o x
rm -f x.o
rm -f y.o
rm -f z.o

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

Каждый тип файла, автоматически преобразуемый в объектные файлы ‘.o’, будет автоматически линкован с помощью компилятора (‘$(CC)’, ‘$(FC)’ или ‘$(PC)’; компилятор C ‘$(CC)’ используется для ассемблирования файлов ‘.s’) без опции ‘-c’. Это можно сделать, используя объектные файлы ‘.o’ в качестве промежуточных, но быстрее выполнить компиляцию и линковку в одном шаге, поэтому так и делается.

Yacc для программ C

n.c автоматически создается из n.y путём запуска Yacc с рецептом ‘$(YACC) $(YFLAGS)’.

Lex для программ C

n.c автоматически создается из n.l с помощью Lex. Фактический рецепт: ‘$(LEX) $(LFLAGS)’.

Lex для программ Ratfor

n.r автоматически создается из n.l с помощью Lex. Фактический рецепт: ‘$(LEX) $(LFLAGS)’.

Использование одного и того же суффикса ‘.l’ для всех файлов Lex независимо от того, производят ли они код C или Ratfor, делает невозможным для make автоматически определить, какой из двух языков вы используете в конкретном случае. Если make призывается для пересоздания объектного файла из файла ‘.l’, он должен угадать, какой компилятор использовать. Он предположит компилятор C, поскольку это более распространено. Если вы используете Ratfor, убедитесь, что make знает об этом, упомянув n.r в makefile. Или, если вы используете только Ratfor без файлов C, удалите ‘.c’ из списка суффиксов неявных правил с:

.SUFFIXES:
.SUFFIXES: .o .r .f .l …

Создание библиотек Lint из программ C, Yacc или Lex

n.ln создается из n.c с помощью lint. Точный рецепт: ‘$(LINT) $(LINTFLAGS) $(CPPFLAGS) -i’. Тот же рецепт используется для кода C, сгенерированного из n.y или n.l.

TeX и Web

n.dvi создаётся из n.tex с рецептом ‘$(TEX)’. n.tex создаётся из n.web с ‘$(WEAVE)’, или из n.w (и из n.ch, если он существует или может быть создан) с ‘$(CWEAVE)’. n.p создаётся из n.web с ‘$(TANGLE)’ и n.c создаётся из n.w (и из n.ch, если он существует или может быть создан) с ‘$(CTANGLE)’.

Texinfo и Info

n.dvi создаётся из n.texinfo, n.texi или n.txinfo с рецептом ‘$(TEXI2DVI) $(TEXI2DVI_FLAGS)’. n.info создаётся из n.texinfo, n.texi или n.txinfo с рецептом ‘$(MAKEINFO) $(MAKEINFO_FLAGS)’.

RCS

Любой файл n извлекается при необходимости из файла RCS, имеющего имя либо n,v, либо RCS/n,v. Точный рецепт: ‘$(CO) $(COFLAGS)’. n не будет извлечён из RCS, если он уже существует, даже если файл RCS новее.

Правила для RCS являются конечными (см. Правила шаблонов сопоставления-всего), поэтому файлы RCS не могут быть сгенерированы из другого источника; они должны фактически существовать.

SCCS

Любой файл n извлекается при необходимости из файла SCCS, имеющего имя либо s.n, либо SCCS/s.n. Точный рецепт: ‘$(GET) $(GFLAGS)’.

Правила для SCCS являются конечными (см. Правила шаблонов сопоставления-всего), поэтому файлы SCCS не могут быть сгенерированы из другого источника; они должны фактически существовать.

Для SCCS файл n копируется из n.sh и делается исполняемым (для всех). Это для сценариев оболочки, которые проверены в SCCS. Поскольку RCS сохраняет разрешение на выполнение файла, вам не нужно использовать эту функцию с RCS.

Мы рекомендуем избегать использования SCCS. RCS считается превосходным и также бесплатным. Выбирая бесплатное программное обеспечение вместо сравнимого (или худшего) проприетарного программного обеспечения, вы поддерживаете движение свободного программного обеспечения.

Обычно вы хотите изменить только переменные, перечисленные в таблице выше, которые документированы в следующем разделе.

Однако рецепты во встроенных неявных правилах фактически используют такие переменные, как COMPILE.c, LINK.p, и PREPROCESS.S, значения которых содержат вышеуказанные рецепты.

make следует соглашению, что правило компиляции файла исходного кода .x использует переменную COMPILE.x. Аналогично, правило для создания исполняемого файла из файла .x использует LINK.x; а правило для предобработки файла .x использует PREPROCESS.x.

Каждое правило, которое создает объектный файл, использует переменную OUTPUT_OPTION. make определяет эту переменную либо как ‘-o $@’, либо как пустую строку, в зависимости от параметра времени компиляции. Вам нужен параметр ‘-o’, чтобы убедиться, что вывод попадает в правильный файл, когда исходный файл находится в другом каталоге, как при использовании VPATH (см. Поиск каталогов). Однако, компиляторы на некоторых системах не принимают переключатель ‘-o’ для объектных файлов. Если вы используете такую систему и используете VPATH, некоторые компиляции поместят свой вывод в неправильное место. Возможным решением этой проблемы является присвоение OUTPUT_OPTION значения ‘; mv $*.o $@’.