Описание правил

Традиционно файл с описанием правил носит название “makefile”. Если в опциях запуска не задано конкретное имя файла правил (опция -f), то по умолчанию, в качестве файла с описанием правил будет использован файл с именем “makefile”. Если в текущем каталоге данный файл отсутствует, то будет совершена попытка открыть файл с именем “Makefile” (с большой буквойM), и только если и такой файл не будет найден, утилита выдаст ошибку, о том что файл с описанием правил не найден.

При описании правил могут быть заданы:

• Правила построения;

• Переменные;

Синтаксис правила

Правила - основное содержимое make-файла. Рассмотрим внимательно, как они устроены:

цель 1 [цель 2..] : [зависимость 1..][; команды]

[\t команды]

Указанные в скобках компоненты могут быть опущены, целиизависимости, которые задают имена файлов или просто символические имена, являются цепочками из букв, цифр, символов . и /. Команды могут быть указаны после точки с запятой в строке зависимостей, или в строках, начинающихся с символатабуляции (указан как \t), которые следуют сразу за строкой зависимостей.

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

Рассмотрим пример makefile-mymake:

HELLO= “Привет”

a:a.ca.h

# Команды построения а

echo “$(HELLO) $(WHO)”

./d/b: ./d/b.c ./d/b.h

# Команды построенияb

all:a./d/b

/* Makefile*/

CXX = CC

targets = test_fork test_exit test_waitpid \

test_exec

all : $(targets)

$(targets) : $($@.C)

$(CXX) -o $@ $@.C

clean :

/bin/rm -f $(targets)

make –f mymake a ./d/b WHO = “всем”

При выполнении makeв первую очередь определяются все переменные, затем выполняются правила для целиmakefile. Затем проверяется существование файла с именем а, если путь не указан, то ищется в текущем каталоге, если файл не существует, то происходит попытка его создания вне зависимости от того, обновлялись ли файлыa.cилиa.h. Проверяется существование файлаa.cи если он не существует, то ищется правило для создания а.с. Если он существует, а правила нет, то считаем его готовым. Если файл существует, но есть правило, то рассматриваются правила его построения, если необходимо, то он перестраивается. Если файл не существует и нет правила его построения, то ошибка. Достаточно, чтобы один из файлов списка зависимостей обновился для того, чтобы была выполнена последовательность команд. Окончание последовательности команд – пустая строка или новая цель.

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

prog: x.c y.c z.c

cc -c $?

cc -o $@ x.o y.o z.o

Интерфейсы прикладного программирования unix и posix

В UNIX-системах имеется набор функций интерфейсов прикладного программирования (API)(широко известных как системные вызовы),которые могут вызываться программами пользователей для выполнения специфических системных задач. Эти функции позволяют пользовательским приложениям непосредственно манипулировать системными объектами типа файлов и процессов, чего нельзя сделать, используя только стандартные библиотечные функции С. Кроме того, многие командыUNIX, библиотечные функции С и стандартные классы C++ (например, классiostream)вызывают эти интерфейсы прикладного программирования для фактического выполнения необходимой работы. Таким образом, с помощью этихAPIпользователи могут избежать издержек, связанных с вызовом библиотечных функций С и стандартных классов C++, и создавать свои собственные версии командUNIX, библиотечных функций С и классов C++.

В большинстве UNIX-систем имеется общий набор APIдля решения следующих задач:

* определения конфигурации системы и получения информации о пользователях;

* манипулирования файлами;

* создания процессов и управления ими;

* осуществления межпроцессного взаимодействия;

* обеспечения связи по сети.

Большинство APIОСUNIXобращаются к внутренним ресурсам ядраUNIX. Так, когда один из этихAPIвызывается процессом (процесс - программа пользователя, находящаяся в состоянии выполнения), контекст выполнения процесса переключается ядром из режима пользователя в режим ядра. Режим пользователя — обычный режим выполнения любого пользовательского процесса. Он обеспечивает процессу доступ только к его собственным данным. Режим ядра — защищенный режим выполнения, который позволяет процессу пользователя получать ограниченный доступ к данным ядра. Когда выполнениеAPIзавершается, пользовательский процесс переключается обратно в режим пользователя. Это переключение контекста для каждого вызоваAPIгарантирует, что доступ процессов к данным ядра контролируется, и уменьшает вероятность того, что вышедшее из-под контроля пользовательское приложение сможет повредить всю систему. В общем, вызовAPIтребует больше времени, чем вызов пользовательской функции, из-за необходимости переключения контекста. Таким образом, для приложений, требующих высокого быстродействия, пользователи должны вызывать системныеAPIтолько в том случае, если это абсолютно необходимо.