Объектные файлы и статические библиотеки, от которых зависит исполняемый файл, требуются только при сборке исполняемого файла. Однако динамические библиотеки, от которых зависит исполняемый файл, должны иметься в системе пользователя при запуске исполняемого файла.
Таблица 1.1 приводит расширения файлов, обычно связанные с этими четырьмя базовыми типами файлов в Microsoft Windows и Unix. Когда я упоминаю файл, имеющий в Windows и Unix различные расширения, я иногда опускаю расширение, если оно ясно из контекста.
Табл. 1.1. Расширения файлов в Windows и Unix
| Тип файла | Windows | Mac OS X | Другие Unix |
|---|---|---|---|
| Объектные файлы | .obj | .o | .o |
| Статические библиотеки | .lib | .a | .a |
| Динамические библиотеки | .dll | .dylib | .so |
| Исполняемые файлы | .exe | Нет расширения | Нет расширения |
В этой главе, когда я говорю Unix, я также имею в виду и Linux.
При сборке примеров из этой главы ваши инструменты будут создавать большое количество вспомогательных файлов с расширениями, не приведенными в табл. 1.1. Если я не указываю другого, вы можете игнорировать эти файлы. Если вы действительно хотите знать, для чего они нужны, обратитесь к документации по вашему инструментарию.
Компилятор, компоновщик и архиватор — это инструменты командной строки, что означает, что они предназначены для запуска из оболочки, такой как bash в Unix или cmd.exe в Microsoft Windows. Имена входных и выходных файлов, а также вся остальная необходимая настроечная информация передаются в компилятор, компоновщик и архиватор как текст в командной строке. Однако вызов этих команд вручную довольно утомителен. Даже для небольших проектов может быть сложно запомнить параметры командной строки для каждого инструмента и порядок, в котором исходные и двоичный файлы проекта должны компилироваться и компоноваться. При изменении одного исходного файла вы должны определить, какие объектные файлы требуется перекомпилировать, какие статические библиотеки требуется обновить и какие исполняемые файлы или динамические библиотеки требуется перекомпоновать. Если вы пересоберете больше файлов, чем требуется, вы зря потратите время, а если пересоберете не все требуемые, то получите ошибки при сборке или неработоспособное приложение. В случае больших проектов на С++, которые могут включать тысячи отдельных файлов, включая исходные файлы, объектные файлы, библиотеки и исполняемые файлы, сборка из командной строки просто невозможна.
Имеется два основных подхода к сборке больших приложений на С++.
• IDE предоставляет графический интерфейс для организации набора исходных файлов и описания двоичных файлов, которые из них должны быть сгенерированы. После указания этой информации вы можете сгенерировать двоичные файлы просто выбрав в меню или на панели инструментов соответствующую команду. IDE отвечает за определение порядка генерации двоичных файлов, вызов инструментов, необходимых для их генерации, и опций командной строки, которые требуется передать в эти инструменты. Когда вы изменяете один или несколько исходных файлов вы можете указать IDE сгенерировать только устаревшие двоичные файлы.
IDE организуют исходные файлы в наборы, которые называются проектами. Проекты IDE обычно связаны с единственным двоичным файлом или несколькими вариантами одного двоичного файла, такими как отладочная и окончательная сборки приложения. Большинство IDE позволяет пользователю организовать проекты в группы, которые называются группами проектов или решениями, и указать зависимости между проектами в группе.
• Система сборки предоставляет формат текстового файла для описания набора исходных и генерируемых из них двоичных файлов, а также инструмент сборки, который читает эти текстовые файлы и генерирует двоичные файлы, вызывая соответствующие инструменты командной строки. Обычно эти текстовые файлы создаются и редактируются с помощью текстового редактора, а инструмент сборки вызывается из командной строки. Однако некоторые системы сборки предоставляют для редактирования этих файлов и вызова инструмента сборки графический интерфейс.
В то время как IDE организует файлы в проекты, система сборки организует файлы в цели. Большинство целей соответствует генерируемым двоичным файлам, другие соответствуют действиям, выполняемым инструментом сборки, таким как установка приложения.
Наиболее часто в качестве инструмента сборки используется утилита make; текстовые файлы, на которых она основана, называются makefile (make-файл). Хотя имеется множество версий make, в этой главе я обсуждаю GNU make — наиболее мощную и переносимую инкарнацию make. GNU make — это очень гибкий инструмент, который может использоваться не только для сборки приложений на С++. Он также имеет целый ряд преимуществ и широко используется и хорошо понимается разработчиками. К сожалению, заставить GNU make сделать именно то, что вам требуется, может оказаться не так просто, особенно в случае сложных проектов, использующих различные инструментарии. По этой причине я также описываю Boost.Build — мощную и расширяемую систему сборки, изначально предназначенную для сборки приложений на С++.
За подробным исследованием GNU make обратитесь к книге Роберта Мекленбурга (Robert Mecklenburg) Managing Projects with GNU make, Third Edition (издательство O'Reilly).
Boost.Build была разработана членами проекта Boost C++ Libraries. Она уже несколько лет используется большим сообществом разработчиков и постоянно активно совершенствуется. Boost.Build использует инструмент сборки, который называется bjam, и текстовые файлы, которые называются Jamfile (Jam-файлы). Ее самой сильной стороной является простота, с которой она позволяет управлять сложными проектами, предназначенными для нескольких платформ и содержащими несколько сборочных конфигураций. Хотя Boost.Build изначально создавалась как расширение системы сборки Perforce's Jam, она с тех пор подверглась значительной переработке. В момент сдачи этой книги в печать разработчики Boost.Build готовили официальный релиз второй основной версии этой системы сборки, и именно она описывается в этой главе