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

Мое упорное игнорирование make в течении долгого времени, было обусловлено удобством используемых IDE, и нежеланием разбираться в этом "пережитке прошлого" (по сути - ленью). Однако, все эти надоедливые кнопочки, менюшки ит.п. атрибуты всевозможных студий, заставили меня искать альтернативу тому методу работы, который я практиковал до сих пор. Нет, я не стал гуру make, но полученных мною знаний вполне достаточно для моих небольших проектов. Данная статья предназначена для тех, кто так же как и я еще совсем недавно, желают вырваться из уютного оконного рабства в аскетичный, но свободный мир шелла.

Make- основные сведения

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

1) целями (то, что данное правило делает);
2) реквизитами (то, что необходимо для выполнения правила и получения целей);
3) командами (выполняющими данные преобразования).

В общем виде синтаксис makefile можно представить так:

# Индентация осуществляется исключительно при помощи символов табуляции, # каждой команде должен предшествовать отступ <цели>: <реквизиты> <команда #1> ... <команда #n>

То есть, правило make это ответы на три вопроса:

{Из чего делаем? (реквизиты)} ---> [Как делаем? (команды)] ---> {Что делаем? (цели)}
Несложно заметить что процессы трансляции и компиляции очень красиво ложатся на эту схему:

{исходные файлы} ---> [трансляция] ---> {объектные файлы}
{объектные файлы} ---> [линковка] ---> {исполнимые файлы}

Простейший Makefile

Предположим, у нас имеется программа, состоящая всего из одного файла:

/* * main.c */ #include int main() { printf("Hello World!\n"); return 0; }
Для его компиляции достаточно очень простого мэйкфайла:

Hello: main.c gcc -o hello main.c
Данный Makefile состоит из одного правила, которое в свою очередь состоит из цели - «hello», реквизита - «main.c», и команды - «gcc -o hello main.c». Теперь, для компиляции достаточно дать команду make в рабочем каталоге. По умолчанию make станет выполнять самое первое правило, если цель выполнения не была явно указана при вызове:

$ make <цель>

Компиляция из множества исходников

Предположим, что у нас имеется программа, состоящая из 2 файлов:
main.c
/* * main.c */ int main() { hello(); return 0; }
и hello.c
/* * hello.c */ #include void hello() { printf("Hello World!\n"); }
Makefile, выполняющий компиляцию этой программы может выглядеть так:

Hello: main.c hello.c gcc -o hello main.c hello.c
Он вполне работоспособен, однако имеет один значительный недостаток: какой - раскроем далее.

Инкрементная компиляция

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

Теперь, после изменения одного из исходных файлов, достаточно произвести его трансляцию и линковку всех объектных файлов. При этом мы пропускаем этап трансляции не затронутых изменениями реквизитов, что сокращает время компиляции в целом. Такой подход называется инкрементной компиляцией. Для ее поддержки make сопоставляет время изменения целей и их реквизитов (используя данные файловой системы), благодаря чему самостоятельно решает какие правила следует выполнить, а какие можно просто проигнорировать:

Main.o: main.c gcc -c -o main.o main.c hello.o: hello.c gcc -c -o hello.o hello.c hello: main.o hello.o gcc -o hello main.o hello.o
Попробуйте собрать этот проект. Для его сборки необходимо явно указать цель, т.е. дать команду make hello.
После- измените любой из исходных файлов и соберите его снова. Обратите внимание на то, что во время второй компиляции, транслироваться будет только измененный файл.

После запуска make попытается сразу получить цель hello, но для ее создания необходимы файлы main.o и hello.o, которых пока еще нет. Поэтому выполнение правила будет отложено и make станет искать правила, описывающие получение недостающих реквизитов. Как только все реквизиты будут получены, make вернется к выполнению отложенной цели. Отсюда следует, что make выполняет правила рекурсивно.

Фиктивные цели

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

$ make $ make install
Командой make производят компиляцию программы, командой make install - установку. Такой подход весьма удобен, поскольку все необходимое для сборки и развертывания приложения в целевой системе включено в один файл (забудем на время о скрипте configure). Обратите внимание на то, что в первом случае мы не указываем цель, а во втором целью является вовсе не создание файла install, а процесс установки приложения в систему. Проделывать такие фокусы нам позволяют так называемые фиктивные (phony) цели. Вот краткий список стандартных целей:

all - является стандартной целью по умолчанию. При вызове make ее можно явно не указывать.
clean - очистить каталог от всех файлов полученных в результате компиляции.
install - произвести инсталляцию
uninstall - и деинсталляцию соответственно.

Для того чтобы make не искал файлы с такими именами, их следует определить в Makefile, при помощи директивы.PHONY. Далее показан пример Makefile с целями all, clean, install и uninstall:

PHONY: all clean install uninstall all: hello clean: rm -rf hello *.o main.o: main.c gcc -c -o main.o main.c hello.o: hello.c gcc -c -o hello.o hello.c hello: main.o hello.o gcc -o hello main.o hello.o install: install ./hello /usr/local/bin uninstall: rm -rf /usr/local/bin/hello
Теперь мы можем собрать нашу программу, произвести ее инсталлцию/деинсталляцию, а так же очистить рабочий каталог, используя для этого стандартные make цели.

Обратите внимание на то, что в цели all не указаны команды; все что ей нужно - получить реквизит hello. Зная о рекурсивной природе make, не сложно предположить как будет работать этот скрипт. Так же следует обратить особое внимание на то, что если файл hello уже имеется (остался после предыдущей компиляции) и его реквизиты не были изменены, то команда make ничего не станет пересобирать . Это классические грабли make. Так например, изменив заголовочный файл, случайно не включенный в список реквизитов, можно получить долгие часы головной боли. Поэтому, чтобы гарантированно полностью пересобрать проект, нужно предварительно очистить рабочий каталог:

$ make clean $ make
Для выполнения целей install/uninstall вам потребуются использовать sudo.

Переменные

Все те, кто знакомы с правилом DRY (Don"t repeat yourself), наверняка уже заметили неладное, а именно - наш Makefile содержит большое число повторяющихся фрагментов, что может привести к путанице при последующих попытках его расширить или изменить. В императивных языках для этих целей у нас имеются переменные и константы; make тоже располагает подобными средствами. Переменные в make представляют собой именованные строки и определяются очень просто:

=
Существует негласное правило, согласно которому следует именовать переменные в верхнем регистре, например:

SRC = main.c hello.c
Так мы определили список исходных файлов. Для использования значения переменной ее следует разименовать при помощи конструкции $(); например так:

Gcc -o hello $(SRC)
Ниже представлен мэйкфайл, использующий две переменные: TARGET - для определения имени целевой программы и PREFIX - для определения пути установки программы в систему.

TARGET = hello PREFIX = /usr/local/bin .PHONY: all clean install uninstall all: $(TARGET) clean: rm -rf $(TARGET) *.o main.o: main.c gcc -c -o main.o main.c hello.o: hello.c gcc -c -o hello.o hello.c $(TARGET): main.o hello.o gcc -o $(TARGET) main.o hello.o install: install $(TARGET) $(PREFIX) uninstall: rm -rf $(PREFIX)/$(TARGET)
Это уже посимпатичней. Думаю, теперь вышеприведенный пример для вас в особых комментариях не нуждается.

Автоматические переменные

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

$@ Имя цели обрабатываемого правила
$< Имя первой зависимости обрабатываемого правила
$^ Список всех зависимостей обрабатываемого правила

Если кто либо хочет произвести полную обфускацию своих скриптов - черпать вдохновение можете здесь:

Эта статья представляет собой небольшое руководство по созданию Makefile-ов. В ней объясняется для чего нужен Makefile и дается несколько правил, которых следует придерживаться при его создании.

Введение

Допустим, вы разрабатываете некую программу под названием foo , состоящую из пяти заголовочных файлов -- 1.h , 2.h , 3.h , 4.h и -- 5.h , и шести файлов с исходным текстом программы на языке С - 1.cpp , 2.cpp , 3.cpp , 4.cpp , 5.cpp и main.cpp . (Хочу заметить, что в реальных проектах следует избегать подобного стиля именования файлов).

Теперь представим себе, что вы обнаружили ошибку в файле 2.cpp и исправили ее. Далее, чтобы получить исправленную версию программы вы компилируете все файлы, входящие в состав проекта, хотя изменения коснулись только одного файла. Это приводит к нерациональной потере времени, особенно если компьютер не слишком быстрый.

Существует ли решение проблемы?

Не стоит беспокоиться, друзья мои! Эта проблема уже давно решена. Опытными программистами была разработана утилита make . Вместо того, чтобы производить повторную компиляцию всех файлов с исходными текстами, она обрабатывает только те файлы, которые претерпели изменения. В нашем случае будет скомпилирован только один файл - 2.cpp . Разве это не здорово!?

Утилита make значительно упрощает жизнь, когда для сборки проекта необходимо выполнение длинных и сложных команд.
Проект иногда требует задания редко используемых, а потому сложных для запоминания опций компилятора. make избавит вас от необходимости удерживать их в памяти.
Единообразие, т.к. работа с этой утилитой поддерживается многими средами разработки.
Процесс сборки можно автоматизировать, поскольку make может быть вызвана из сценариев или из cron.

Для чего нужен Makefile?

Несмотря на все свои достоинства, утилита make ничего не знает о нашем проекте, поэтому необходимо создать простой текстовый файл, который будет содержать все необходимые инструкции по сборке. Файл с инструкциями по сборке проекта называется makefile (произносится как "мэйкфайл". прим. перев. ) .

Как правило этим файлам дается имя makefile или Makefile , в соответствии с соглашениями по именованию таких файлов. Если же вы дадите файлу инструкций другое имя, то вам потребуется вызывать утилиту make с ключом -f .

Например, если свой makefile вы назвали bejo , то команда на сборку проекта будет выглядеть так:

Make -f bejo

Структура файла

Makefile содержит разделы для "целей" , зависимостей и правил (rules) сборки. Все это оформляется следующим образом: сначала указывается имя цели (обычно это имя исполняемого или объектного файла), после которого следует двоеточие, затем следуют имена зависимостей, т.е. файлов, необходимых для получения данной цели. И, наконец, следует список правил: т.е. команд, которые необходимо выполнить для получения указанной цели.

Простой пример структуры makefile"а:

Target: dependencies command command ...

Каждое правило command должно начинаться с символа табуляции -- это обязательное условие! Отсутствие символа табуляции в начале строки с правилом - самая распространенная ошибка. К счастью, подобные ошибки легко обнаруживаются, так как утилита make сообщает о них.

Пример Makefile.

Ниже приводится простой пример (номера строк добавлены для ясности).

1 client: conn.o 2g++ client.cpp conn.o -o client 3 conn.o: conn.cpp conn.h 4g++ -c conn.cpp -o conn.o

В этом примере строка, содержащая текст
client: conn.o ,
называется "строкой зависимостей", а строка
g++ client.cpp conn.o -o client
называется "правилом" и описывает действие, которое необходимо выполнить.

А теперь более подробно о примере, приведенном выше:

Задается цель -- исполняемый файл client , который зависит от объектоного файла conn.o
Правило для сборки данной цели
В третьей строке задается цель conn.o и файлы, от которых она зависит -- conn.cpp и conn.h .
В четвертой строке описывается действие по сборке цели conn.o .

"Ложная" цель

Обычно "ложные" цели, представляющие "мнимое" имя целевого файла, используются в случае возникновения конфликтов между именами целей и именами файлов при явном задании имени цели в командной строке.

Допустим в makefile имеется правило, которое не создает ничего, например:

Clean: rm *.o temp

Поскольку команда rm не создает файл с именем clean , то такого файла никогда не будет существовать и поэтому команда make clean всегда будет отрабатывать.

Однако, данное правило не будет работать, если в текущем каталоге будет существовать файл с именем clean . Поскольку цель clean не имеет зависимостей, то она никогда не будет считаться устаревшей и, соответственно, команда "rm *.o temp" никогда не будет выполнена. (при запуске make проверяет даты модификации целевого файла и тех файлов, от которых он зависит. И если цель оказывается "старше", то make выполняет соответствующие команды-правила -- прим. ред.) Для устранения подобных проблем и предназначена специальная декларация .PHONY , объявляющая "ложную" цель. Например:

PHONY: clean

Таким образом мы указываем необходимость исполнения цели, при явном ее указании, в виде make clean вне зависимости от того - существует файл с таким именем или нет.

Переменные

Определить переменную в makefile вы можете следующим образом:

$VAR_NAME=value

В соответствии с соглашениями имена переменных задаются в верхнем регистре:

$OBJECTS=main.o test.o

Чтобы получить значение переменной, необходимо ее имя заключить в круглые скобки и перед ними поставить символ "$", например:

$(VAR_NAME)

В makefile-ах существует два типа переменных: "упрощенно вычисляемые" и "рекурсивно вычисляемые" .

TOPDIR=/home/tedi/project SRCDIR=$(TOPDIR)/src

При обращении к переменной SRCDIR вы получите значение /home/tedi/project/src .

Однако рекурсивные переменные могут быть вычислены не всегда, например следующие определения:

CC = gcc -o CC = $(CC) -O2

выльются в бесконечный цикл. Для разрешения этой проблемы следует использовать "упрощенно вычисляемые" переменные:

CC:= gcc -o CC += $(CC) -O2

Где символ ":=" создает переменную CC и присваивает ей значение "gcc -o". А символ "+=" добавляет "-O2" к значению переменной CC.

Заключение

Я надеюсь, что это краткое руководство содержит достаточно информации, чтобы начать создавать свои makefile. А за сим -- успехов в работе.

Библиография

1 GNU Make Documentation File, info make.
Kurt Wall, et.al., Linux Programming Unleashed (Программирование под Linux на оперативном просторе -- прим. ред.) , 2001.

Чаще всего сборка проекта в ОС Linux, с учётом зависимостей и обновлений, выполняется утилитой make , которая использует для этого заранее оформленный сценарий сборки. Мы уже неоднократно прибегали к помощи этой утилиты в предыдущих статьях, и эта статья будет посвящена исключительно вопросам использования утилиты make .

Утилита make

Утилита make автоматически определяет, какие части крупного проекта были изменены и должны быть перекомпилированы, а также выполняет действия, необходимые для этого. Но, на самом деле, область применения make не ограничивается только сборкой программ, так её можно использовать и для решения других задач, где одни файлы должны автоматически обновляться при изменении других файлов.

Утилита make доступна для разных ОС, и из-за особенностей выполнения наряду с «родной» реализацией во многих ОС присутствует GNU реализация gmake , и поведение этих реализаций в некоторых ОС, например, Solaris может существенно отличаться. Поэтому в сценариях сборки рекомендуется указывать имя конкретной утилиты. В ОС Linux эти два имени являются синонимами, реализованными через символическую ссылку, как показано ниже:

$ ls -l /usr/bin/*make lrwxrwxrwx 1 root root 4 Окт 28 2008 /usr/bin/gmake -> make -rwxr-xr-x 1 root root 162652 Май 25 2008 /usr/bin/make ... $ make --version GNU Make 3.81 ...

По умолчанию имя файла сценария сборки - Makefile . Утилита make обеспечивает полную сборку указанной цели , присутствующей в сценарии, например:

$ make $ make clean

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

$ make -f Makefile.my

Простейший файл Makefile состоит из синтаксических конструкций двух типов: целей и макроопределений. Описание цели состоит из трех частей: имени цели, списка зависимостей и списка команд интерпретатора оболочки, требуемых для построения цели. Имя цели - непустой список файлов, которые предполагается создать. Список зависимостей - список файлов, в зависимости от которых строится цель. Имя цели и список зависимостей составляют заголовок цели, записываются в одну строку и разделяются двоеточием (":"). Список команд записывается со следующей строки, причем все команды начинаются с обязательного символа табуляции . Многие текстовые редакторы могут быть настроены таким образом, чтобы заменять символы табуляции пробелами. Этот факт стоит учесть и проверить, что редактор, в котором редактируется Makefile , не замещает табуляции пробелами, так как подобная проблема встречается довольно часто. Любая строка в последовательности списка команд, не начинающаяся с табуляции (ещё одна команда) или символа "# " (комментарий) - считается завершением текущей цели и началом новой.

Утилита make имеет много внутренних параметров со значениями по умолчанию, важнейшими из которых являются правила обработки суффиксов, а также определения внутренних переменных окружения. Эти данные называются базой данных make и могут быть просмотрены следующим образом:

$ make -p >make.suffix make: *** Не заданы цели и не найден make-файл. Останов. $ cat make.suffix # GNU Make 3.81 # Copyright (C) 2006 Free Software Foundation, Inc. ... # База данных Make, напечатана Thu Apr 14 14:48:51 2011 ... CC = cc LD = ld AR = ar CXX = g++ COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c COMPILE.C = $(COMPILE.cc) ... SUFFIXES:= .out .a .ln .o .c .cc .C .cpp .p .f .F .r .y .l .s .S .mod .sym \ .def .h .info .dvi .tex .texinfo .texi .txinfo .w .ch... # Implicit Rules ... %.o: %.c # команды, которые следует выполнить (встроенные): $(COMPILE.c) $(OUTPUT_OPTION) $< ...

Значения всех этих переменных: CC , LD , AR , EXTRA_CFLAGS , ... могут использоваться файлом сценария как неявные определения со значениями по умолчанию. Кроме этого, можно определить и собственные правила обработки по умолчанию для выбранных суффиксов (расширений файловых имён), как это показано на примере выше для исходных файлов кода на языке С: %.c.

Большинство интегрированных сред разработки (IDE) или пакетов для создания переносимых инсталляций (например, automake или autoconf) ставят своей задачей создание файла Makefile для утилиты make .

Как ускорить сборку make

Сборка простых проектов происходит достаточно быстро, но с учётом роста проекта по ходу его развития, время сборки, основная часть которого затрачивается на компиляцию, может значительно вырасти. Хорошо известным примером такого рода является сборка ядра Linux, которая, в зависимости от типа оборудования, может занимать от нескольких десятков минут до часов процессорного времени. Усугубляет ситуацию и то, что при работе над проектом (доработка кода, отладка, поиск ошибок, тестирование, и т.д.) может понадобиться выполнять пересборку проекта по несколько десятков раз в день. Поэтому возможности, позволяющие ускорить этот процесс, приобретают действительную актуальность.

Так как сегодня однопроцессорные (одноядерные) системы уже практически вытеснены многоядерными конфигурациями, сборку многих проектов можно значительно (в разы) ускорить, используя возможность make запускать несколько заданий сборки в параллель с помощью ключа –j , как показано ниже:

$ man make ... -j , --jobs[=jobs] Specifies the number of jobs (commands) to run simultaneously. ...

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

$ pwd /usr/src/ntp-4.2.6p3

Сначала запустим сборку на 4-х ядерном процессоре Atom (не очень быстрая модель с частотой 1.66Ghz) но с очень быстрым твердотельным диском SSD:

$ cat /proc/cpuinfo | head -n10 processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 28 model name: Intel(R) Atom(TM) CPU 330 @ 1.60GHz stepping: 2 cpu MHz: 1596.331 cache size: 512 KB $ make clean # запускаем сборку в четыре потока $ time make -j4 ... real 1m5.023s user 2m40.270s sys 0m16.809s $ make clean # запускаем сборку в стандартном режиме без параллелизма $ time make ... real 2m6.534s user 1m56.119s sys 0m12.193s $ make clean # запускаем сборку с автоматическим выбранным уровнем параллелизма $ time make -j ... real 1m5.708s user 2m43.230s sys 0m16.301s

Как можно заметить, использование параллелизма (явное или не явное) позволяет ускорить сборку почти в два раза – 1 минута против 2-ух. Выполним сборку этого же проекта на более быстром 2-х ядерном процессоре, но с достаточно медленным обычным диском HDD:

$ cat /proc/cpuinfo | head -n10 processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 23 model name: Pentium(R) Dual-Core CPU E6600 @ 3.06GHz stepping: 10 cpu MHz: 3066.000 cache size: 2048 KB ... $ time make ... real 0m31.591s user 0m21.794s sys 0m4.303s $ time make -j2 ... real 0m23.629s user 0m21.013s sys 0m3.278s

Хотя итоговая скорость сборки и выросла в 3-4 раза, но улучшение от числа процессоров составляет только порядка 20%, так как «слабым звеном» здесь является медленный накопитель, допускающий задержку при записи большого числа мелких.obj файлов проекта.

Примечание : Хотелось бы напомнить, что не всякая сборка make , которая успешно выполняется на одном процессоре (как это имеет место по умолчанию или при указании -j1 ), будет также успешно выполняться при большем числе задействованных процессоров. Это связано с нарушениями синхронизации операций в случаях сложных сборок. Самым наглядным примером такой сборки, завершающейся с ошибкой в случае параллельного исполнения, является сборка ядра Linux для некоторых версий ядра. Возможность параллельного выполнения make нужно экспериментально проверять для собираемого проекта. Но в большинстве случаев это возможность может использоваться и позволяет в разы ускорить процесс сборки!

Если данный способ ускорения процесса сборки основан на том, что сейчас подавляющее большинство систем являются многопроцессорными (многоядерными), то следующий способ использует тот факт, что объём памяти RAM современных компьютеров (2-4-8 ГБ) значительно превышает объём памяти, необходимый для компиляции программного кода. В таком случае, компиляцию, основным сдерживающим фактором для которой является создание множества объектных файлов, можно перенести в область специального созданного диска (RAM диск, tmpfs ), расположенного в памяти:

$ free total used free shared buffers cached Mem: 4124164 1516980 2607184 0 248060 715964 -/+ buffers/cache: 552956 3571208 Swap: 4606972 0 4606972 $ df -m | grep tmp tmpfs 2014 1 2014 1% /dev/shm

Теперь можно временно перенести файлы собираемого проекта в tmpfs (мы по-прежнему используем NTP-сервер из предыдущего примера), в каталог /dev/shm :

$ pwd /dev/shm/ntp-4.2.6p3 $ make -j ... real 0m4.081s user 0m1.710s sys 0m1.149s

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

Этот способ ускорения можно применить к сборке ядра Linux, для которого, как уже было сказано, параллельная сборка не работает. Чтобы воспользоваться преимуществами RAM-памяти, скопируем дерево исходных кодов ядра в каталог /dev/shm :

$ pwd /dev/shm/linux-2.6.35.i686 $ time make bzImage ... HOSTCC arch/x86/boot/tools/build BUILD arch/x86/boot/bzImage Root device is (8, 1) Setup is 13052 bytes (padded to 13312 bytes). System is 3604 kB CRC 418921f4 Kernel: arch/x86/boot/bzImage is ready (#1) real 9m23.986s user 7m4.826s sys 1m18.529s

Как видно, сборка ядра Linux заняла менее 10 минут, что является необычайно хорошим результатом.

В качестве вывода, можно посоветовать тщательно оптимизировать условия сборки проекта под используемое для этого оборудование, и, учитывая, что в процессе отладки сборка выполняется сотни раз, то можно сэкономить множество времени!

Сборка модулей ядра

Частным случаем сборки приложений является сборка модулей ядра Linux (драйверов). Начиная с версий ядра 2.6, для сборки модуля составляется Makefile , построенный на использовании макросов, и нам остаётся только записать (для файла собственного кода с именем mod_params.c ), следующий шаблон для сборки модулей:

Листинг 1. Makefile для сборки модулей ядра

CURRENT = $(shell uname -r) KDIR = /lib/modules/$(CURRENT)/build PWD = $(shell pwd) TARGET = mod_params obj-m:= $(TARGET).o default: $(MAKE) -C $(KDIR) M=$(PWD) modules ... $ make make -C /lib/modules/2.6.18-92.el5/build \ M=examples/modules-done_1/hello_printk modules make: Entering directory `/usr/src/kernels/2.6.18-92.el5-i686" CC [M] /examples/modules-done_1/hello_printk/hello_printk.o Building modules, stage 2. MODPOST CC /examples/modules-done_1/hello_printk/hello_printk.mod.o LD [M] examples/modules-done_1/hello_printk/hello_printk.ko make: Leaving directory `/usr/src/kernels/2.6.18-92.el5-i686" $ ls -l *.o *.ko -rw-rw-r-- 1 olej olej 74391 Мар 19 15:58 hello_printk.ko -rw-rw-r-- 1 olej olej 42180 Мар 19 15:58 hello_printk.mod.o -rw-rw-r-- 1 olej olej 33388 Мар 19 15:58 hello_printk.o $ file hello_printk.ko hello_printk.ko: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped $ /sbin/modinfo hello_printk.ko filename: hello_printk.ko author: Oleg Tsiliuric license: GPL srcversion: 83915F228EC39FFCBAF99FD depends: vermagic: 2.6.18-92.el5 SMP mod_unload 686 REGPARM 4KSTACKS gcc-4.1

Заключение

В статье были рассмотрены аспекты работы с утилитой make, которые не часто описываются в литературе, но могут оказаться крайне полезными в практической работе. Также мы завершили обсуждение вопросов, связанных с поставкой и сборкой программного обеспечения в ОС Linux.

В следующей статье мы начнём знакомство с библиотеками API, присутствующими в POSIX системах.

Что такое Makefile? Makefile - это сценарий для утилиты make . Эта утилита помогает автоматизировать процесс компиляции проекта (проектов):

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

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

make -f prjmake.nmk

Makefile состоит из нескольких основных частей:

правила;
директивы;
переменные;
комментарии.

Начнем рассмотрение в обратном порядке списка - от простого к сложному.

Комментарии.
Комментарий обозначается символом "#". Если нужно использовать символ "#" в другом контексте, то необходимо добавить обратный слэш: "\#".

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

LIB = lib1.o lib2.o lib3.o

Название переменной задается в верхнем регистре (по негласному соглашению). Для получения параметров переменной используется смпользуются скобки и символ "
$(PATH)

Значение переменной может вычисляться рекурсивно:

PATH=$(PATH)/trunc

Либо можно использовать другую форму записи:

PATH+=/trunc

Некоторые переменные являются стандартыми константами, для них нельзя вычислять значение рекусивно. Такими перменными являются: CC (имя компилятора С), СХХ (имя компилятора С++), CFLAGS (параметры С компилятора), CXXFLAGS (параметры С++ компилятора).

Помимо переменных, определенных "писателем" файла, Make-файл предполагает использование автоматических переменных, значения которых вычисляются в контексте использования таких переменных (вычисление основывается на цели и зависимости правила - о целях и зависимостях ниже):

$@ - имя цели;
$$@ - имя цели, если его необходимо ввести в строке описания зависимости справа от двоеточия;
$? - имена всех зависимостей (с пробелами) которые новее, чем цель;
$^ - имена всез зависимостей с пробелами;
$* - имя текущего предусловия за вычетом суффикса;
$% - имя соответствующего.о файла, если текущей целью является файл библиотеки;
$** - только для nmake - внутри правила обозначаются все зависимости, оказавшиеся справа от двоеточия;
D - часть имени внутренних макроопределений, описывающая директорию файла (допустимые варианты применения: $(@D), $$(@D), $(
F - часть имени внутренних макоопределений, описывающая собственно имя файла (допустимые варианты прменения: $(@F), $$(@F), $(
B - часть имени внутренних макроопределений, описывающая базовое имя файла (без диска, директориии и расширения);
R - часть имени внутренних макроопределений, описывающая полный путь к файлу за вычетом расширения.

Директивы.
Директива - это команда для make с указанием, что делать в процессе чтения make-файла. Может выполнять такие действия:

подключать другие make-файлы;
принимать решение какие части файла использовать, а какие игнорировать (в зависимости от значения переменных);
определение значений переменных.

Поключать другие make-файлы можно директивой include. Она указвает утилите make , что нужно приостановить чтение текущего файла и прочитать указанные файлы:

include filenames...

Если фала не существует - выводиться ошибка. Для отключения сообщени об ошибке, к директиве добавлятеся префикс "-":

Include file1

Решение о том, какие части make-файла использовать, а какие игнорировать, примается на основе условий, синтаксис которого имеет вид:

conditional-directive
text-if-true
else
text-if-false
endif

Например:

libs_for_gcc = -lgnu
normal_libs =

foo: $(objects)
ifeq ($(CC),gcc)
$(CC) -o foo $(objects) $(libs_for_gcc)
else
$(CC) -o foo $(objects) $(normal_libs)
endif
Определить значение перенной можно при помощи дериктив define... endef:

define two-lines
echo foo
echo $(bar)
endef
В этом случает значение переменной two-lines = echo foo; echo $(bar)

Правила.
Правила объясняют make , что и как нужно пересобирать. В общем виде структура выглядит так:

targets: prerequisites
command
...

Здесь targets - имена файлов-результатов, разделенные пробелами; так же может быть действие не связанное с процессом компиляции, например, clean. prerequisites - зависимости, то, от чего зависит создание targets. command - комманда, которая выполняется для получения targets; может быть не одна; перед командой обязательно ставиться табуляция.

Существуют несколько фиктивных целей:

all - выполнение работы по достижению всех частных целей, перечисленных ниже;
build - компиляция и сборка всех устаренших (невыполненных) целей/файлов;
clean - удаление всех файлов, кроме исходных;
docs - подготовка документации и размещение таких файлов в соответствующих системных директориях;
examples - компиляция и сборка примеров;
install - работа, по размещению всех готовых частей проекта в соответствующих директориях.

В именах файлов могут использоваться wildcards:

objects = *.o

Пример использования правил:

# задаем цель - исполняемый файл mytest, зависимый от lib.o
mytest: lib.o
# задаем комманду, результатом которой будет mytest
$(CXX) mytest.cpp $^ -o $@

# задаем цель - файл lib.o, зависимый от libimpl.h и libimpl.с
lib.o: libimpl*
# задаем комманду, результатом которой будет lib.o
$(CXX) -c $^ -o $@

Помимо обычных правил, можно создавать шаблонные правила - правила, применимые к группе файлов. Такие правила имеют суффиксную форму записи:

# все o-файлы зависят от cpp-файлов
.cpp.o:
gcc -c $^

Если бы в предыдущем примере mytest зависел от нескольких o-файлов, то шаблонное правило можно было бы записать так:

mytest: lib.o map.o vector.o
gcc $^ -o $@

Cpp.o:
gcc -c $^

Некоторый ключи компилятора:
-I"path/to/include" - директория со списком хидеров.
-Wall-Werror - вывод варнингов.
-O1, -O2, -O3 - оптимизация.

Некоторые ключи сборки:
-llibrary - указывает линковшику использовать библиотеку library при сборке программы.
-s - не включает симольные таблицы и информацию о размещении функций в испольняемый файл. Использование этого ключа позволяет существенно ужать исполняемые файлы.
-L"path/to/libs" - директория с библиотеками.
-static - статическая компоновка библиотек.