C++. Сборник рецептов

1.0. Введение в сборку

Эта глава содержит рецепты по преобразованию исходного кода на C++ в исполняемые программы и библиотеки. При изучении этих рецептов вы узнаете об основных инструментах, используемых при сборке приложений на С++, различных типах двоичных файлов, используемых в этом процессе, и системах, предназначенных для упрощения управления процессом сборки.

Если посмотреть на названия рецептов в этой главе, то можно получить впечатление, что я снова и снова решаю одни и те же проблемы. И это будет правильно. Это происходит потому, что имеется большое количество способов сборки приложений С++, и хотя я не могу описать их все, я пытаюсь описать несколько наиболее важных методов. В первой десятке рецептов я показываю, как различными методами выполнять три базовые задачи - собирать статические библиотеки, собирать динамические библиотеки и собирать исполняемые файлы. Рецепты сгруппированы по методам; сначала я рассматриваю сборку из командной строки, затем с помощью системы Boost (Boost.Build), затем с помощью интегрированной среды разработчика (Integrated Development Environment (IDE), и наконец, с помощью GNU make.

Прежде чем вы начнете читать рецепты, обязательно прочтите следующие вводные разделы. Я объясню некоторую базовую терминологию, дам обзор инструментов командной строки, систем сборки и IDE, описываемых в этой главе, и покажу примеры исходного кода.

Три базовых инструмента, используемых для сборки приложений С++, — это компилятор, компоновщик и архиватор (или библиотекарь). Набор этих программ и, возможно, других инструментов называется инструментарием.

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

Исполняемый файл, или приложение, — это просто любая программа, которая может выполняться операционной системой. Динамическая библиотека, также называемая совместно используемой библиотекой, похожа на исполняемый файл, за исключением того, что она не может исполняться самостоятельно. Она состоит из тела машинного кода, которое загружается в память после запуска приложения, и может использоваться одним или несколькими приложениями. В Windows динамические библиотеки также называются динамически подключаемыми библиотеками (dynamic link libraries (DLL)).

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

Таблица 1.1 приводит расширения файлов, обычно связанные с этими четырьмя базовыми типами файлов в Microsoft Windows и Unix. Когда я упоминаю файл, имеющий в Windows и Unix различные расширения, я иногда опускаю расширение, если оно ясно из контекста.

Табл. 1.1. Расширения файлов в Windows и Unix

Компилятор, компоновщик и архиватор — это инструменты командной строки, что означает, что они предназначены для запуска из оболочки, такой как 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 — мощную и расширяемую систему сборки, изначально предназначенную для сборки приложений на С++.

Boost.Build была разработана членами проекта Boost C++ Libraries. Она уже несколько лет используется большим сообществом разработчиков и постоянно активно совершенствуется. Boost.Build использует инструмент сборки, который называется bjam, и текстовые файлы, которые называются Jamfile (Jam-файлы). Ее самой сильной стороной является простота, с которой она позволяет управлять сложными проектами, предназначенными для нескольких платформ и содержащими несколько сборочных конфигураций. Хотя Boost.Build изначально создавалась как расширение системы сборки Perforce's Jam, она с тех пор подверглась значительной переработке. В момент сдачи этой книги в печать разработчики Boost.Build готовили официальный релиз второй основной версии этой системы сборки, и именно она описывается в этой главе

В этой главе я буду обсуждать семь наборов инструментов командной строки: GCC, Visual C++, Intel, Metrowerks, Borland, Comeau и Digital Mars. Таблица 1.2 показывает имена инструментов командной строки из различных инструментариев, а табл. 1.3 показывает, где они расположены в вашей системе, если они установлены. Имена инструментов для Windows используют суффикс .exe, который требуется для исполняемых файлов Windows. Для инструментария, доступного как для Windows, так и для Unix, я заключаю этот суффикс в квадратные скобки.

Табл. 1.2. Имена инструментов командной строки в различном инструментарии

Табл. 1.3. Расположение ваших инструментов командной строки

¹ В предыдущих версиях Visual Studio директория VC называлась VC98 или Vc7.

Пусть количество инструментария вас не пугает - вам не требуется изучать их все. В большинстве случаев можно просто пропустить материал, который не относится к вашему инструментарию. Однако, если вы хотите узнать немного о другом инструментарии, прочтите разделы о Visual C++ и GCC, так как это основной инструментарий для Windows и Unix.

Теперь давайте посмотрим на каждый из этих семи наборов.

GCC — это набор компиляторов для большого количества языков, включая С и С++. Следует заметить, что он является проектом с открытыми исходными кодами, доступен почти для всех имеющихся в природе платформ и обладает высокой степенью соответствия стандарту языка С++. Это основной компилятор для многих платформ Unix, он также широко используется в Microsoft Windows. Даже если GCC не является вашим основным инструментарием, вы можете многое узнать, используя его для компиляции своего кода. Также, если вы думаете, что знаете способ улучшить язык C++, проверьте свою идею на базе кода GCC.

GCC поставляется вместе с libstdc++ — хорошей реализацией с открытыми кодами стандартной библиотеки С++. Также он может использоваться совместно со стандартной библиотекой C++ с открытыми исходниками STLPort и со стандартной библиотекой Dinkumware

Инструментарий Microsoft является главным на платформе Windows. Хотя до сих пор широко используются некоторые старые версии, лучше всего соответствуют стандарту самые последние версии. Также он может создавать хорошо оптимизированный код. Инструменты Microsoft распространяются вместе со средами разработки Visual C++ и Visual Studio, которые обсуждаются в следующем разделе. В момент написания этой книги они также были доступны в составе Visual C++ Toolkit 2003, который можно бесплатно скачать с www.microsoft.com.

Visual C++ поставляется в комплекте с модифицированной версией реализации стандартной библиотеки C++ Dinkumware. Стандартная библиотека C++ Dinkumware является одной из наиболее эффективных и наиболее полно соответствующих стандарту коммерческих реализаций. Она доступна на различных платформах и поддерживает многие из наборов инструментов, описываемых в этой главе.

Табл. 1.4. Версии Microsoft Visual Studio

Intel производит несколько компиляторов С++, предназначенных для использования со своими процессорами. Они отличаются генерацией очень быстрого кода — возможно, самого быстрого, доступного для архитектуры Intel. Основанные на интерфейсной части C++ производства Edison Design Group (EDG), они также очень хорошо соответствуют стандарту.

Компилятор Intel C++ для Windows используется совместно со средой разработки Microsoft's Visual C++ или Visual Studio, которая требуется для его правильного функционирования. Этот компилятор разработан с учетом совместимости с Visual С++: он может использоваться как дополнение к среде разработки Visual С++, может генерировать код, который на двоичном уровне совместим с кодом, генерируемым компилятором Visual С++, он предлагает многие из таких же опций командной строки, что и компилятор Visual C++, и, если вы не указали не делать этого, даже эмулирует некоторые из ошибок Microsoft. Коммерческую версию компилятора Intel C++ для Windows можно приобрести по адресу www.intel.com. Также имеется академическая версия по более низкой цене.

В то время как компилятор Intel для Windows разработан с учетом совместимости с компилятором Visual С++, компилятор Intel для Linux разработан с учетом совместимости с GCC. Для работы ему требуется GCC, он поддерживает многие опции GCC и по умолчанию реализует некоторые из расширений GCC. Коммерческую версию компилятора Intel C++ для Linux можно приобрести по адресу www.intel.com. Некоммерческая версия доступна для бесплатного скачивания.

В Windows компилятор Intel использует стандартную библиотеку Dinkumware, поставляемую вместе с Visual С++. В Linux он использует libstdc++.

Инструменты командной строки Metrowerks, распространяемые вместе со средой разработки CodeWarrior, относятся к числу лучших как с точки зрения соответствия стандарту, так и с точки зрения эффективности генерируемого кода. Они также поставляются вместе с MSL — превосходной реализацией стандартной библиотеки C++ от Metrowerks. До недавнего времени Metrowerks разрабатывала инструменты для Windows, Mac OS и некоторых встраиваемых платформ. Однако в 2004 году Metrowerks продала свои технологии компилятора и отладчика для Intel х86 фирме Nokia и прекратила выпуск линии продуктов CodeWarrior для Windows. В 2005 году, после того как Apple Computer анонсировала планы по переходу на процессоры Intel, Metrowerks объявила, что будущая версия CodeWarrior 10 для Mac OS будет, скорее всего, последней для этой платформы. В будущем Metrowerks сосредоточит свое внимание на разработке для встраиваемых систем на основе чипов производства Freescale Semiconductor.

Инструменты командной строки Borland когда-то считались очень хорошими. Однако к сентябрю 2005 года последнее обновление насчитывало уже три года и представляло собой только незначительные улучшения предыдущей версии, которая была выпущена в 2000 году. В результате теперь инструменты Borland являются несколько устаревшими. В 2003 году Borland анонсировала планы по серьезному редизайну компилятора С++, используя интерфейсную часть EGD. К сожалению, в течение прошедшего времени Borland не делала больше никаких новых анонсов. Однако инструменты командной строки Borland остаются важны, так как все еще широко используются.

В настоящее время самая последняя версия инструментов командной строки Borland может быть приобретена в составе сред разработки C++Builder или C++BuilderX, описываемых в следующем разделе, или в составе доступной для бесплатной закачки персональной редакции C++BuilderX.

Инструментарий Borland поставляется с двумя стандартными библиотеками С++: STLPort и устаревшей версией стандартной библиотеки Rogue Wave. Также Borland разрабатывает версию инструментов, которые будут поставляться со стандартной библиотекой Dinkumware.

Компилятор Comeau широко известен своим полным соответствием стандарту С++. Кроме реализации самых последних версий языка C++ он поддерживает несколько версий С и большое количество ранних диалектов С++. Он также является одним из самых дешевых, стоя на настоящий момент $50.

Аналогично компилятору Intel Comeau использует интерфейс EDG и требует для корректной работы отдельного компилятора С. В отличие от Intel, Comeau может использовать в качестве внутреннего интерфейса различные компиляторы С.

Comeau доступен для Microsoft Windows и для многих видов Unix. Если для вашей платформы Comeau недоступен, вы можете оплатить Comeau Computing создание отдельной версии, но это значительно дороже. Заказать компилятор Comeau можно по адресу www.comeaucomputing.com.

Comeau поставляется с libcomo — реализацией стандартной библиотеки С++, основанной на стандартной библиотеке Silicon Graphics. Также он может использовать стандартную библиотеку Dinkumware.

Digital Mars — это компилятор С++, написанный Вальтером Брайтом (Walter Bright). Его можно бесплатно скачать с www.digitalmars.com, а за небольшую сумму можно заказать CD, содержащий компилятор Digital Mars, IDE и некоторые полезные инструменты. Бесплатная версия компилятора может компилировать все примеры Digital Mars из этой главы, за исключением тех, которые требуют динамическую версию рабочей библиотеки, доступную только на CD.

Digital Mars — это очень быстрый компилятор, создающий сильно оптимизированный код. К сожалению, у него есть некоторые проблемы с компиляцией кода, использующего расширенные идиомы шаблонов. К счастью, Вальтер Брайт очень быстро отвечает на сообщения об ошибках и стремится сделать Digital Mars соответствующим стандарту.

Digital Mars поставляется с двумя стандартными библиотеками: портом стандартной библиотеки STLPort и более старой "стандартной библиотекой, которая не соответствует стандарту и неполна. В целях обратной совместимости STLPort должен явно подключаться пользователем. Все примеры Digital Mars в этой главе используют стандартную библиотеку STLPort.

В этой главе я описываю четыре IDE: Microsoft Visual С++, Metrowerks CodeWarrior, Borland C++Builder и Bloodshed Software Dev-C++. Есть большое количество различных IDE, не охватываемых мной, — примерами являются Apple Xcode и Eclipse Project, — но рассмотрение этих четырех IDE должно дать вам достаточно материала для начала изучения других IDE.

Microsoft Visual C++ — это главная среда разработки C++ для Microsoft Windows. Она доступна как отдельное приложение или как часть набора Visual Studio и поставляется в комплекте с большим набором инструментов для разработки под Windows. Для переносимой разработки на C++ наиболее важными ее качествами являются

• высокое соответствие компилятора стандарту С++;

• стандартная библиотека C++ Dinkumware;

• хороший визуальный отладчик;

• менеджер проектов, который отслеживает зависимости между проектами.

Широко используются несколько версий Visual Studio. Так как названия различных версий могут сбить с толку, я перечислил наиболее широко используемые версии в табл. 1.4.

Первая версия Visual С++, включающая первоклассные компилятор и стандартную библиотеку, находится в третьей строке табл. 1.4. Все предшествующие версии имеют серьезные проблемы с реализацией стандарта.

CodeWarrior — это кросс-платформенная среда разработки Metrowerks. Она имеет большинство таких же функций, что и Visual С++, включая:

• высокое соответствие компилятора стандарту С++;

• превосходную стандартную библиотеку C++;

• хороший визуальный отладчик;

• менеджер проектов, который отслеживает зависимости между проектами.

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

C++Builder — это среда разработки Borland для приложений Microsoft Windows. Одной из ее привлекательных черт является поддержка библиотеки Borland's Visual Component Library. Однако для переносимой (мобильной) разработки на C++ наиболее важными ее качествами являются:

• проверенный временем компилятор С++;

• стандартная библиотека STLPort;

• хороший визуальный отладчик;

• менеджер проектов с ограниченной способностью управлять зависимостями проектов.

Я описываю C++Builder, потому что он широко используется и у него есть большое сообщество преданных пользователей.

C++Builder не следует путать с C++BuilderX — кросс-платформенной средой разработки, выпущенной Borland в 2003 году. Хотя C++BuilderX является полезным инструментом разработки, он не имел коммерческого успеха и неизвестно, будет ли Borland выпускать его новые версии.

Bloodshed Software Dev-C++ — это бесплатная среда разработки C++ для Windows, использующая порт MinGW GCC, описанный в рецепте 1.1. Он содержит вполне удобный текстовый редактор и визуальный интерфейс для отладчика GNU.

Dev-C++ предлагает неполный графический интерфейс для многочисленных опций командной строки GCC: во многих случаях пользователи должны настраивать свои проекты, вводя в текстовые поля опции командной строки. Кроме того, его менеджер проектов может управлять только одним проектом, а визуальный отладчик ненадежен. Несмотря на эти ограничения, Dev-C++ поддерживается большим сообществом пользователей, включая студентов многих университетов. Это хорошая среда для того, кто хочет изучить С++, но не имеет никаких инструментов для разработки на С++.

Co времен, когда в 1978 году Брайан Керниган (Brian Kernighan) и Деннис Ритчи (Dennis Ritchie) опубликовали книгу The С Programming Language (Язык программирования С), стало традицией начинать изучение нового языка программирования с написания, компиляции и запуска небольшой программки, которая печатает в консоли «Hello, World!» («Привет, мир!»). Так как эта глава описывает статические и динамические библиотеки, а также исполняемые файлы, мне потребуется несколько более сложный пример.

Примеры 1.1, 1.2 и 1.3 представляют исходный код приложения hellobeatles, которое выводит текст

John, Paul, George, and Ringo

на консоль. Это приложение можно написать в виде единого исходного файла, но я разбил его на три модуля: статическую библиотеку libjohnpaul, динамическую библиотеку libgeorgeringo и исполняемый файл hellobeatles. Более того, хотя каждая из этих библиотек могла бы быть легко реализована как один заголовочный файл и один файл .cpp, я, чтобы проиллюстрировать компиляцию и компоновку проектов, содержащих более одного исходного файла, разбил реализацию на несколько исходных файлов.

Исходный код libjohnpaul представлен в примере 1.1. Открытый интерфейс libjohnpaul состоит из одной функции

johnpaul()

johnpaul()

John, Paul,

на консоль. Реализация

johnpaul()

Пример 1.1. Исходный код libjohnpaul

johnpaul/john.hpp

#ifndef JOHN_HPP_INCLUDED

#define JOHN_HPP_INCLUDED

void john(); // Печатает "John, "

#endif // JOHN _HPP_INCLUDED

johnpaul/john.cpp

#include 

#include "john.hpp"

void john() {

 std::cout << "John, ";

}

johnpaul/paul.hpp

#ifndef PAUL_HPP_INCLUDED

#define PAUL_HPP_INCLUDED

void paul(); // Печатает " Paul, "

#endif // PAUL_HPP_INCLUDED

johnpaul/paul.cpp

#include 

#include "paul.hpp"

void paul() {

 std::cout << "Paul, ";

}

johnpaul/johnpaul.hpp

#ifndef JOHNPAUL_HPP_INCLUDED

#define JOHNPAUL_HPP_INCLUDED

void johnpaul(); // Печатает "John, Paul, "

#endif // JOHNPAUL_HPP_INCLUDED

johnpaul/johnpaul.cpp

#include "john.hpp"

#include "paul.hpp"

#include "johnpaul.hpp"

void johnpaul() {

 john();

 paul();

}

Исходный код libgeorgeringo представлен в примере 1.2. Открытый интерфейс libgeorgeringo состоит из одной функции

georgeringo()

georgeringo()

George, and Ringo

на консоль. И снова реализация

georgeringo()

Пример 1.2. Исходный код libgeorgeringo

georgeringo/george.hpp

#ifndef GEORGE_HPP_INCLUDED

#define GEORGE_HPP_INCLUDED

void george(); // Печатает "George, "

#endif // GEORGE_HPP_INCLUDED

georgeringo/george.cpp

#include 

#include "george.hpp"

void george()

 std::cout << "George, ";

}

georgeringo/ringo.hpp

#ifndef RINGO_HPP_INCLUDED

#define RINGO_HPP_INCLUDED

void ringo(); // Печатает "and Ringo\n"

#endif // RINGO_HPP_INCLUDED

georgeringo/ringo.cpp

#include 

#include "ringo.hpp"

void ringo() {

 std::cout << "and Ringo\n";

}

georgeringo/georgeringo.hpp

#ifndef GEORGERINGO_HPP_INCLUDED

#define GEORGERINGO_HPP_INCLUDED

// определите GEORGERINGO_DLL при сборке libgeorgeringo.dll

#if defined(_WIN32) && !defined(__GNUC__)

#ifdef GEORGERINGO_DLL

# define GEORGERINGO_DECL __declspec(dllexport)

#else

# define GEORGERINGO_DECL __declspec(dllimport)

#endif

#endif // WIN32

#ifndef GEORGERINGO_DECL

# define GEORGERINGO_DECL

#endif

// Печатает "George, and Ringo\n"

#ifdef __MWERKS__

# pragma export on

#endif

GEORGERINGO_DECL void georgeringo();

#ifdef __MWERKS__

# pragma export off

#endif

#endif // GEORGERINGO_HPP_INCLUDED

georgeringo/georgeringo.cpp

#include "george.hpp"

#include "ringo.hpp"

#include "georgeringo.hpp"

void georgeringo() {

 george();

 ringo();

}

Заголовок georgeringo.hpp содержит несколько сложных директив препроцессора. Если вы их не понимаете, не страшно. Я объясню их в рецепте 1.4.

Наконец, исходный код исполняемого файла hellobeatles представлен в примере 1.3. Он состоит из единственного исходного файла hellobeatles.cpp, который просто включает заголовки johnpaul.hpp и georgeringo.hpp и вызывает функцию

johnpaul()

georgeringo()

Пример 1.3. Исходный код hellobeatles

hellobeatles/ hellobeatles.cpp

#include "johnpaul/johnpaul.hpp"

#include "georgeringo/georgeringo.hpp"

int main() {

 // Печатает "John, Paul, George, and Ringo\n"

 johnpaul();

 georgeringo();

}

1.1. Получение и установка GCC

Вы хотите получить GCC — свободно распространяемый компилятор GNU C/С++.

Решение зависит от вашей операционной системы.

Установите MinGW, Cygwin или оба.

Чтобы установить MinGW, посетите страницу MinGW по адресу www.mingw.org и проследуйте по ссылкам до страницы загрузки MinGW. Скачайте последнюю версию программы установки MinGW, которая должна иметь имя MinGW-<версия>.exe.

Далее запустите программу установки. Она попросит вас указать, куда вы хотите установить MinGW. Также она может спросить, какие пакеты вы хотите установить, - как минимум вы должны установить gcc-core, gcc-g++, binutils и среду выполнения MinGW, но можно установить и другие. По окончании установки вы сможете запустить из командной строки Windows gcc, g++, ar, ranlib, dlltool и некоторые другие инструменты GNU. Вам может потребоваться добавить директорию bin установки MinGW в переменную среды окружения

PATH

Чтобы установить Cygwin, посетите страницу Cygwin по адресу www.cygwin.com и для загрузки программы установки Cygwin проследуйте по ссылке Install Cygwin Now. Далее запустите программу установки. Она попросит вас выбрать несколько опций, таких как путь, куда следует устанавливать Cygwin.

Наиболее важным выбором является выбор пакетов. Если у вас достаточно места на диске и высокоскоростное соединение с Интернетом, я рекомендую устанавливать все пакеты. Чтобы сделать это, щелкните на слове Default (По умолчанию) рядом со словом All (Все) в верхней части иерархии пакетов. После паузы (возможно, продолжительной) слово Default должно измениться на Install (Установить).

Если места на диске недостаточно или у вас медленное соединение с Интернетом, можете выбрать меньшее количество пакетов. Чтобы выбрать только инструменты разработки, щелкните на слове Default рядом со словом Devel. После паузы (возможно, продолжительной) слово Default должно измениться на Install. Для выбора еще меньшего набора пакетов раскройте список пакетов для разработки, щелкнув на пиктограмме + рядом со словом Devel. Выберите пакеты gcc-core, gcc-g++ и make, щелкнув на слове Skip (Пропустить) напротив каждого из этих пакетов, в результате чего это слово сменится на Install.

По окончании выбора пакетов нажмите на Finish (Готово). Когда программа установки завершит работу, директория установки Cygwin должна содержать файл cygwin.bat. Запуск этого сценария приведет к отображению оболочки Cygwin — среды с командной строкой, из которой можно запускать gcc, g++, ar, ranlib, dlltool, make и любые другие установленные вами утилиты. Процесс установки добавляет поддиректорию bin установки Cygwin в переменную среды окружения

PATH

Введя в командной строке

g++ -v

Using built-in specs.

Target: powerpc-apple-darwin8

Configured with /private/var/tmp/gcc/gcc-5026.obj~19/src/configure

--disable-checking --prefix=/usr ...

Если GCC не установлен или если он установлен без поддержки С++, вы должны самостоятельно установить его. Обычно это сложный процесс, который зависит от вашей платформы. Среди прочего вам потребуется установить пакеты GNU make и GNU binutils. Подробные инструкции доступны по адресу gcc.gnu.org/install.

Если вы используете Mac OS X, то простейшим способом получения GCC является скачивание с Web-сайта Apple среды разработки Xcode и следование простым инструкциям ее установки. В настоящий момент Xcode доступен по адресу developer.apple.com/tools.

Если вы используете Linux, то какая-то версия GCC уже должна быть установлена. Чтобы проверить номер версии, введите

g++ -v

Cygwin и MinGW представляют очень разные подходы к портированию инструментов GNU в Windows. Cygwin — это амбициозный проект, стремящийся воспроизвести Unix-подобную среду, работающую под Windows. Он предоставляет уровень совместимости с Unix, что позволяет компилировать и выполнять под Windows программы, написанные для Unix. Следовательно, для Cygwin доступно огромное количество утилит Unix. Даже если вы не разрабатываете для Unix, вы, возможно, скоро станете считать, что вам необходимы инструменты Cygwin.

MinGW, что означает «Minimalist GNU for Windows» (минимальный GNU для Windows), предоставляет минимальную среду для сборки исполняемых файлов для Windows с помощью GCC. Среди других вещей MinGW включает порт GCC, порт архиватора и компоновщика GNU и порт отладчика GNU GDB. Он также включает MSYS — среду командной строки, способную выполнять make-файлы GNU и сценарии configure. MSYS будет обсуждаться в рецепте 1.14.

Одно из важных различий между Cygwin и MinGW относится к лицензированию. За некоторыми исключениями вы можете распространять двоичные файлы, скомпилированные с помощью порта MinGW GCC, под любой удобной вам лицензией. С другой стороны, двоичные файлы, собранные с помощью порта Cygwin GCC, по умолчанию подпадают под действие лицензии GNU General Public License (GPL). Если вы хотите распространять программы, скомпилированные в Cygwin, не делая их исходники открытыми, вы должны приобрести лицензию у Red Hat. За полным описанием обратитесь к Web-сайтам Cygwin и MinGW.

Рецепт 1.14.

1.2. Сборка простого приложения «Hello, World» из командной строки

Вы хотите собрать простую программу «Hello, World», подобную приведенной в примере 1.4.

Пример 1.4. Простая программа «Hello, World»

hello.cpp

#include 

int main() {

 std.:cout << "Hello, World!\n";

}

Выполните следующие шаги.

1. Установите все переменные среды окружения, необходимые для вашего инструментария.

2. Введите команду, которая говорит компилятору скомпилировать и скомпоновать вашу программу.

Сценарии для установки переменных среды окружения перечислены в табл 1.5. Эти сценарии расположены в той же директории, что и инструменты командной строки (табл. 1.3), Если ваш инструментарий в табл. 1.5 не указан, пропустите первый шаг. В противном случае, если вы используете Windows, запустите соответствующий сценарий из командной строки, а если используете Unix, то укажите его в качестве источника переменных окружения.

Табл. 1.5. Сценарии для установки переменных среды окружения, необходимые для инструментов командной строки

¹ В предыдущих версиях компилятора Intel этот сценарий назывался iccvars.bat.

² В версиях CodeWarrior до 10.0 имелся единственный сценарий csh с именем mwvars.

Команды для компиляции и компоновки hello.cpp приведены в табл. 1.6. Для корректной работы эти команды требуют, чтобы ваша текущая директория была директорией, содержащей hello.cpp, и чтобы директория, в которой находится компилятор командной строки, была указана в переменной среды

PATH

PATH

PATH

Табл. 1.6. Команды для компиляции и компоновки hello.cpp за один шаг

Табл. 1.7. Добавление директории в переменную среды окружения PATH для одной сессии работы с командной строкой

Например, при использовании Microsoft Visual Studio .NET 2003 и установке ее по стандартному пути на диск С перейдите в директорию, содержащую hello.cpp, и введите показанные ниже команды.

> "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat"

Setting environment for using Microsoft Visual Studio .NET 2003 tools.

(If you have another version of Visual Studio or Visual C++ installed

and wish to use its tools from the command line, run vcvars32.bat for

that version.)

> cl -nologo -EHsn -GR -Zc:forScope -Zc:wchar_t -Fehello hello.cpp hello

hello.cpp

hello

Теперь программу можно запустить.

> hello

Hello World!

Аналогично при использовании Intel 9.0 для Linux и установке его по стандартному пути /opt/intel/cc/9.0 откройте оболочку bash, перейдите в директорию, содержащую hello.cpp, и введите команды:

$ . /opt/intel/cc/9.0/bin/iccvars.sh

$ icpc -о hello hello.cpp

$ ./hello

Hello, World!

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

PATH

PATH

Инструменты командной строки используют переменные среды как в Unix, так и в Windows, но в Unix обычно есть системный компилятор С++, и переменные среды для его работы обычно по умолчанию устанавливаются в правильные значения. Однако в Windows традиционно имелось несколько конкурирующих компиляторов С++. Например, два различных компилятора будут, скорее всего, искать стандартные заголовочные файлы и библиотеки в различных местах. Следовательно, для Windows инструментарий часто предоставляет сценарии, которые устанавливают несколько переменных среды, в которых записано расположение заголовочных файлов и библиотек, а также другая информация.

Один из способов использовать такой сценарий — запускать его из командной строки перед вызовом какого-либо инструмента командной строки, как я продемонстрировал для Visual C++ и для Intel 9.0 для Linux. Также можно сделать установки переменных среды постоянными, с тем чтобы не приходилось каждый раз при запуске сессии командной строки запускать этот сценарий. Как это сделать, зависит от вашей операционной системы и вашей оболочки. Однако изменение постоянных значений переменных среды является плохой идеей, так как некоторые наборы инструментов могут содержать инструменты с одинаковыми именами, что приведет к вызову в процессе сборки неправильного инструмента. Например, если у вас установлено несколько версий Visual С++, вы должны быть уверены, что перед использованием инструментов командной строки вы запустили правильную версию vcvars32.bat. Другим примером является то, что Visual C++ и Digital Mars содержат инструменты с именами link.exe и lib.exe.

Теперь давайте посмотрим на командные строки в табл. 1.7. Помните, что вам требуется обратить внимание только на ту строку, которая соответствует вашему инструментарию. В общем случае информация, передаваемая компилятору, делится на четыре категории.

• Имя (имена) входного (исходного) файла (файлов).

• Имя (имена) выходного файла (файлов).

• Пути поиска файлов.

• Общая конфигурационная информация.

В табл. 1.6 указан только один входной файл hello.cpp, и он передается компилятору с помощью указания его имени в командной строке. Не имеет значения, в каком месте строки находится имя входного файла, при условии, что оно не находится в середине другой опции командной строки. В табл. 1.7 я поместил hello.cpp в самый конец командной строки.

Также в ней присутствует один выходной файл — hello.exe или hello, в зависимости от операционной системы. Однако в этом случае способ передачи имени файла компилятору зависит от инструментария. Большая часть инструментов для указания выходного файла использует -о , но Visual C++ и Intel для Windows используют -Fe, a Borland использует -e. Заметьте, что указывать расширение исполняемого файла не обязательно.

Единственная информация в табл. 1.7, относящаяся к третьей категории — путям поиска файлов, — имеется в строке для Digital Mars. Так как библиотека STLPort не является встроенной стандартной библиотекой Digital Mars, компилятору с помощью опции -I требуется сообщить, где искать заголовочные файлы STLPort. Заголовочные файлы STLPort расположены в поддиректории /stlport/stlport установки Digital Mars. В табл. 1.7 я указал эту директорию с помощью опции /stlport/stlport. За дополнительной информацией об опции -I обратитесь к рецепту 1.5.

Большая часть опций командной строки в табл. 1.7 относится к четвертой категории: общей конфигурационной информации. Эти опции не относятся к какому-либо отдельному файлу, а включают или отключают определенные функции компилятора.

• Опции -nologo (Visual C++ и Intel для Windows) и -q (Borland) говорят компилятору не печатать в консоли свои название и версию. Это делает вывод компилятора более простым для чтения.

• Опции -EHsc (Visual C++ и Intel для Windows) и -Ае (Digital Mars) говорят компилятору включить обработку исключений С++.

• Опции -GR (Visual C++ и Intel для Windows) и -Ar (Digital Mars) говорят компилятору включить информацию времени исполнения (RTTI).

• Опции -Zc:wchar_t (Visual C++ и Intel для Windows) и -wchar_t (Metrowerks) говорят компилятору распознавать

wchar_t

• Опция -Zc:forScope (Visual C++ и Intel для Windows) говорит компилятору задействовать современные правила для областей видимости циклов

for

• Опция -cwd include (Metrowerks) говорит компилятору начинать поиск включенного заголовка с директории исходного файла, содержащего директиву

include

Далее давайте рассмотрим второе решение нашей проблемы. Вместо того чтобы компилировать и компоновать с помощью одной команды, второй шаг можно разбить на две части.

2a. Введите команду, говорящую компилятору скомпилировать программу в объектный файл без компоновки.

2b. Введите команду, говорящую компоновщику создать исполняемый файл из объектных файлов, созданных на шаге 2a.

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

Команды для компиляции и компоновки в два этапа представлены в табл. 1.8 и 1.9. В некоторых случаях я устанавливаю для объектного файла расширение o[bj], указывающее, что одна и та же командная строка годится и для Windows, и для Unix, за исключением расширения объектного файла.

Табл. 1.8. Команды для компиляции hello.cpp без компоновки

Табл. 1.9. Команды для компоновки hello.exe или hello

Например, чтобы собрать исполняемый файл hello с помощью инструментария GCC, перейдите в директорию, содержащую hello.cpp, и введите следующие команды.

$ g++ -с -о hello.о hello.cpp

$ g++ -о hello hello.о

Теперь программу можно запустить вот так.

$ ./hello Hello, World!

Таблица 1.9 почти идентична табл. 1.6. Имеется только два различия. Во-первых, используется опция -с, говорящая компилятору скомпилировать без компоновки. Во-вторых, указанный выходной файл является объектным файлом hello.obj или hello.o, а не исполняемым. Большая часть компиляторов для указания выходного файла использует опцию -о , но Visual C++ и Intel для Windows используют опцию -Fo. Кроме того, все компиляторы, за исключением Visual C++ и Intel для Windows, требуют, чтобы было указано расширение объектного файла.

Теперь все командные строки в табл. 1.9 должны быть просты и понятны, так что я сделаю только два замечания.

• Компоновщик Digital Mars имеет необычный синтаксис, содержащий шесть полей, разделенных запятыми, которые используются для указания различных типов входных файлов. Сейчас вам требуется знать только то, что первое поле предназначено для объектных файлов, а второе — для выходного файла. Опция -noi говорит компоновщику выполнить компоновку с учетом регистра, что необходимо для программ на C++.

• Компоновщик Borland ilink32.exe использует синтаксис, похожий на Digital Mars. Чтобы упростить командную строку, я использовал для выполнения этапа компоновки компилятор bcc32.exe. Внутри себя bcc32.exe вызывает ilink32.exe.

Рецепты 1.7 и 1.15.

1.3. Сборка статической библиотеки из командной строки

Вы хотите использовать свои инструменты командной строки для сборки статической библиотеки из набора исходных файлов С++, таких как перечисленные в примере 1.1.

Во-первых, используйте компилятор для компиляции исходных файлов в объектные файлы. Если ваши исходные файлы включают заголовочные файлы, расположенные в других директориях, то для указания компилятору, где искать эти заголовочные файлы, вам может потребоваться использовать опцию -I. За дополнительной информацией обратитесь к рецепту 1.5. Во-вторых, для объединения объектных файлов в статическую библиотеку используйте архиватор.

Чтобы скомпилировать каждый из трех исходных файлов из примера 1.1, используйте командные строки из табл. 1.8, изменив соответственно имена входного и выходного файлов. Чтобы объединить результирующие объектные файлы в статическую библиотеку, используйте команды, приведенные в табл. 1.10.

Табл. 1.10. Команды для создания архива libjohnpaul.lib или libjohnpaul.а

Например, чтобы скомпилировать john.cpp, paul.cpp и johnpaul.cpp в объектные файлы с помощью GCC, перейдите в директорию johnpaul и введите следующие команды, создающие объектные файлы john.о, paul.о и johnpaul.о:

$ g++ -с -о john.o john.cpp

$ g++ -с -о paul.o paul.cpp

$ g++ -с -о johnpaul.о johnpaul.cp

Теперь скомпонуйте эти объектные файлы в статическую библиотеку следующим образом.

$ ar ru libjohnpaul.a john.o paul.o johnpaul.о

$ ranlib libjohnpaul.а

При использовании GCC в Unix для создания статической библиотеки вы используете две отдельные команды: во-первых, вы вызываете архиватор ar, а затем вызываете инструмент с именем ranlib. Опция ru говорит ar добавить указанные объектные файлы в указанный архив, если в нем отсутствуют члены с такими же именами, а обновить существующий член архива только в том случае, если указанный объектный файл новее, чем существующий член архива. Традиционно после создания или обновления архива использовался инструмент ranlib, который создает или обновляет таблицу символов архива, т.е. указатель символов, которые присутствуют в содержащихся в архиве объектных файлах. Сегодня на многих системах архиватор ar самостоятельно заботится об обновлении таблицы символов, так что запуск ranlib необязателен. В частности, это верно для версии GNU ar. Однако на некоторых системах компилятор GCC может использоваться в сочетании с не-GNU-версией ar, и по этой причине для безопасности лучше запустить ranlib.

Как вы можете видеть в табл. 1.10, архиватор Borland tlib использует несколько необычный синтаксис: знак «плюс» перед объектными файлами говорит tlib добавить объектные файлы в библиотеку. Остальные командные строки должны быть вам понятны без пояснений.

Рецепты 1.8, 1.11 и 1.16.

1.4. Сборка динамической библиотеки из командной строки

Вы хотите использовать свои инструменты командной строки для сборки динамической библиотеки из набора исходных файлов С++, таких как перечисленные в примере 1.2.

Выполните следующие шаги.

1. Используйте компилятор для компиляции исходных файлов в объектные файлы. Если вы используете Windows, то для определения макросов, необходимых для организации экспорта символов динамической библиотеки, используйте опцию -D. Например, чтобы собрать динамическую библиотеку из примера 1.2, вы должны определить макрос

GEORGERINGO_DLL

2. Используйте компоновщик для создания из объектных файлов, созданных на шаге 1, динамической библиотеки.

Основные команды для выполнения первого шага приведены в табл. 1.8 Вы должны соответственно изменить имена входных и выходных файлов. Команды для выполнения второго шага приведены в табл. 1.11. Если вы используете инструментарий, который поставляется как со статическим, так и с динамическим вариантами библиотек времени исполнения, укажите компилятору и компоновщику использовать динамический вариант, как описано в рецепте 1.23.

Табл. 1.11. Команды для создания динамической библиотеки libgeorgeringo.so, libgeorgeringo.dll или libgeorgeringo.dylib

¹ CodeWarrior 10.0 для Mac OS X будет содержать динамический вариант своих библиотек. При сборке libgeorgeringo.dylib следует использовать именно их. (См. рецепт 1.23.)

Например, чтобы скомпилировать исходные файлы из примера 1.2 в объектные файлы с помощью компилятора Borland, предполагая, что директория, в которой находятся инструменты Borland, включена в переменную

PATH

> bcc32 -с -a -WR -о george.obj george.cpp

george.cpp:

> bcc32 -c -q -WR -o ringo.obj ringo.cpp

ringo.cpp:

> bcc32 -c -q -WR -DGERORGERINGO_DLL -o georgeringo.obj georgeringo.cpp

georgeringo.cpp:

Здесь опция компилятора -WR используется для указания того, что применяется динамический вариант рабочей библиотеки. Эти три команды сгенерируют объектные файлы george.obj, ringo.obj и georgeringo.obj. Затем введите команду:

> bcc32 -q -WD -WR -elibgeorgeringo.dll george.obj ringo.obj georgeringo.obj

Она сгенерирует динамическую библиотеку libgeorgeringo.dll. Наконец, введите команду:

> implib -с libgeorgeringo.lib libgeorgeringo.dll

Она сгенерирует библиотеку импорта libgeorgeringo.lib.

То, как обрабатываются динамические библиотеки, в основном зависит от операционной системы и инструментария. С точки зрения программиста, два наиболее значительных отличия — это:

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

В случае с большинством инструментариев для Windows, чтобы символ, определенный в динамической библиотеке, был доступен коду, использующему эту библиотеку, он должен быть явно экспортирован при сборке динамической библиотеки и импортирован при сборке исполняемого файла или другой динамической библиотеки, использующей эту библиотеку. Некоторые инструменты для Unix также предлагают такие возможности. Это верно для последних версий GCC для некоторых платформ, для Metrowerks на Mac OS X и для Intel для Linux. Однако в некоторых случаях нет никакого выбора, кроме как сделать все символы видимыми.

В Unix динамическая библиотека может быть указана как входной файл компоновщика при компоновке кода, использующего эту динамическую библиотеку. В Windows, кроме случаев использования GCC, динамические библиотеки не указываются напрямую как вход компоновщика, а вместо этого используется библиотека импорта или файл определения модуля.

Библиотеки импорта, грубо говоря, являются статическими библиотеками, содержащими информацию, необходимую для вызова функций, содержащихся в DLL, во время исполнения. Нет необходимости знать, как они работают, надо только знать, как их создавать и использовать. Большинство компоновщиков создает библиотеки импорта автоматически при сборке DLL, но в некоторых случаях может оказаться необходимо использовать отдельный инструмент, который называется библиотекарь импорта (import librarian). В табл. 1.11 с целью избежать запутанного синтаксиса командной строки, требуемого компоновщиком Borland ilink32.exe, я использовал библиотекарь импорта Borland implib.exe.

Файл определения модуля, или файл .def — это текстовый файл, который описывает функции и данные, экспортируемые из DLL. Файл .def может быть написан вручную или автоматически сгенерирован каким-либо инструментом. Пример файла .def для библиотеки libgeorgeringo.dll показан в примере 1.5.

Пример 1.5. Файл определения модуля для libgeorgeringo.dll

LIBRARY LIBGEORGERINGO.DLL

EXPORTS

 Georgeringo @1

Имеется два стандартных метода экспорта символов из Windows DLL.

• Использование атрибута

__declspec(dllexport)

Атрибут

__dеclspec(dllexport)

class

struct

__declspec(dllexport)

• Создание файла .def, описывающего функции и данные, экспортируемые из динамической библиотеки.

Пример 1.6. Использование атрибута __declspec(dllexport)

__declspec(dllexport) int m = 3; // Экспортируемое определение данных

extern __declspec(dllexport) int n; // Экспортируемое объявление данных

__declspec(dllexport) void f(); // Экспортируемое объявление функции class

__declspec(dllexport) c { // Экспортируемое определение класса

 /* ... */

};

Использование файла .def имеет несколько преимуществ — например, он может позволить осуществлять доступ к функциям в DLL по номеру, а не по имени, что сокращает размер DLL. Он также устраняет необходимость запутанных директив препроцессора, таких как показанные в примере 1.2 в заголовочном файле georgeringo.hpp. Однако он также имеет и несколько серьезных недостатков. Например, файл .def не может использоваться для экспорта классов. Более того, можно забыть обновить свой файл .def при добавлении, удалении или изменении функций в вашей DLL. Таким образом, я рекомендую вам всегда использовать

__declspec(dllexport)

Как есть два способа экспорта символов из DLL, так есть и два способа импорта символов.

• В заголовочных файлах, включенных в исходный код, использующий DLL, используйте атрибут

__declspec(dllimport)

• При сборке кода, использующего DLL, укажите файл .def.

Как и в случае с экспортом символов, я рекомендую вместо файлов .def использовать в вашем исходном коде атрибут

__declspec(dllimport)

__declspec(dllimport)

__declspec(dllexport)

__declspec(dllexport)

__declspec(dllimport)

Если вы выбрали использование

__declspec(dllexport)

__declspec(dllimport)

__declspec(dllexport)

__declspec(dllimport)

Вместо этого обычно используют определение макроса, который при сборке DLL расширяется как

__declspec(dllexport)

__declspec(dllimport)

GEORGERINGO_DECL

GEORGERINGO_SOURCE

GEORGERINGO_DECL

__declspec(dllexport)

__declspec(dllimport)

GEORGERINGO_SOURCE

Порты GCC Cygwin и MinGW, обсуждавшиеся в рецепте 1.1, работают с DLL по-другому, нежели остальные инструменты для Windows. При сборке DLL с помощью GCC по умолчанию экспортируются все функции, классы и данные. Это поведение можно изменить, использовав опцию компоновщика --no-export-all-symbols, применив в исходных файлах атрибут

__declspec(dllexport)

__declspec(dllexport)

Таким образом, инструментарий GCC можно использовать для сборки DLL двумя способами: как обычный инструментарий Windows, экспортирующий символы явно с помощью

__declspec

__declspec(dllexport)

GCC отличается от других инструментов для Windows и еще в одном: вместо того чтобы передавать компоновщику библиотеку импорта, связанную с DLL, вы можете передать саму DLL. Это обычно быстрее, чем использование библиотеки импорта. Однако это может привести к проблемам, так как в одной и той же системе может существовать несколько версий одной DLL, и вы должны быть уверены, что компоновщик выберет правильную версию. В табл. 1.11 при демонстрации того, как создавать библиотеки импорта с помощью GCC, я решил не использовать эту возможность.

Последние версии GCC на некоторых платформах, включая Linux и Mac OS X, дают программистам возможность более тонкого управления экспортом символов из динамических библиотек: опция командной строки -fvisibility используется для указания видимости символов динамической библиотеки по умолчанию, а специальный атрибут, аналогичный

__declspec(dllexport)

-fvisibility

Пример 1.7. Использование атрибута visibility с опцией командной строки -fvisibility=hidden

extern __attribute__((visibility("default"))) int m; // экспортируется

extern int n; // не экспортируется

__attribute__((visibility("default"))) void f(); // экспортируется

void g(); // не экспортируется

struct __attribute__((visibility("default"))) S { }; // экспортируется

struct T { }; //не экспортируется

В примере 1.7 атрибут

__attribute__((visibility("default")))

__declspec(dllexport)

Использование атрибута

visibility

__declspec(dllexport)

__declspec(dllimport)

__declspec(dllexport)

__declspec(dllimport)

georgeringo/georgeringo.hpp

#ifndef GEORGERINGO_HPP_INCLUDED

#define GEORGERINGO_HPP_INCLUDED

// определите GEORGERINGO_DLL при сборке libgeorgeringo

#if defined(_WIN32) && !defined(__GNUC__)

#ifdef GEORGERINGO_DLL

#define GEORGERINGO_DECL __declspec(dllexport)

#else

#define GEORGERINGO_DECL __declspec(dllimport)

#endif

#else // Unix

# if defined(GEORGERINGO_DLL) && defined(HAS_GCC_VISIBILITY)

# define GEORGERINGO_DECL __attribute__((visibility("default")))

# else

#define GEORGERINGO_DECL

#endif

# endif

// Печатает "George, and Ringo\n"

GEORGERINGO_DECL void georgeringo();

#endif // GEORGERINGO_HPP_INCLUDED

Чтобы заставить это работать, вы должны при сборке в системах, поддерживающих опцию -fvisibility, определить макрос

HAS_GCC_VISIBILITY

Metrowerks для Mac OS X предоставляет несколько опций для экспорта символов из динамической библиотеки. При использовании IDE CodeWarrior вы можете использовать файл экспорта символов, который играет роль файла .def в Windows. Вы также можете экспортировать все символы с помощью опции -export all, что при сборке из командной строки является поведением по умолчанию. Я рекомендую метод, использующий для пометки в вашем исходном коде экспортируемых функций

#pragma export

#pragma export

#pragma export on

#pragma export off

#pragma export

#ifdef

#endif

Давайте кратко посмотрим на опции, использованные в табл. 1.11. Каждая строка команды определяет:

• имя (имена) входного файла (файлов): george.obj, ringo.obj и georgeringo.obj;

• имя создаваемой динамической библиотеки;

• в Windows имя библиотеки импорта.

Кроме того, компоновщик требует опции, которая говорит ему создать динамическую библиотеку, а не исполняемый файл. Большинство компоновщиков используют опцию -shared, но Visual C++ и Intel для Windows используют -dll, Borland и Digital Mars используют -WD, a GCC для Mac OS X использует -dynamiclib.

Несколько опций в табл. 1.11 способствуют более эффективному использованию динамических библиотек во время выполнения. Например, некоторым компоновщикам для Unix требуется с помощью опции -fPIC сгенерировать независимый от положения код (position- independent code) (GCC и Intel для Linux). Эта опция приводит к тому, что несколько процессов смогут использовать единственную копию кода динамической библиотеки. На некоторых системах отсутствие этой опции приведет к ошибке компоновщика. Аналогично в Windows опция компоновщика GCC --enable-auto-image-base снижает вероятность того, что операционная система попытается загрузить две динамические библиотеки в одно и то же место. Использование этой опции помогает ускорить загрузку DLL.

Большая часть других опций используется для указания вариантов рабочей библиотеки и описывается в рецепте 1.23.

Рецепты 1.9, 1.12, 1.17, 1.19 и 1.23.

1.5. Сборка сложного приложения из командной строки

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

Начните со сборки статических и динамических библиотек, от которых зависит ваше приложение. Если библиотеки получены от сторонних разработчиков, следуйте инструкциям, поставляемым с этими библиотеками; в противном случае соберите их так, как описано в рецептах 1.3 и 1.4.

Затем скомпилируйте в объектные файлы .cpp-файлы своего приложения, как описано в разделе «Сборка простой программы «Hello, World» из командной строки». Чтобы сказать компилятору, где искать заголовочные файлы, требуемые для вашего приложения, используйте опцию -I, как показано в табл. 1.12.

Табл. 1.12. Указание директорий для поиска заголовочных файлов

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

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

Таблица 1.13 предоставляет команды для компоновки приложения hellobeatles из примера 1.3. Она предполагает, что:

• текущей директорией является hellobeatles;

• статическая библиотека libjohnpaul.lib или libjohnpaul.а была создана в директории johnpaul;

• динамическая библиотека georgeringo.dll, georgeringo.so или georgeringo.dylib и, если есть, ее библиотека импорта были созданы в директории georgeringo.

georgeringo()

GEORGERINGO_DECL

Табл. 1.13. Команды для компоновки приложения hellobeatles.exe

¹ При сборке с помощью указанной командной строки hellobeatles может работать неправильно, так как это приложение будет использовать две копии рабочих библиотек Metrowerks. (См. рецепт 1.23.)

² CodeWarrior 10.0 для Mac OS X будет содержать динамический вариант своих библиотек. При сборке hellobeatles следует использовать именно их. (См. рецепт 1.23.)

Например, при использовании Microsoft Visual Studio .NET 2003 и если она установлена в стандартную директорию на диске С, чтобы собрать hellobeatles.exe из командной строки, перейдите в директорию hellobeatles и введите следующие команды.

> "С:Program Files\Microsoft Visual Studio .NET 2003\VC\bin\vcvars32.bat"

Setting environment for using Microsoft Visual Studio 2005 tools.

(IF you have another version of Visual Studio or Visual C++ installed

and wish to use its tools from the command line, run vcvars32.bat for

that version.)

> cl -c -nologo -EHsc -GR -Zc:forScope -Zc:wchar_t -MD -I.. -Fohollobeatles hellobeatles.cpp

hellobeatles.cpp

> link -nologo -out:hellobeatles.exe -libpath:../johnpaul -libpath:../georgeringo libjohnpaul.lib libgeorgeringo.lib

> hellobeatles.obj

Опция -I используется для указания пути, где находятся заголовочные файлы. Когда компилятор — а на самом деле препроцессор — встречает директиву

include

#include "file"

он обычно пытается вначале найти подключаемый файл, интерпретируя указанный путь относительно директории, в которой находится обрабатываемый исходный файл. Если этот поиск не дает результатов, он пытается найти этот файл в одной из директорий, указанных в опции -I, а затем в директориях, указанных в инструментарии, который часто настраивается с помощью переменных среды.

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

#include 

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

Есть несколько интересных аспектов, связанных с командными строками из табл. 1.13.

В Windows вход компоновщика состоит из объектных файлов, статических библиотек и библиотек импорта. В Unix он состоит из объектных файлов, статических и динамических библиотек.

Как в Windows, так и в Unix библиотеки могут передаваться компоновщику двумя способами:

• с помощью указания пути в командной строке;

• с помощью указания только имени библиотеки и места поиска библиотек.

Таблица 1.13 иллюстрирует оба метода.

Места поиска библиотек обычно могут быть указаны в командной строке. Большинство компоновщиков для этой цели используют опцию -L, но Visual C++ и Intel для Windows используют опцию -lipath: , a Metrowerks использует опцию -search -L. Компоновщик Digital Mars позволяет указывать пути поиска библиотек в командной строке вместе с файлами библиотек, при условии, что пути поиска отличаются от файлов библиотек завершающей обратной косой чертой. Также он требует, чтобы эти обратные слеши использовались как разделители в путях.

Кроме явно указанных директорий компоновщики обычно используют список собственных директорий, который часто может быть настроен с помощью переменных среды. В Windows список директорий обычно включает lib-поддиректорию пути установки инструментария. В результате, если скопировать .lib-файлы в эту директорию, их можно будет указать в командной строке по имени, не указывая их местоположения. Если объединить этот метод с действиями, описанными в рецепте 1.25, то можно вообще избежать передачи компоновщику какой-либо информации о библиотеке.

Способ, которым имя библиотеки передается компоновщику, для Unix и Windows различается. В Windows указывается полный путь библиотеки, включая расширение файла. В Unix — и в Windows при использовании инструментария GCC — библиотеки указываются с помощью опции -l, за которой следует имя библиотеки с удаленными из него расширением файла и префиксом lib. Это означает, что для того, чтобы компоновщик автоматически находил библиотеку, ее имя должно начинаться с префикса lib. Еще интереснее то, что это дает компоновщику возможность выбрать между несколькими версиями библиотек. Если компоновщик находит как статическую, так и динамическую версии библиотеки, выбирается, если не указано другого, динамическая библиотека. На некоторых системах компоновщик может выбрать между несколькими версиями динамической библиотеки, используя часть имени файла, за которой следует .so.

Наконец, будьте осторожны, так как компоновщики Unix могут быть очень чувствительны к порядку, в котором в командной строке указаны объектные файлы и статические библиотеки: если статическая библиотека или объектный файл ссылаются на символ, определенный во второй статической библиотеке или объектном файле, первый файл должен быть указан в командной строке до второго. Чтобы разрешить круговые зависимости, иногда требуется указать библиотеку или объектный файл несколько раз. Еще одним решением является передача последовательности из объектных файлов и статических библиотек компоновщику обрамленными в -( и -). Это приведет к тому, что поиск в файле будет производиться до тех пор, пока не будут разрешены все зависимости. Этой опции по возможности следует избегать, так как она значительно снижает производительность.

Если ваше приложение использует динамический вариант библиотеки времени исполнения инструментария, то эта библиотека должна быть доступна приложению при его запуске и должна находиться в таком месте, где динамический загрузчик операционной системы сможет автоматически найти ее. Обычно это означает, что динамическая библиотека времени исполнения должна находиться либо в той же директории, что и ваше приложение, либо в одной из директорий, указанных системе. Это больше относится к разработке для Windows, чем для Unix, так как в Unix соответствующие библиотеки обычно уже установлены по правильным путям. Имена динамических библиотек времени исполнения, поставляемых с различным инструментарием, приведены в рецепте 1.23.

Рецепты 1.10, 1.13, 1.18 и 1.23.

1.6. Установка Boost.Build

Вы хотите получить и установить Boost.Build.

Обратитесь к документации Boost.Build по адресу www.boost.org/boost-build2 или выполните эти шаги.

1. Перейдите на домашнюю страницу Boost — www.boost.org и проследуйте по ссылке Download (скачать) на страницу SourceForge Boost.

2. Скачайте и распакуйте либо самый последний релиз пакета boost, либо самый последний релиз пакета boost-build. Первый включает полный набор библиотек Boost, а второй — это отдельный релиз Boost.Build. Распакованные файлы поместите в подходящую временную директорию.

3. Скачайте и распакуйте последнюю версию пакета boost-jam для вашей платформы. Этот пакет включает собранный исполняемый файл bjam. Если пакет boost-jam для вашей платформы недоступен, то для сборки исполняемого файла из исходников следуйте инструкциям, прилагаемым к пакету, скачанному вами на шаге 2.

4. Скопируйте bjam в директорию, указанную в переменной среды

PATH

5. Установите переменную среды

BOOST_BUILD_PATH

6. Настройте BoostBuild на ваш инструментарий и библиотеки, отредактировав файл user-config.jam, расположенный в корневой директории Boost.Build. Файл user-config.jam содержит комментарии, поясняющие, как это сделать.

Наиболее сложной частью использования Boost.Build является его скачивание и установка. Со временем Boost может предоставить графическую программу установки, но в настоящий момент вы должны следовать приведенным выше шагам.

Целью пятого шага является помощь инструменту сборки — bjam в поиске корневой директории системы сборки. Однако этот шаг необязателен, так как есть другой способ выполнить эту же задачу: просто создайте файл, который называется boost-build.jam, с единственной строкой:

boost-build boost-build-root ;

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

Шестой шаг, вероятно, является наиболее сложным, но на практике он обычно довольно прост. Если у вас установлена только одна версия инструментария, и она установлена в стандартном месте, то файл user-config.jam может содержать всего одну строку вида:

using  ;

Например, при использовании Visual C++ будет достаточно следующего:

using msvc ;

А при использовании GCC просто напишите:

using gcc ;

Дела становятся несколько более сложными при использовании нескольких версий инструментария или при установке инструментария не по стандартному пути. Если ваш инструментарий установлен в нестандартную директорию, скажите Boost.Build, где искать его, передав ему в качестве третьего аргумента

using

using msvc : : "С:/Tools/Compilers/Visual Studio/Vc7/bin/cl" ;

Если у вас установлено несколько версий инструментария, вы можете указать правило

using

using intel : 7.1 : "C:/Program Files/Intel/Compiler70/IA32/Bin/icl" ;

using intel : 8.0 : "C./Program Files/Intel/CPP/Compiler80/IA32/Bin/icl" ;

Имена, используемые Boost.Build для нескольких разных инструментариев, описываемых в этой главе, приведены в табл 1.14.

Табл. 1.14. Имена инструментариев Boost.Build

1.7. Сборка простого приложения «Hello, World» с помощью Boost.Build

Вы хотите собрать простую программу «Hello, World», подобную приведенной в примере 1.4, с помощью BoostBuild.

В директории, где вы хотите создать исполняемый файл и все создаваемые при этом промежуточные файлы, создайте текстовый файл с именем Jamroot. В файле Jamroot укажите два правила, приведенных далее. Во-первых, укажите правило exe, объявляющее целевой исполняемый файл и исходные файлы .cpp. Далее укажите правило

install

Например, чтобы собрать исполняемый файл hello или hello.exe из файла hello.cpp из примера 1.4, создайте в директории, содержащей файл hello.cpp, файл с именем Jamroot с содержимым, показанным в примере 1.8.

Пример 1.8. Jamfile для проекта hello

# jamfile для проекта hello

exe hello : hello.cpp ;

install dist : hello : . ;

Далее перейдите в директорию, содержащую hello.cpp и Jamroot, и введите следующую команду.

> bjam hello

Эта команда собирает исполняемый файл hello или hello.exe в поддиректории текущей директории. Наконец, введите команду:

> bjam dist

Эта команда копирует исполняемый файл в директорию, указанную в свойстве

location

bjam hello

bjam --v2 hello

Файл Jamroot является примером файла Jamfile. В то время как для управления небольшим набором исходных файлов C++ можно использовать один Jam-файл, большой набор файлов обычно требует нескольких Jam-файлов с иерархической организацией. Каждый Jam-файл находится в отдельной директории и соответствует отдельному проекту. Большая часть Jam-файлов просто называется Jamfile, но самый верхний Jam-файл — Jam-файл, который расположен в директории, родительской по отношению ко всем другим директориям, содержащим остальные Jam-файлы, — называется Jamroot. Проект, определяемый этим верхним Jam- файлом, называется корнем проекта. Каждый проект, за исключением корня проекта, имеет родительский проект определяемый проектом, расположенным в ближайшей к нему родительской директории, содержащей Jam-файл.

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

Каждый проект — это набор целей. Цели объявляются с помощью вызова правил, таких как правило

exe

install

Правило

exe

Пример 1.9. Вызов правила exe

exe имя-целевого-файла

 : исходные-файлы

 : требования

 : сборка-по-умолчанию

 : требования-к-использованию

 ;

Здесь

имя-целевого-файла

исходные-файлы

сборка-по-умолчанию

требования-к-использованию

Свойства указываются в виде

<функция>значение

exe hello

 : hello.cpp

 : multi

 ;

Некоторые часто используемые функции и их возможные значения перечислены в табл. 1.15.

Табл. 1.15. Часто используемые функции Boost.Build

multi

single

static

shared

debug

release

¹ См. рецепт 1.23.

Когда собирается целевой исполняемый файл, или цель, соответствующая статической или динамической библиотеке, файл, соответствующий этой цели, создается в директории, дочерней по отношению к директории, содержащей Jam-файл. Относительным путь этой директории зависит от инструментария и конфигурации сборки, но он всегда начинается с bin. Например, исполняемый файл из примера 1.8 может быть создан в директории bin/msvc/debug.

Для простоты я попросил вас создать Jam-файл из примера 1.8 в той же директории, в которой находится исходный файл hello.cpp. Однако в реальных проектах вам часто придется хранить исходные и двоичные файлы в различных директориях. В примере 1.8 Jam-файл можно поместить в любое место при условии, что вы укажете путь hello.cpp так, что он будет указывать на реальный файл hello.cpp.

Правило

install

Пример 1.10. Вызов правила install

install имя-цели

 : файлы

 : требования

 : сборка-по-умолчанию

 : требования-к-использованию

 ;

Здесь

имя-цели

файлы

требования

сборка-по-умолчанию

требования-к-использованию

Место, куда файлы должны быть скопированы, может указываться либо как имя цели, либо как значение свойства

location

install

install . : hello ;

Затем установка исполняемого файла выполняется так:

> bjam .

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

Наконец, давайте быстро взглянем на синтаксис командной строки bjam. Чтобы собрать цель

xxx

> bjam xxx

Чтобы собрать цель

xxx

yyy

> bjam xxx toolset=yyy

Чтобы собрать цель

xxx

vvv

yyy

> bjam хххtoolset=yyy-vvv

Чтобы в командной строке указать использовать при сборке стандартную библиотеку

zzz

> bjam xxx stdlib=zzz

Чтобы собрать несколько целей одновременно, введите в командной строке несколько имен целей, а чтобы собрать все цели данного проекта, не указывайте целей. Следовательно, чтобы собрать и установить исполняемый файл из примера 1.9, просто введите:

> bjam

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

> bjam --clean

Свойство в виде

<функция>значение

функция=значение

Рецепты 1.2 и 1.15.

1.8. Сборка статической библиотеки с помощью Boost.Build

Вы хотите использовать Boost.Build для сборки статической библиотеки из набора исходных файлов С++, таких как перечисленные в примере 1.1.

В директории, где вы хотите создать статическую библиотеку, создайте файл Jamroot. В файле Jamroot вызовите правило

lib

static

include

путь

путь

Например, чтобы собрать статическую библиотеку из исходных файлов, перечисленных в примере 1.1, ваш Jamroot может выглядеть как в примере 1.11.

Пример 1.11. Jam файл для сборки статической библиотеки libjohnpaul.lib или libjohnpaul.a

# Jamfile для проекта libjohnpaul

lib libjohnpaul

: # исходники

john.cpp paul.cpp johnpaul.cpp

: # требования

static

: # сборка-по-умолчанию

: # требования-к-использованию

..

;

Чтобы собрать библиотеку, введите:

> bjam libjohnpaul

Правило

lib

..

static

static

static

libjohnpaul

> bjam libjohnpaul link=static

Однако написание исходного кода для библиотеки, которая может быть собрана и как статическая, и как динамическая, является нетривиальной задачей, что показано в рецепте 1.9.

Рецепты 1.3, 1.11 и 1.16.

1.9. Сборка динамической библиотеки с помощью Boost.Build

Вы хотите использовать Boost.Build для сборки динамической библиотеки из набора исходных файлов С++, таких как перечисленные в примере 1.2.

В директории, где вы хотите создать динамическую библиотеку и, если надо, библиотеку импорта, создайте файл Jamroot. В файле Jamroot вызовите правило

lib

shared

include

путь

путь

__declspec(dllexport)

символ

Например, чтобы собрать из исходных файлов, перечисленных в примере 1.2, динамическую библиотеку, создайте в директории georgeringo файл с именем Jamroot, показанный в примере 1.12.

Пример 1.12. Jam-файл для сборки динамической библиотеки georgeringo.so, georgeringo.dll или georgeringo.dylib

# Jamfile для проекта georgeringo

lib libgeorgeringo

 : # исходники

  george.cpp ringo.cpp georgeringo.cpp

 : # требования

  shared

  GEORGERINGO_DLL

 : # сборка-по-умолчанию

 : # требования-к-использованию

  ..

 ;

Чтобы собрать библиотеку, введите:

> bjam libgeorgeringo

Как обсуждалось в рецепте 1.8, правило

lib

..

shared

shared

Рецепты 1.4, 1.12, 1.17 и 1.19.

1.10. Сборка сложного приложения с помощью BoostBuild

Вы хотите использовать Boost.Build для сборки исполняемого файла, зависящего от нескольких статических и динамических библиотек.

Выполните следующие шаги.

1. Для каждой библиотеки, от которой зависит исполняемый файл, — при условии, что она не распространяется в виде готового бинарного файла, — создайте Jam-файл, как описано в рецептах 1.8 и 1.9.

2. В директории, где вы хотите создать исполняемый файл, создайте файл Jamroot.

3. В файле Jamroot вызовите правило exe, объявляющее целевой исполняемый файл. Укажите свои файлы .cpp и цели библиотек, от которых исполняемый файл зависит как от источников. Также, если требуется, добавьте свойства вида

путь

4. В файле Jamroot вызовите правило

install

on

EXE

SHARED_LIB

5. В директории, содержащей Jamroot, запустите bjam, как описано в рецепте 1.7.

6. Например, чтобы собрать из исходных файлов, перечисленных в примере 1.3, исполняемый файл, создайте в директории hellobeatles файл с именем Jamroot, показанный в примере 1.13.

Пример 1.13. Jam-файл для сборки исполняемого файла hellobeatles.exe или hellobeatles

# Jamfile для проекта hellobeatles

exe hellobeatles

 : # исходники

 ../johnpaul//libjohnpaul

 ../georgeringo//libgeorgeringo

 hellobeatles.cpp

 ;

install dist

 : # исходники

  hellobeatles

 : # требования

  on

  EXE

  SHARED_LIB

  .

 ;

Теперь введите:

> bjam hellobeatles

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

hellobeatles

> bjam dist

В результате исполняемый файл hellobeatles и динамическая библиотека georgeringo будут скопированы в директорию, содержащую файл hellobeatles.cpp.

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

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

path//target-name

lib имя-цели

 :

 : имя-файла

 ;

Как объяснялось в рецепте 1.7, большая часть основных целей соответствует не одному файлу, а набору связанных файлов, таких как отладочная и окончательная сборка исполняемого файла. Чтобы объявить цель для готовой библиотеки, у которой есть несколько вариантов, используйте следующую запись.

lib имя цели

 :

 : имя-файла требования

 ;

lib имя-цели

 : другое-имя-файла другие-требования

 ;

Например, отладочный и окончательный варианты готовой библиотеки могут быть объявлены следующим образом.

lib cryptolib

 :

 :  ../libraries/cryptolib/cryptolib_debug.lib

  debug

 ;

 lib cryptolib

 :  ../libraries/cryptolib/cryptolib.lib

  release

 ;

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

lib имя-цели

 : имя-библиотеки

 ;

Здесь

имя-библиотеки

lib имя-цели

 : имя-библиотеки

 путь-к-библиотеке

 ;

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

install-dependencies

on

install-dependencies

EXE

SHARED_LIB

install-type

LIB

IMPORT_LIB

Все три Jam-файла, используемые при сборке исполняемого файла hellobeatles, называются Jamroot. Это хорошо для такого простого проекта, но обычно следует организовывать набор Jam-файлов в иерархию с единственным высшим Jam-файлом, определяющим корень проекта. Организация проектов подобным образом позволяет использовать некоторые из более сложных функций Boost.Build's, таких как наследование свойств дочерними проектами. Одним из способов сделать такую организацию в нашем случае является изменение имен Jam-файлов в директориях johnpaul, georgeringo и hellobeatles с Jamroot на Jamfile и добавление файла Jamroot со следующим содержимым в родительскую директорию.

# jamfile для примера приложения

build-project hellobeatles ;

Правило

build-project

Рецепты 1.5, 1.13 и 1.18.

1.11. Сборка статической библиотеки с помощью IDE

Вы хотите использовать IDE для сборки статической библиотеки из набора исходных файлов С++, таких как перечисленные в примере 1.1.

Основная процедура выглядит следующим образом.

1. Создайте новый проект и укажите, что требуется собрать статическую библиотеку, а не исполняемый файл или динамическую библиотеку.

2. Выберите конфигурацию сборки (т. е. отладочную или окончательную версию и поддержку или отсутствие поддержки многопоточности).

3. Укажите имя библиотеки и директорию, в которой она должна быть создана.

4. Добавьте в проект исходные файлы.

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

6. Соберите проект.

Шаги этой процедуры могут варьироваться в зависимости от IDE — например, для некоторых IDE некоторые шаги будут объединены в один или изменится их порядок. Второй шаг подробно описывается в рецептах 1.21, 1.22 и 1.23. А сейчас вы. насколько это возможно, должны использовать параметры по умолчанию.

Например, вот как надо собирать статическую библиотеку из исходных файлов из примера 1.1 с помощью Visual C++ IDE.

В меню File выберите New→Project, в левой панели выберите Visual С++[2], выберите Win32 Console Application и введите в качестве имени проекта libjohnpaul. В мастере Win32 Application Wizard перейдите в раздел Application Settings (Параметры приложения), выберите Static library, отключите опцию Precompiled header (Прекомпилированные заголовочные файлы) и нажмите на Finish (Готово). Теперь у вас должен иметься пустой проект с двумя конфигурациями сборки — Debug и Release, и первая будет активной.

Затем, сделав щелчок правой кнопкой мыши на Solution Explorer и выбрав Properties, отобразите страницы свойств проекта. Перейдите в раздел Configuration Properties (Свойства конфигурации)→Librarian (Библиотекарь)→General (Общие) и в поле с именем Output File (Выходной файл) введите имя и путь выходного файла проекта. Директория этого пути должна указывать на директорию binaries, созданную в начале этой главы, а имя должно быть libjohnpaul.lib.

Наконец, чтобы добавить в проект исходные файлы из примера 1.1, используйте Add Existing Item (добавить существующий элемент) из меню Project. Теперь страницы свойств проекта должны содержать узел с именем «C/C++». Перейдите к Configuration Properties→C/C++→Code Generation (Генерация кода) и укажите в качестве библиотеки времени выполнения Multi-threaded Debug DLL (многопоточная отладочная динамическая библиотека). Теперь можно собрать проект, выбрав в меню Build пункт Build Solution. Проверьте, что в директории binaries был создан файл с именем libjohnpaul.lib.

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

При изучении того, как использовать новую IDE, вам следует обратить особое внимание на следующие моменты.

• Как создать новый проект.

• Как указать тип проекта (исполняемый файл, статическая библиотека или динамическая библиотека).

• Как добавить в проект существующий файл.

• Как создать и добавить в проект новый файл.

• Как указать имя выходного файла проекта.

• Как указать пути для включаемых заголовков.

• Как указать пути для поиска библиотек.

• Как указать библиотеки, от которых зависит проект.

• Как собрать проект.

• Как организовать набор проектов в группу и указать их зависимости.

Этот рецепт демонстрирует многие из этих функций. Большая часть других функций описывается в рецептах 1.12 и 1.13.

Теперь давайте посмотрим на то, как собрать статическую библиотеку с помощью CodeWarrior, C++Builder и Dev-C++.

В меню File выберите New… и в диалоге New выберите вкладку Project. В качестве имени проекта введите

libjohnpaul.mcp

Так как при создании проекта, зависящего от этого проекта, вам придется ссылаться на эти цели по их имени, им следует дать понятные имена. Сейчас переименуйте только отладочную цель. Выберите вкладку Targets окна проекта и дважды щелкните мышью на имени отладочной цели, чтобы: отобразить окно Target Settings (Параметры цели). Затем перейдите к Target→Target Settings и в первом поле Target Name (Имя цели) введите

libjohnpaul Debug

Далее в окне Target Settings перейдите к Target→PPC Mac OS X Target. В качестве Project Туре (Тип проекта) укажите Library, а в поле с именем File Name (Имя файла) введите

libjohnpaul.а

Наконец выберите вкладку files окна проекта и удалите существующие исходные файлы и файлы библиотек, перетащив их в Trash (корзину). Затем, чтобы добавить в проект исходные файлы из примера 1.1, используйте Add Files (Добавить файлы) из меню Project. Теперь можно собрать проект, выбрав в меню Project пункт Make. Проверьте, что в директории binaries был создан файл с именем libjohnpaul.a.

В меню File выберите New→Other и выберите Library. Теперь у вас должен иметься пустой проект. В меню File выберите Save Project As, выберите директорию для сохранения настроечных файлов проекта и в качестве имени проекта введите libjohnpaul.bpr.

Затем, чтобы отобразить диалог Project Options (Параметры проекта), в меню Project выберите Options. Затем перейдите в Directories and Conditionals (Директории и условия) и используйте элемент управления рядом с надписью Final output (Окончательный вывод), чтобы указать, где должен создаваться выходной файл libjohnpaul.lib. По умолчанию этот файл будет создан в той же директории, где находится libjohnpaul.bpr, но вы должны сказать C++Builder, что его требуется создать в директории binaries. Если хотите, то также можно использовать элемент управления рядом с Intermediate output (Промежуточный вывод) и указать место создания объектных файлов. По умолчанию они создаются в той же директории, где находятся исходные файлы.

Наконец, чтобы добавить в проект исходные файлы из примера 1.1, используйте Add to Project (Добавить в проект) из меню Project. Теперь можно собрать проект, выбрав в меню Project пункт Make libjohnpaul. Проверьте, что в директории binaries был создан файл с именем libjohnpaul.lib.

В меню File выберите New→Project. В диалоге New project (Новый проект) выберите Static Library и C++ Project и в качестве имени проекта введите libjohnpaul. После нажатия на OK укажите место для сохранения настроечных файлов проекта.

Затем, чтобы отобразить диалог Project Options, в меню Project выберите Project Options. Затем перейдите к Build Options и проверьте, что в качестве имени выходного файла проекта указано libjohnpaul.a. В поле Executable output directory (Директория для записи исполняемого файла) введите путь к директории binaries. Если хотите, то в поле Object File output directory (Директория для записи объектных файлов) можно указать директорию для создания объектных файлов.

Наконец, чтобы добавить в проект исходные файлы из примера 1.1, используйте Add to project (Добавить в проект) из меню Project. Теперь можно собрать проект, выбрав в меню Execute пункт Compile. Проверьте, что в директории binaries был создан файл с именем libjohnpaul.a.

Рецепты 1.3, 1.8 и 1.16.

1.12. Сборка динамической библиотеки с помощью IDE

Вы хотите использовать IDE для сборки динамической библиотеки из набора исходных файлов С++, таких как перечисленные в примере 1.2.

Основная процедура выглядит следующим образом.

1. Создайте новый проект и укажите, что требуется собрать динамическую библиотеку, а не исполняемый файл или статическую библиотеку.

2. Выберите конфигурацию сборки (т. е. отладочную или окончательную версию и поддержку или отсутствие поддержки многопоточности).

3. Укажите имя библиотеки и директорию, в которой она должна быть создана.

4. Добавьте в проект исходные файлы.

5. В Windows определите макросы, необходимые для организации экспорта символов динамической библиотеки с помощью

__declspec(dllexport)

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

7. Соберите проект.

Как и в рецепте 1.11, шаги в этой процедуре будут различаться в зависимости от IDE. Второй шаг подробно описывается в рецептах 1.21, 1.22 и 1.23. А сейчас вы, насколько это возможно, должны использовать параметры по умолчанию.

Например, вот как надо собирать динамическую библиотеку из исходных файлов из примера 1.2 с помощью Visual C++ IDE.

В меню File выберите New→Project, в левой панели выберите Visual С++[3], выберите Win32 Console Application и в качестве имени проекта введите libgeorgeringo. В мастере Win32 Application Wizard перейдите к Application Settings, выберите DLL и Empty Project (Пустой проект) и нажмите на Finish. Теперь у вас должен иметься пустой проект с двумя конфигурациями сборки — Debug и Release, и первая будет активной.

Затем, сделав щелчок правой кнопкой мыши на Solution Explorer и выбрав Properties, отобразите страницы свойств проекта. Перейдите в раздел Configuration Properties (Свойства конфигурации)→Linker (Компоновщик)→General (Общие) и в поле с именем Output File (Выходной файл) введите имя и путь выходного файла проекта. Директория этого пути должна указывать на директорию binaries, созданную в начале этой главы, а имя должно быть libgeorgeringo.dll. Аналогично перейдите в раздел Configuration Properties (Свойства конфигурации)→Linker (Компоновщик)→Advanced (Дополнительно) и в поле с именем Import Library (Библиотека импорта) введите имя и путь библиотеки импорта проекта. Директория этого пути должна указывать на директорию binaries, созданную в начале этой главы, а имя должно быть libgeorgeringo.lib.

Затем, чтобы добавить в проект исходные файлы из примера 1.2, используйте Add Existing Item… (Добавить существующий элемент…) из меню Project.

Теперь страницы свойств проекта должны содержать узел с именем «С/С++». Перейдите к Configuration Properties→С/С++→Code Generation (Генерация кода) и, как описано в рецепте 1.19, определите макрос

GEORGERINGO_DLL

Теперь можно собрать проект, выбрав в меню Build пункт Build Solution. Проверьте, что в директории libgeorgeringo.lib были созданы два файла с именами libgeorgeringo.dll и libgeorgeringo.lib.

Как вы уже видели в рецепте 1.11, каждая IDE предоставляет свой собственный способ создания проекта, указания свойств конфигурации и добавления в него файлов. Теперь давайте посмотрим на то, как собрать динамическую библиотеку с помощью CodeWarrior, C++Builder и Dev-C++.

В меню File выберите New… и в диалоге New выберите вкладку Project. В качестве имени проекта введите

libgeorgeringo.mcp

Так как при создании проекта, зависящего от этого проекта, вам придется ссылаться на эти цели по их именам, им следует дать понятные имена. Сейчас переименуйте только отладочную цель. Выберите вкладку Targets окна проекта и дважды щелкните мышью на имени отладочной цели, чтобы отобразить окно Target Settings (Параметры цели). Затем перейдите к Target→Target Settings и в первом поле Target Name (Имя цели) введите

libgeorgeringo Debug

Далее в окне Target Settings перейдите к Target→PPC Mac OS X Target. В качестве Project Туре (Тип проекта) укажите Dynamic Library, а в поле с именем File Name (Имя файла) введите

libgeorgeringo.dylib

Наконец выберите вкладку Files окна проекта и удалите существующие исходные файлы и файлы библиотек, перетащив их в Trash (корзину). Чтобы добавить в проект исходные файлы из примера 1.2, используйте Add Files… (Добавить файлы…) из меню Project. Затем используйте Add Files…, чтобы добавить файл dylib1.о из директории /usr/lib и файлы MSL_All_Mach-O_D.dylib и MSL_Shared_AppAndDylib_Runtime_D.lib из директории Metrowerks CodeWarrior/MacOS X Support/Libraries/Runtime/Runtime PPC/Runtime_MacOSX/Libs. Если бы вы вместо отладочной цели настраивали окончательную, то вместо этих библиотек должны были бы добавить библиотеки MSL_All_Mach-O.dylib и MSL_Shared_AppAndDylib_Runtime.lib. Теперь можно собрать проект, выбрав в меню Project пункт Make. Проверьте, что в директории binaries был создан файл с именем libgeorgeringo.dylib.

В меню File выберите New→Other и затем выберите DLL Wizard. В диалоге DLL Wizard выберите C++ и Multi Threaded. Теперь у вас должен быть проект, содержащий один исходный файл Unit1.cpp. Удалите Unit1.cpp из проекта, сделав для этого щелчок правой кнопкой мыши и выбрав Remove From Project (Удалить из проекта). В меню File выберите Save Project As, выберите директорию для сохранения настроечных файлов проекта и в качестве имени проекта введите libgeorgeringo.bpr.

Затем, чтобы отобразить диалог Project Options (Параметры проекта), в меню Project выберите Options…. Затем перейдите в Directories and Conditionals (Директории и условия) и используйте элемент управления рядом с надписью Final output (Окончательный вывод), чтобы указать, что выходные файлы проекта должны создаваться в директории binaries. По умолчанию они создаются в той же директории, где находится libjohnpaul.bpr. Если хотите, то также можно использовать элемент управления рядом с Intermediate output (Промежуточный вывод) и указать место создания объектных файлов. По умолчанию они создаются в той же директории, где находятся исходные файлы.

Далее определите макрос

GEORGERINGO_DLL

Наконец, чтобы добавить в проект исходные файлы из примера 1.2, используйте Add to Project (Добавить в проект) из меню Project. Теперь можно собрать проект, выбрав в меню Project пункт Make libgeorgeringo. Проверьте, что в директории libgeorgeringo.lib были созданы два файла с именами libgeorgeringo.dll и libgeorgeringo.lib.

В меню File выберите New→Project. В диалоге New project (Новый проект) выберите DLL и C++ Project, а в качестве имени проекта введите libgeorgeringo. После нажатия на OK укажите место для сохранения настроечных файлов проекта.

Затем, чтобы отобразить диалог Project Options, в меню Project выберите Project Option. Затем перейдите к Build Options и проверьте, что в качестве имени выходного файла проекта указано libjohnpaul.dll. В поле Executable output directory (Директория для записи исполняемого файла) введите путь к директории binaries. Если хотите, то в поле Object file output directory (Директория для записи объектных файлов) можно указать директорию для создания объектных файлов.

Теперь определите макрос

GEORGERINGO_DLL

Наконец удалите из проекта все существующие исходные файлы, сделав щелчок правой кнопкой мыши и выбрав Remove file. Для сохранения настроечного файла проекта libgeorgeringo.dev используйте Save Project as из меню File. Затем, чтобы добавить в проект исходные файлы из примера 1.2, используйте Add to project (Добавить в проект) из меню Project. Соберите проект, в меню Execute выбрав Compile, и проверьте, что в директории binaries был создан файл с именем libjohnpaul.a.

Рецепты 1.4, 1.9, 1.17, 1.19 и 1.23.

1.13. Сборка сложного приложения с помощью IDE

Вы хотите использовать IDE для сборки исполняемого файла, зависящего от нескольких статических и динамических библиотек.

Основная процедура выглядит следующим образом.

1. При сборке из исходного кода библиотек, от которых зависит исполняемый файл, при том, что они не имеют своих собственных проектов IDE или make-файлов, создайте для них проекты, как описано в рецептах 1.11 и 1.12.

2. Создайте новый проект и укажите, что требуется собрать исполняемый файл, а не библиотеку.

3. Выберите конфигурацию сборки (т.е. отладочную или окончательную версию и поддержку или отсутствие поддержки многопоточности).

4. Укажите имя исполняемого файла и директорию, в которой он должен быть создан.

5. Добавьте в проект исходные файлы.

6. Скажите компилятору, где искать заголовочные файлы библиотек.

7. Скажите компоновщику, какие библиотеки требуется использовать и где их искать.

8. Если IDE поддерживает группы проектов, добавьте все проекты, указанные выше, в единую группу и укажите зависимости между ними.

9. Если IDE поддерживает группы проектов, соберите группу, созданную на шаге 8. В противном случае соберите проекты по отдельности, обращая внимание на последовательность их сборки с целью соблюдения зависимостей.

Как и в рецептах 1.11 и 1.12, шаги в этой процедуре будут различаться в зависимости от IDE. Третий шаг подробно описывается в рецептах 1.21, 1.22 и 1.23. А сейчас вы, насколько это возможно, должны использовать параметры по умолчанию.

Например, вот как надо собирать исполняемый файл из исходных файлов из примера 1.3 с помощью Visual C++ IDE.

В меню File выберите New→Project, в левой панели выберите Visual С++[4], выберите Win32 Console Application и в качестве имени проекта введите hellobeatles. В мастере Win32 Application Wizard перейдите к Application Settings, выберите Console Application (Консольное приложение) и Empty Project (Пустой проект) и нажмите на Finish. Теперь у вас должен иметься пустой проект hellobeatles.vcproj с двумя конфигурациями сборки — Debug и Release, и первая будет активной. Также у вас должно быть решение hellobeatles.sln, содержащее один проект hellobeatles.vcproj.

Затем, сделав щелчок правой кнопкой мыши на Solution Explorer и выбрав Properties, отобразите страницы свойств проекта. Перейдите в раздел Configuration Properties (Свойства конфигурации)→Linker (Компоновщик)→General (Общие) и в поле с именем Output File (Выходной файл) введите имя и путь выходного файла проекта. Директория этого пути должна указывать на директорию binaries, созданную в начале этой главы, а имя файла должно быть hellobeatles.exe.

Затем, чтобы добавить в проект исходный файл hellobeatles.cpp из примера 1.3, используйте Add Existing Item (Добавить существующий элемент) из меню Project. Теперь страницы свойств проекта должны содержать узел с именем «C/C++». Перейдите к Configuration Properties→C/C++→Code Generation (Генерация кода) и укажите в качестве библиотеки времени выполнения Multi-threaded Debug DLL (многопоточная отладочная динамическая библиотека).

Затем перейдите к Configuration Properties→C/C++→General и в поле редактирования с именем Additional Include Directories (Дополнительные директории заголовочных файлов) введите директорию, которая содержит директории johnpaul и georgeringo, — директорию, являющуюся «дедушкой» по отношению к файлам john.hpp, ringo.hpp и другим. Это позволит корректно разрешить директивы

include

Далее, используя Add→Existing Project… (Существующий проект…) из меню File добавьте в решение hellobeatles файлы проектов libjohnpaul.vcproj и libgeorgeringo.vcproj. Чтобы отобразить диалог Project Dependencies… (Зависимости проектов…), в меню Project выберите Project Dependencies. В раскрывающемся списке выберите hellobeatles и щелкните на флажках рядом с libjohnpaul и libgeorgeringo.

Наконец соберите проект, выбрав в меню Build пункт Build Solution. Проверьте, что в директории binaries были созданы файлы с именами libjohnpaul.lib, libgeorgeringo.dll, libgeorgeringo.lib и hellobeatles.exe. Теперь, чтобы запустить это приложение, в меню Debug выберите Start Without Debugging (Запустить без отладки).

В предыдущем примере было достаточно просто указать, что hellobeatles.exe зависит от библиотек libjohnpaul.lib и libgeorgeringo.dll, так как обе эти библиотеки собирались в проектах Visual C++ из исходного кода. При сборке приложения, которое зависит от библиотек, распространяемых в виде готовых бинарных и заголовочных файлов, указать Visual C++, как их найти, можно следующим способом. Во-первых, перейдите к Configuration Properties→C/C++→General и в поле редактирования Additional Include Directories введите директории, которые содержат заголовочные файлы библиотек. Затем перейдите в раздел Configuration Properties→Linker→Input и в поле с именем Additional dependencies (Дополнительные зависимости) введите имена этих библиотек. Наконец перейдите к Configuration Properties→Linker→General и в поле редактирования Additional Include Directories введите директории, которые содержат бинарные файлы этих библиотек. Теперь давайте посмотрим на то, как из исходного кода из примера 1.3 собрать исполняемый файл с помощью CodeWarrior, C++Builder и Dev-C++.

В меню File выберите New… и в диалоге New выберите вкладку Project. В качестве имени проекта введите

hellobeatles.mcp

Так как при добавлении в проект зависимостей вам придется ссылаться на эти цели по их именам, им следует дать понятные имена. Сейчас переименуйте только отладочную цель. Выберите вкладку Targets окна проекта и дважды щелкните мышью на имени отладочной цели, чтобы отобразить окно Target Settings (Параметры цепи). Затем перейдите к Target→Target Settings и в первом поле Target Name (Имя цели) введите

hellobeatles Debug

Далее выберите вкладку Targets окна проекта и дважды щелкните мышью на имени отладочной цели, чтобы отобразить окно Target Settings, Перейдите к Target→PPC Mac OS X Target, в качестве Project Туре (Тип проекта) укажите Executable (Исполняемый файл), а в поле с именем File Name (Имя файла) введите hellobeatles. Чтобы в качестве места для создания выходного файла hellobeatles указать директорию binaries, перейдите к Target→Target Settings и нажмите на Choose….

Выберите вкладку Files окна проекта и удалите существующие исходные файлы и файлы библиотек MSL, перетащив их в Trash (корзину). Чтобы добавить в проект исходный файл hellobeatles.cpp из примера 13, используйте Add Files… (Добавить файлы…) из меню Project. Затем используйте Add Files…, чтобы добавить файлы MSL_All_Mach-O_D.dylib и MSL_Shared AppAndDylib_Runtime_D.lib, находящиеся в директории Metrowerks CodeWarrior/MacOS X Support/Libraries/Runtime/Runtime PPC/Runtime_MacOSX/Libs. Если бы вы вместо отладочной цели настраивали окончательную, то вместо этих библиотек должны были бы добавить библиотеки MSL_All_Mach-О.dylib и MSL_Shared_AppAndDylib_Runtime.lib. В окне Target Settings перейдите к Target→Access Paths (Пути доступа) и щелкните на панели, которая называется User Paths (Пути пользователя). Чтобы добавить директорию, которая содержит директории johnpaul и georgeringo, — директорию, являющуюся «дедушкой» по отношению к исходным файлам ringo.hpp, ringo.hpp и другим, — используйте элемент управления с именем Add…. Это позволит корректно разрешить директивы

include

Используя Add Files… из меню Project, добавьте в проект hellobeatles.mcp файлы проектов libjohnpaul.mcp и libgeorgeringo.mcp. Перейдите на вкладку Targets и раскройте узлы, которые называются hellobeatles Debug, libjohnpaul.mcp и libgeorgeringo.mcp. Щелкните на пиктограммах целей, расположенных рядом с дочерними узлами libjohnpaul.mcp и libgeorgeringo.mcp, которые называются libjohnpaul Debug и libgeorgeringo Debug. На обеих пиктограммах должны появиться жирные стрелки. Если требуется, увеличьте окно проекта так, чтобы увидеть небольшую пиктограмму связи у правого края окна. Дважды щелкните в этом столбце — напротив пиктограмм целей со стрелками. В этом столбце должны появиться две черные точки.

Соберите проект, выбрав в меню Project пункт Make. Компоновщик может отобразить несколько предупреждений о символах, определенных несколько раз, но ими можно пренебречь. Вы можете подавить их, перейдя к Linker→Mac OS X Linker и установив опцию Suppress Warning Messages (Подавлять предупреждающие сообщения).

Проверьте, что в директории binaries были созданы файлы с именами libjohnpaul.a, libgeorgeringo.dylib и hellobeatles. Теперь запустите hellobeatles, поместив в директорию binaries копию библиотек MSL_All_Mach-O_D.dylib, перейдя в директорию binaries и введя в командной строке

./hellobeatles

В меню File выберите New и затем выберите Console Wizard. В диалоге Console Wizard выберите C++, Multi Threaded (Многопоточное) и Console Application (Консольное приложение). Теперь у вас должен быть проект, содержащий один исходный файл Unit1.cpp. Удалите Unit1.cpp из проекта, сделав для этого щелчок правой кнопкой мыши и выбрав Remove From Project (Удалить из проекта). В меню File выберите Save Project As, выберите директорию для сохранения настроечных файлов проекта и в качестве имени проекта введите hello_beatles. Я добавил в имя проекта знак подчеркивания, потому что C++Builder не позволяет указывать для проекта то же имя, что и для исходного файла.

Затем, чтобы отобразить диалог Project Options (Параметры проекта), в меню Project выберите Options…. Далее перейдите в Directories and Conditionals (Директории и условия) и используйте элемент управления рядом с надписью Final output (Окончательный вывод), чтобы указать, где должен создаваться выходной файл hello_beatles.exe. По умолчанию этот файл будет создан в той же директории, где находится hello_beatles.bpr. Скажите C++Builder, что его требуется создать в директории binaries. Если хотите, то также можете использовать элемент управления рядом с Intermediate output (Промежуточный вывод) и указать место создания объектных файлов. По умолчанию они создаются в той же директории, где находятся исходные файлы.

После этого, чтобы добавить в проект исходный файл hellobeatles.cpp из примера 1.3, используйте Add to Project (Добавить в проект) из меню Project.

Затем из Project Options перейдите к Directories and Conditionals и, используя элемент управления рядом с Include path (Путь заголовочных файлов), выберите директорию, которая содержит директории johnpaul и georgeringo, — директорию, являющуюся «дедушкой» по отношению к исходным файлам john.hpp, ringo.hpp и другим. Это позволит корректно разрешить директивы

include

Далее сделайте щелчок правой кнопкой мыши на ProjectGroup1, выберите Save Project Group As, выберите директорию, содержащую файл hello_beatles.bpr, и введите имя группы проектов hello_beatles.bpg.

После этого в группу проектов добавьте проекты libjohnpaul.bpr и libgeorgeringo.bpr, сделав щелчок правой кнопкой мыши на надписи hello_beatles и выбрав Add Existing Project. Соберите эти два проекта, как описано в рецептах 1.11 и 1.12, если этого еще не сделано, а затем с помощью Add to Project из меню Project добавьте выходные файлы libjohnpaul.lib и libgeorgeringo.lib в проект hello_beatles. Используя клавишу со стрелкой при нажатой клавише Ctrl, переместите в Project Manager проекты libjohnpaul и libgeorgeringo выше проекта hello_beatles так, чтобы гарантировать, что они будут собираться первыми.

Наконец соберите решение, выбрав в меню Build пункт Make All Projects. Проверьте, что в директории binaries был создан файл с именем hellobeatles.exe. Чтобы запустить приложение, выберите Run в меню Run.

В меню File выберите New→Project. В диалоге New project (Новый проект) выберите Console Application и C++ Project, а в качестве имени проекта введите hellobeatles. После нажатия на OK укажите место для сохранения настроечных файлов проекта.

Затем от Project Options перейдите к Build Options и проверьте, что в качестве имени выходного файла проекта указано hellobeatles.exe. В поле Executable output directory (Директория для записи исполняемого файла) введите путь к директории binaries. Если хотите, то в поле Object file output directory (Директория для записи объектных файлов) можно указать директорию для создания объектных файлов.

Далее удалите из проекта все существующие исходные файлы, сделав щелчок правой кнопкой мыши и выбрав Remove file (Удалить файл). Для сохранения настроечного файла проекта hellobeatles.dev используйте Save Project as из меню File. Наконец, чтобы добавить в проект исходный файл hellobeatles.cpp из примера 1.3, используйте Add to project (Добавить в проект) из меню Project

Затем, чтобы отобразить диалог Project Options, в меню Project выберите Project Options. Затем перейдите к Directories→Include Directories, выберите директорию, которая содержит директории johnpaul и georgeringo — директорию, являющуюся «дедушкой» по отношению к исходным файлам ringo.hpp, ringo.hpp и другим, — и нажмите на Add. Это позволит корректно разрешить директивы include в заголовочном файле hellobeatles.hpp.

Наконец от Project Options перейдите к Directories→Libraries Directories и добавьте директорию, которая содержит выходные файлы libjohnpaul.a и libgeorgeringo.c проектов libjohnpaul и libgeorgeringo. Затем перейдите к Parameters→Linker и введите опции -ljohnpaul и -lgeorgeringo.

Теперь с помощью Compile из меню Execute соберите все три проекта по отдельности, проверив, что hellobeatles собирается последним. Запустите hellobeatles.exe, выбрав в меню Execute пункт Run.

Рецепты 1.5, 1.10 и 1.18.

1.14. Получение GNU make

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

Решение зависит от вашей операционной системы.

Хотя в некоторых источниках можно получить готовые бинарные файлы GNU make, чтобы использовать возможности GNU make по максимуму, она должна быть установлена как часть Unix-подобной среды. Я рекомендую использовать либо Cygwin, либо MSYS, являющуюся частью проекта MinGW.

Если вы установили Cygwin, как описано в рецепте 1.1, то GNU make у вас уже есть. Чтобы запустить ее из оболочки Cygwin, просто введите команду make.

Чтобы установить MSYS, начните с установки MinGW, как описано в рецепте 1.1. Будущие версии инсталлятора MinGW могут предоставить опцию для автоматической установки MSYS. Но пока выполните следующие дополнительные действия.

Во-первых, на домашней странице MinGW http://www.mingw.org перейдите на страницу закачки MinGW и скачайте самую последнюю стабильную версию программы установки MSYS. Имя этой программы установки должно иметь вид MSYS-<версия>.exe.

Далее запустите программу установки. После этого будет выдан запрос на ввод пути, где находится установка MinGW, и пути, куда следует устанавливать MSYS. Когда программа установки завершит работу, директория установки MSYS должна содержать файл msys.bat. Запуск этого скрипта приведет к отображению оболочки MSYS — порта оболочки bash, из которой можно запускать GNU make и другие программы MinGW, такие как ar, ranlib и dlltool.

Вначале, введя в командной строке make -v, проверьте, установлена ли в вашей системе утилита GNU make. Если GNU make установлена, она должна вывести сообщение, подобное следующему:

GNU Make 3.90

Copyright (С) 2002 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.

Если в системе имеется не-GNU-версия make, то, возможно, GNU-версия установлена под именем gmake. Это можно проверить, введя в командной строке gmake -v.

При использовании Mac OS X простейшим способом получения GNU make является скачивание с web-сайта Apple среды разработки Xcode и следование простым инструкциям ее установки. В настоящий момент Xcode доступен по адресу developer.apple.com/tools.

В других случаях скачайте самую свежую версию GNU make с сайта ftp://ftp.gnu.org/pub/gnu/make, распакуйте ее и следуйте инструкциям по установке.

Утилита make имеет множество разновидностей. Большая часть инструментариев содержит собственные варианты make. Например, Visual C++ поставляется с утилитой, которая называется nmake.exe. Обычно эти специфичные версии make содержат встроенные функции, которые облегчают их использование с конкретным инструментарием. В результате обсуждение make, которое охватывает множество инструментариев, должно будет описать несколько версий make или иметь дело с ситуациями, когда между какой-то отдельной версией make и конкретным инструментарием не будет соответствия.

Вместо того чтобы описывать несколько утилит make, я решил сконцентрировать внимание на GNU make, которая является наиболее мощным и переносимым вариантом make. GNU make в первую очередь предназначена для работы с GCC. В результате использование GNU make с другим инструментарием, в частности для Windows, иногда может оказаться нетривиальным. Тем не менее, так как GNU make обладает достаточной гибкостью, гораздо проще использовать GNU make с нe-GNU-инструментам и, чем большую часть других make, типа nmake.exe, с инструментарием, отличным от того, для которого они были разработаны.

Основные преимущества GNU make происходят от ее способности исполнять сложные сценарии оболочки. Если вы работаете одновременно и в Unix, и в Windows, вы знаете, что оболочка Windows cmd.exe оставляет желать много большего; в ней отсутствуют многие полезные команды, она имеет ограниченную способность по выполнению сценариев и накладывает жесткие ограничения на длину командной строки. Следовательно, если заставить GNU make использовать cmd.exe, то ее возможности будут сильно ограничены. К счастью, Cygwin и MSYS предоставляют прекрасные среды для использования GNU make в Windows.

MSYS предоставляет минимальную среду, необходимую для запуска в Windows make-файлов и сценариев configure в стиле Unix. Среди прочих полезных инструментов она предоставляет awk, cat, cp, grep, ls, mkdir, mv, rm, rmdir и sed. MSYS была предназначена для работы с GCC и прекрасно с этим справляется. Однако с другими инструментариями для Windows, в частности теми, которые предоставляют .bat-файлы для установки переменных среды и используют для опций командной строки слеши (/) вместо тире (-), она работает несколько менее гладко.

Так, где MSYS минимальна, Cygwin максимальна. Cygwin make может делать все, что может MSYS make, и даже много больше. Однако переносимые make-файлы ограничены узким диапазоном утилит GNU, и они все поддерживаются в MSYS.

Рецепт 1.1.

1.15. Сборка простого приложения «Hello, World» с помощью GNU make

Вы хотите с помощью GNU make собрать простую программу «Hello, World», подобную приведенной в примере 1.4.

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

цели: пререквизиты

 команда-сценари

Здесь

цели

пререквизиты

команда-сценарий

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

all

install

clean

install

clean

install

PHONY

Например, чтобы с помощью GCC собрать исполняемый файл из исходного кода из примера 1.4, make-файл может иметь вид, показанный в примере 1.14.

Пример 1.14. make-файл для сборки исполняемого файла с помощью GCC

# Это цель по умолчанию, которая будет собрана при

# вызове make

.PHONY: all

all: hello

# Это правило говорит make, как собрать hello из hello.cpp

hello: hello.cpp

   g++ -o hello hello.cpp

# Это правило говорит make скопировать hello в поддиректорию binaries,

# создав ее, если требуется

.PHONY: install

install:

   mkdir -p binaries

   cp -p hello binaries

# Это правило говорит make удалить hello и hello.о

.PHONY: clean

clean:

   rm -f hello

Чтобы собрать исполняемый файл из исходного кода из примера 1.4 с помощью Visual С++, используйте make-файл, показанный в примере 1.15.

Пример 1.15. make-файл для сборки исполняемого файла с помощью Visual С++.

#цель по умолчанию

.PHONY: all

all: hello.exe

#правило для сборки hello.exe

hello.exe: hello.cpp

   cl -nologo -EHsc -GR -Zc:forScope -Zc:wchar_t \

   -Fehello hello.cpp

.PHONY: install

install:

   mkdir -о binaries

   cp -p hello.exe binaries

.PHONY: clean

clean:

   rm -f hello.exe

Чтобы собрать исполняемый файл, установите переменные среды, необходимые для инструментов командной строки, перейдите в директорию, содержащую makefile, и введите

make

make install

make clean

PATH

make

В нескольких последующих рецептах вы увидите, что GNU make является достаточно мощным инструментом для сборки сложных проектов. Но что же она делает? Вот как она работает. При вызове make без аргументов она просматривает текущую директорию в поисках файла с именем GNUmakefile, makefile или Makefile и пытается собрать первую содержащуюся в нем цель, которая называется целью по умолчанию (default target). Если цель по умолчанию не устарела, что означает, что она существует, все ее пререквизиты существуют и ни один из них не был изменен с момента ее сборки, то работа make закончена. В противном случае она пытается сгенерировать цель по умолчанию из ее пререквизитов, выполнив соответствующий командный сценарий. Аналогично определению устаревания этот процесс рекурсивен: для каждого устаревшего пререквизита make ищет правило, содержащее этот пререквизит в качестве цели, и начинает весь процесс заново. Так продолжается до тех пор, пока цель по умолчанию не будет обновлена или пока не возникнет ошибка.

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

И наоборот, пререквизит, соответствующий существующему файлу, никогда не устаревает при условии, что этот файл не указан в качестве цели одного из правил.

Теперь давайте посмотрим на то, что происходит при выполнении make-файла из примера 1.14. Фиктивная цель

all

all

all

hello

hello

hello.cpp

all

all

При вызове make с аргументом командной строки, соответствующим цели, make пытается собрать эту цель. Следовательно, выполнение

make install

mkdir -p binaries

cp -p hello binarie

Первая команда создает, если она не существует, директорию binaries, а вторая команда копирует в эту директорию файл hello. Точно так же

make clean

rm -f hello

которая удаляет hello.

mkdir

cp

rm

install

clean

После того как вы поймете, как make анализирует зависимости, пример 1.14 покажется очень простым. Однако на самом деле он значительно сложнее, чем требуется. Рассмотрение различных методов его упрощения является хорошим способом узнать некоторые из основ make-файлов.

GNU make поддерживает переменные, чьими значениями являются строки. Наиболее часто переменные используются в make-файлах как символьные константы. Вместо того чтобы жестко указывать в нескольких местах make-файла имя файла или команды оболочки, вы можете присвоить имя файла или команды переменной и далее использовать эту переменную. Это дает возможность облегчить сопровождение make-файлов. Например, make-файл из примера 1.14 можно переписать с помощью переменных make так, как показано в примере 1.16.

Пример 1.16. make-файл для сборки исполняемого файла hello с помощью GCC, измененный с помощью переменных

# Указываем целевой файл и директорию установки

OUTPUTFILE=hello

INSTALLDIR=binaries

# Цель по умолчанию

.PHONY all

all: $(OUTPUTFILE)

# Собрать hello из hello.cpp

$(OUTPUTFILE): hello cpp

   g++ -o hello hello.cpp

#Скопировать hello в поддиректорию binaries

.PHONY: install

install:

   mkdir -p $(INSTALLDIR)

   cd -p $(OUTPUTFILE) $(INSTALLDIR)

# Удалить hello

.PHONY: clean

clean:

   rm -f $(OUTPUTFILE)

Здесь я ввел две переменные make —

OUTPUTFILE

INSTALLDIR

Также установить значение переменной make можно в командной строке с помощью записи make X=Y. Кроме того, при запуске make все переменные среды используются для инициализации переменных make с такими же именами и значениями. Значения, указанные в командной строке, имеют приоритет перед значениями, унаследованными от переменных среды. Значения, указанные в самом make-файле, имеют приоритет перед значениями, указанными в командной строке.

Также GNU make поддерживает автоматические переменные (automatic variables), имеющие специальные значения при выполнении командного сценария. Наиболее важные из них — это переменная

$@

$<

$^

Пример 1.17. make-файл для сборки исполняемого файла hello с помощью GCC, измененный с помощью автоматических переменных

# Указываем целевой файл и директорию установки

OUTPUTFILE=hellо

INSTALLDIR=binaries

# Цель по умолчанию

.PHONY all

all: $(OUTPUTFILE)

# Собрать hello из hello.cpp

$(OUTPUTFILE) hello.cpp

   g++ -o $@ $<

# Цели Install и clean как в примере 1 16

В командном сценарии

g++ -o $@ $<

$@

hello

$<

hello.cpp

make-файл в примере 1.17 может быть еще проще. На самом деле командный сценарий, связанный с целью

hello

Пример 1.18. make-файл для сборки исполняемого файла hello с помощью GCC, измененный с помощью неявных правил

# Указываем целевой файл и директорию установки

OUTPUTFILE=hello

INSTALLDIR=binaries

# Цель по умолчанию

.PHONY: all

all: $(OUTPUTFILE)

# Говорим make пересобрать hello тогда, когда изменяется hello.cpp

$(OUTPUTFILE): hello.cpp

# Цели Install и clean как в примере 1.16

Откуда make знает, как собирать исполняемый файл hello из исходного файла hello.cpp, без явного указания? Ответ состоит в том, что make содержит внутреннюю базу данных неявных правил, представляющих операции, часто выполняемые при сборке приложений, написанных на С и С++. Например, неявное правило для генерации исполняемого файла из файла .cpp выглядит так, как в примере 1.19.

Пример 1.19. Шаблон правила из внутренней базы данных make

%: %.cpp

# исполняемые команды (встроенные):

   $(LINK.cpp) $(LOADLIBS) $(LDLIBS) -о $@

Правила, первые строки которых имеют вид

%xxx:%yyy

%

Например, при первом выполнении make-файла из примера 1.18 пререквизит

hello

all

hello

$(OUTPUTFILE): hello.cpp

hello

hello

hello: hello.cpp

   $(LINK.cpp) $(LOADLIBS) $(LDLIBS) -o $@

Пока все хорошо, но есть еще кое-что. Повторный взгляд на внутреннюю базу данных make показывает, что переменная

LINK.cpp

$(LINK.cc)

LINK.cc

$(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)

Наконец, переменная

CXX

g++

$(CXXFLAGS)

$(CPPFLAGS)

$(LDFLAGS)

$(TARGET_ARCH)

hello: hello.cpp

   g++ $^ -o $@

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

%: %.cpp

   g++ $^ -о $@

Ответ состоит в том, что промежуточные переменные, такие как

$(CXX)

$(CXXFLAGS)

$(CPPFLAGS)

$(LDFLAGS)

LDFLAGS

CPPFLAGS

CXXFLAGS

CXX

make CXX=icpc

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

VPATH

VPATH = <путь-к-файлам-cpp>

Чтобы сказать make, что выполнять поиск определенных типов файлов требуется в определенном месте, используйте директиву

vpath

# искать файлы .exp в ../lib

vpath %. exp../lib

Рецепты 1.2 и 1.7.

1.16. Сборка статической библиотеки с помощью GNU Make

Вы хотите использовать GNU make для сборки статической библиотеки из набора исходных файлов C++, таких как перечисленные в примере 1.1.

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

all

CXX

CXXFLAGS

install

clean

Например, чтобы с помощью GCC в Unix собрать из исходных файлов, перечисленных в примере 1.2, статическую библиотеку, создайте в директории johnpaul make-файл, показанный в примере 1.20.

Пример 1 20. make-файл для создания libjohnpaul.a с помощью GCC в Unix

# Укажите расширения файлов, удаляемых при очистке

CLEANEXTS - о а

# Укажите целевой файл и директорию установки

OUTPUTFILE = libjohnpaul.a

INSTALLDIR = ../binaries

# Цель по умолчанию

.PHONY: all

all: $(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

install:

   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

all: $(OUTPUTFILE)

# Соберите libjohnpaul.lib из john.obj, paul.obj и johnpaul.obj

$(OUTPUTFILE): john.obj paul.obj johnpaul.obj

   "$(MSVCDIR)/bin/link" -lib -nologo -out:"$@" $^

.PHONY: install

install:

   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

"$(MSVCDIR)/bin/link"

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

clean

all

Правило для сборки статической библиотеки выглядит так.

$(OUTPUTFILE): john.o paul.o johnpaul.о

   ar ru $@ $^

   ranlib $@

Это непосредственная адаптация записи для GCC из табл. 1.10. Здесь

$(OUTPUTFILE)

$@

libjohnpaul.a

$^

john.o paul.o johnpaul.о

Следующие два правила объявляют цели

install

clean

о а

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 можно заменить на следующие.

# Генерируем зависимости .cpp-файлов от .hpp-файлов

include john.o paul.o johnpaul.о

%.d: %.cpp

   $(CC) -M $(CPPFLAGS) $< > $@.$$$$; \

   sed 's.\($*\)\.o[ :]*.\1.o $@ : ,g' < $@.$$$$ > $@, \

   rm -f $@.$$$$

Этот фрагмент кода основан на опции компилятора -M, которая заставляет GCC вывести в make-файл информацию о зависимостях. За подробным описанием того, как это работает, и почему иногда не подходит, обратитесь к книге Managing Projects with GNU make, Third Edition, написанной Робертом Мекленбургом (Robert Mecklenburg) (O'Reilly).

Так как большинство компиляторов имеет опцию, аналогичную опции -М GCC, этот метод может быть адаптирован для работы с большинством инструментов. На самом деле обычно эта опция называется -М или -m. Однако Visual C++ не имеет опции для генерации зависимостей в make-файле. При использовании Visual C++ есть две возможности. Можно использовать опцию -Gm совместно с опциями -Zi или -ZI, обсуждаемыми в рецепте 1.21. Опция -Gm говорит компилятору создать базу данных, сохраняемую в файле с расширением idb, содержащую информацию о зависимостях между исходными файлами. Файл .idb создается при первоначальной компиляции файла или набора файлов .cpp. При последующих компиляциях перекомпилируются только те исходные файлы, которые были изменены или зависят от изменившихся заголовочных файлов.

Кроме того, можно использовать опцию -showIncludes совместно с опцией -E. Опция -showIncludes приводит к тому, что компилятор при каждом обнаружении директивы include выводит в стандартный поток ошибок сообщение. Опция -E говорит компилятору запустить препроцессор и выйти, не создавая никаких двоичных файлов. С помощью небольшого сценария оболочки можно использовать вывод, сгенерированный -showIncludes; для создания зависимостей в make-файле.

include john.d paul.d johnpaul.d

%d: %.cpp

   "$(MSVCDIR)/bin/cl" -E -showIncludes $< 2> $@.$$$$ > /dev/null; \

   sed -n 's/^Note: including file: *\(.*\)/$*.obj•$*.d:\1/gp' \

   < $@.$$$$ | sed "s:\\:/:g:s: :\\ :gp" > $@; \

   rm -f $@.$$$$

В этом примере символ • обозначает Tab.

Давайте сделаем еще одно последнее усовершенствование примера 1.20. В настоящий момент последовательность

john paul johnpaul

include

SOURCES

john paul johnpaul

SOURCES

SOURCES = john.cpp paul.cpp johnpaul.cpp

...

# Собираем libjohnpaul.a из john.о, paul.o и johnpaul.о

$(OUTPUTFILE): $(subst .cpp, .o,$(SOURCES))

   ar ru $@ $^

   ranlib $@

...

# Генерируем зависимости .cpp-файлов от .hpp-файлов

include $(subst .cpp,.d,$(SOURCES))

%d: %.cpp

   $(CC) -M $(CPPFLAGS) $< > $@.$$$$; \

   sed 's,\($*\)\.o[ :]*.\1.o $@ : .g' < $@ $$$$ > $@; \

   rm -f $@.$$$$

Здесь я использую функцию make

$(subst x, y, str)

str

x

y

Рецепты 1.2 и 1.7.

1.17. Сборка динамической библиотеки с помощью GNU Make

Вы хотите использовать GNU make для сборки динамической библиотеки из набора исходных файлов С++, таких как перечисленные в примере 1.2.

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

цель

CXX

CXXFLAGS

install

clean

Например, чтобы из исходных файлов, перечисленных в примере 1.2, собрать динамическую библиотеку с помощью GCC в Unix, в директории georgeringo создайте make-файл, показанный в примере 1.22.

Пример 1.22. make-файл для libgeorgeringo.so с использованием GCC

# Укажите расширения файлов, удаляемых при очистке

CLEANEXTS = o so

# Укажите исходные файлы, целевой файл и директорию установки

SOURCES = george.cpp ringo.cpp georgeringo.cpp

OUTPUTFILE = libgeorgeringo.so

INSTALLDIR = ../binaries

.PHONY: all

all: $(OUTPUTFILE)

# Соберите libgeorgeringo.so из george.o, ringo.о

# и georgeringo.o; subst - это функция поиска и замены.

# показанная в рецепте 1.16

$(OUTPUTFILE): $(subst .cpp,.o,$(SOURCES))

   $(CXX) -shared -fPIC $(LDFLAGS) -о

.PHONY: install

install:

   mkdir -p $(INSTALLDIR)

   cp -p $(OUTPUTFILE) $(INSTALLDIR)

.PHONY: clean

clean:

   for file in $(CLEANEXTS); do rm -f *.$$file; done

# Сгенерируйте зависимости файлов .cpp от файлов .hpp

   include $(subst .cpp,.d,$(SOURCES))

%.d: %.cpp

   $(CC) -M $(CPPFLAGS) $< > $@.$$$$; \

   sed 's. \($*\)\.o[ :]*.\1.o $@ : ,g' < $@.$$$$ > $@; \

   rm -f $@.$$$$

make-файл из примера 1.22 — это прямое применение идей из рецептов 1.4, 1.15 и 1.16. Главным отличием между примерами 1.22 и 1.20 является правило для сборки libgeorgeringo.so из объектных файлов george.o, ringo.o и georgeringo.о.

$(OUTPUTFILE): $(subst .cpp,.o,$(SOURCES))

$(CXX) -shared -fPIC $(LDFLAGS) -о $@ $^

Здесь

$(OUTPUTFILE)

libgeorgeringo.so

$(subst.cpp, .o, $(SOURCES))

george.о

ringo.о

georgeringo.o

$(CXX) -shared -fPIC $(LDFLAGS) -о

Рецепты 1.4, 1.9, 1.12, 1.19 и 1.23.

1.18. Сборка сложного приложения с помощью GNU make

Вы хотите использовать GNU make для сборки исполняемого файла, зависящего от нескольких статических и динамических библиотек.

Выполните следующие действия.

1. Создайте make-файлы для библиотек, используемых приложением, как описано в рецептах 1.16 и 1.17. Эти make-файлы должны находиться в отдельных директориях.

2. Создайте make-файл в еще одной директории. Этот make-файл будет использоваться для сборки приложения, но только после того, как будут выполнены make-файлы из шага 1. Укажите в этом make-файле фиктивную цель

all

3. В директории, родительской по отношению к директориям, содержащим все остальные make-файлы, создайте новый make-файл — давайте называть его главным (top-level) make-файлом, а все остальные — подчиненными. Объявите цель по умолчанию all с пререквизитами в виде директории, содержащей make файл, созданный на шаге 2. Объявите правило, чьи цели состоят из директорий, содержащих подчиненные make-файлы, а командный сценарий вызывает make в каждой целевой директории для цели, указанной в виде значения переменной

TARGET

Например, чтобы из исходных файлов из примера 1.3 собрать исполняемый файл с помощью GCC в Unix, создайте такой make-файл, как показанный в примере 1.23.

Пример 1.23. make файл для hellobeatles.exe с использованием GCC

# Укажите исходные файлы, целевой файл, директории сборки

# и директорию установки

SOURCES = hellobeatles.cpp

OUTPUTFILE = hellobeatles

LIBJOHNPAUL = libjohnpaul.a

LIBGEORGERINGO = libgeorgeringo.so

JOHNPAULDIR = ../johnpaul

GEORGERINGODIR = ../georgeringo

INSTALLDIR = ../binaries

#

# Добавьте в путь поиска заголовочных файлов родительскую директорию

#

CPPFLAGS += -I..

#

# Цель по умолчанию

#

.PHONY: all

all: $(HELLOBEATLES)

#

# Цель для сборки исполняемого файла.

#

$(OUTPUTFILE): $(subst .cpp,.о,$(SOURCES)) \

 $(JOHNPAULDIR)/$(LIBJOHNPAUL) \

 $(GEORGERINGODIR)/$(LIBGEORGERINGO)

   $(CXX) $(LDFLAGS) -o $@ $^

.PHONY: install

install:

   mkdir -p $(INSTALLDIR)

   cp -p $(OUTPUTFILE) $(INSTALLDIR)

.PHONY: clean

clean:

   rm -f *.o

   rm -f $(OUTPUTFILE)

#Сгенерируйте зависимости .cpp-файлов от .hpp-файлов

include $(subst .cpp,.d,$(SOURCES))

%.d: %.cpp

   $(CC) -M $(CPPFLAGS) $< > $@.$$$$; \

   sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@..$$$$ > $@; \

   rm -f $@.$$$$

Далее в директории, содержащей johnpaul, georgeringo, hellobeatles и binaries, создайте главный make-файл, как показано в примере 1.24.

Пример 1.24. Главный make-файл для исходного кода из примеров 1.1, 1.2 и 1.3

# Все цели в этом make-файле — фиктивные

PHONY: all johnpaul georgeringo hellobeatles

# Цель по умолчанию

all: hellobeatles

# Цели johnpaul, georgeringo и hellobeatles представляют

# директории, командный сценарий вызывает make в каждой из них

johnpaul georgeringo hellobeatles

$(MAKE) --directory=$@ $(TARGET)

# Это правило указывает что цель по умолчанию make-файла

# в директории hellobeatles зависит от целей по умолчанию

# make-файлов из директорий johnpaul и georgeringo

.PHONY: hellobeatles

hellobeatles: johnpaul georgeringo

Чтобы собрать hellobeatles, перейдите в директорию, содержащую главный make-файл, и введите

make

make TARGET=install

make TARGET=clean

Подход к управлению сложными проектами, продемонстрированный в этом рецепте, известен как рекурсивный make (recursive make). Он позволяет организовать проект в виде набора модулей, каждый со своим собственным make-файлом, и указать зависимости между этими модулями. Он не ограничен одним главным make-файлом с набором дочерних make-файлов: эта методика может применяться для обработки многоуровневых древовидных структур. В то время, пока рекурсивный make был стандартной методикой управления большими проектами с помощью make, появились другие методы, которые теперь рассматриваются как более качественные. За подробностями снова обратитесь к Managing Projects with GNU make, Third Edition Роберта Мекленбурга (O'Reilly).

Пример 1.23 — это прямое применение методик, продемонстрированных в рецептах 1.15, 1,16 и 1.17. В нем есть один очень интересный момент. Как показано в рецепте 1.15, при компиляции hellobeatles.cpp из командной строки необходимо использовать опцию -I.., говорящую компилятору, где искать заголовочные файлы johnpaul.hpp и georgeringo.hpp. Одним из возможных решений является написание явного правила сборки hellobeatles.o с помощью командного сценария, содержащего опцию -I.. подобно этому.

hellobeatles.o: hellobeatles.cpp

g++ -с -I.. -о hellobeatles.o hellobeatles.cpp

Вместо этого я использовал точку настройки

CPPFLAGS

CPPFLAGS += -I..

Вместо оператора присвоения

=

+=

CPPFLAGS

Теперь давайте посмотрим на то, как работает пример 1.24. Наиболее важным правилом является то, которое заставляет make вызываться для каждой из директорий johnpaul, georgeringo и hellobeatles.

johnpaul georgeringo hellobeatles:

$(MAKE) --directory=$@ $(TARGET)

Чтобы понять это правило, вы должны знать три вещи. Во-первых, переменная

MAKE

make

gmake

<path>

johnpaul:

   $(MAKE) --directory=$@ $(TARGET)

georgeringo:

   $(MAKE) --directory=$@ $(TARGET)

hellobeatles:

   $(MAKE) --directory=$@ $(TARGET)

В свою очередь это эквивалентно:

johnpaul:

   $(MAKE) --directory=johnpaul $(TARGET)

georgeringo:

   $(MAKE) --directory=georgeringo $(TARGET)

hellobeatles:

   $(MAKE) -directory=hellobeatles $(TARGET)

Следовательно, эффект от этого правила состоит в вызове make-файлов в каждой из директорий johnpaul, georgeringo и hellobeatles, а в командной строке передаётся значение переменной

TARGET

xxx

TARGET=xxx

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

hellobeatles

johnpaul

georgeringo

hellobeatles: johnpaul georgeringo

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

Рецепты 1.5, 1.10 и 1.13.

1.19. Определение макроса

Вы хотите определить символ препроцессора

name

value

Опции компилятора для определения макросов в командной строке показаны в табл. 1.16. Инструкции для определения макросов в IDE приведены в табл. 1.17. Чтобы определить макрос с помощью Boost.Build, просто добавьте в требования цели свойство вида

name[=value]

Табл. 1.16. Определение макроса из командной строки

-Dname[-value]

Табл. 1.17. Определение макроса из IDE

name[=value]

#define name[=value]

name[=value]

-Dname[=value]

Символы препроцессора часто используются в коде C++ для того, чтобы один набор исходных файлов мог быть использован в нескольких конфигурациях сборки или операционных системах. Например, предположим, что вы хотите написать функцию, проверяющую, является ли имя объекта именем файла или директории. Сейчас стандартная библиотека C++ не предоставляет функциональности, необходимой для выполнения этой задачи. Следовательно, эта функция должна использовать функции, специфичные для платформы. Если вы хотите, чтобы этот код работал и в Windows, и в Unix, вы должны убедиться, что код, использующий специфичные для Windows функции, невидим для компилятора при компиляции под Unix, и наоборот. Обычным способом достижения этого эффекта является использование условной компиляции, иллюстрируемой в примере 1.25.

Пример 1.25. Условная компиляция с помощью предопределенных макросов

#ifdef _WIN32

# include 

#else // He Windows - предположим, что мы в Unix

# include 

#endif

bool is_directory(const char* path) {

#ifdef _WIN32

 // реализация для Windows

#else

 // реализация для Unix

#endif

}

В Windows все наборы инструментов, за исключением порта GCC Cygwin, определяют макрос

_WIN32

WIN32

Однако часто настроечная информация, необходимая для выполнения подобного рода условной компиляции, в виде предопределенных макросов недоступна. В таких случаях необходимо создать собственные макросы и с помощью методов, показанных в табл. 1.15, 1.16 и 1.17, присвоить им соответствующие значения. Хорошим примером является пример 1.2. В Windows при сборке DLL georgeringo.dll функция

georgeringo()

__declspec(dllexport)

__declspec(dllimport)

GEORGERINGO_DLL

-D<name>=<value>

Рецепты 1.4, 1.9, 1.12 и 1.17.

1.20. Указание опций командной строки из IDE

Вы хотите передать компилятору или компоновщику опцию командной строки, но она не соответствует ни одному из параметров, доступных в IDE.

Многие IDE предоставляют способ передачи опций командной строки непосредственно компилятору или компоновщику. Эти способы приведены в табл. 1.18 и 1.19.

Табл. 1.18. Указание опций компилятора из IDE

Табл. 1.19. Указание опций компоновщика из IDE

Visual C++ предоставляет опции расширенной настройки через свой графический интерфейс, но также позволяет указать опции командной строки явно. CodeWarrior и C++Builder не позволяют явно устанавливать опции командной строки, но обычно это не является проблемой, так как аналогично Visual C++ они предоставляют опции расширенной настройки через свои графические интерфейсы. С другой стороны, некоторые IDE предоставляют для настройки инструментов командной строки только самый минимум, за исключением возможности явного ввода в текстовое поле опций командной строки. Dev-C++ занимает положение где-то посередине: хотя Dev-C++ предлагает больше графических опций настройки, чем некоторые IDE, предназначенные для работы с инструментарием GCC, при его использовании обычно бывает необходимо явно ввести опции командной строки.

1.21. Создание отладочной сборки

Вы хотите собрать версию проекта, которую можно будет легко отлаживать.

В основном для получения отладочной сборки требуется:

• отключить оптимизации;

• отключить расширение встраиваемых (inline) функций;

• включить генерацию отладочной информации.

Таблица 1.20 представляет опции компилятора и компоновщика, предназначенные для отключения оптимизаций и встраивания функций, а табл. 1.21 представляет опции компилятора и компоновщика для включения отладочной информации.

Табл. 1.20. Отключение оптимизаций и встраивания из командной строки

-O0

-fno-inline

-Od

-Ob0

-O0

-Ob0

-opt off

-inline off

-O0

--no_inlining

-Od

-vi-

-o+none -S

-C

¹ Эту опцию указывать не требуется, если не была указана опция

-O3

Табл. 1.21. Опции командной строки для включения отладочной информации

Табл. 1.22. Включение отладочной информации при использовании Visual C++ или Intel для Windows

¹ Чтобы получить доступ к этим опциям, перейдите к Configuration Properties→С/С++→ General→Debug Information Format (формат отладочной информации).

BoostBuild предоставляет похожий механизм создания отладочной сборки: просто добавьте к требованиям цели

debug

Некоторые IDE также предоставляют простой способ создания отладочной сборки. Например, при создании нового проекта в Visual C++ IDE автоматически генерирует конфигурации для отладочной и окончательной сборок. Чтобы запросить отладочную сборку, просто выберите в меню Build опцию Configuration Manager и в качестве активной выберите конфигурацию Debug. Также можно выбрать Debug в раскрывающемся списке конфигураций на стандартной панели инструментов. При следующей сборке проекта будет создана отладочная сборка.

Аналогично при создании проекта в CodeWarrior с помощью одного из шаблонов проектов Metrowerks, называемых «принадлежности» (stationery), IDE автоматически генерирует отладочную и окончательную цели. Имя отладочной цели может быть разным, но оно всегда должно включать слово «debug». Чтобы запросить отладочную сборку, в меню Project выберите пункт Set Default Target (установить цель по умолчанию), а затем выберите элемент меню, соответствующий отладочной цели. Также можно выбрать отладочную цель в раскрывающемся списке целей в окне проекта.

C++Builder не поддерживает множественных конфигураций для одного проекта, но он предоставляет простой способ создания отладочной сборки. Чтобы запросить отладочную сборку, перейдите в Project Options→Compiler и нажмите на Full debug (полная отладка). Это отключит все оптимизации и встраивание и включит отладочную информацию.

При использовании IDE, которая не предоставляет готовых отладочной и окончательной конфигураций, такой как Dev-C++, или если вам требуется получить дополнительный контроль над параметрами проекта, обратитесь к таблицам с 1.23 до 1.25.

Табл. 1.23. Отключение оптимизаций из IDE

Табл. 1.24. Отключение встраивания из IDE

Табл. 1.25. Включение отладочной информации в IDE

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

Большинство наборов инструментов сохраняют отладочную информацию непосредственно в объектных и исполняемых файлах, но некоторые также предоставляют опцию для генерации отладочной информации в отдельных файлах базы данных. Например, в Visual C++ опция компилятора -Z7 указывает, что отладочная информация должна быть помещена в объектные и исполняемые файлы, а опции -Zi и -ZI указывают, что она должна быть сохранена в файлах базы данных программы, имеющих расширение .pdb. Опция -ZI включает функцию, которая называется Edit and Continue (отредактировать и продолжить), которая позволяет пользователям IDE изменять и перекомпилировать код, не прерывая сессии отладки. Аналогично CodeWarrior для Mac OS X по умолчанию генерирует отладочную информацию в файлах .SYM.

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

По этим причинам обычно при создании отладочной сборки принято отключать оптимизации и встраивание.

Рецепт 1.22.

1.22. Создание окончательной сборки

Вы хотите создать небольшой быстрый исполняемый файл или динамическую библиотеку, предназначенные для распространения среди покупателей.

В основном для получения окончательной сборки требуется:

• включить оптимизации;

• включить расширение встраиваемых (inline) функций;

• отключить генерацию отладочной информации.

В табл 1.26 представлены опции компилятора и компоновщика, включающие оптимизацию и встраивание. Опций командной строки для отключения отладочной информации не существует: при сборке из командной строки отладочная информация по умолчанию отключена. Однако при использовании инструментария GCC размер исполняемых файлов и динамических библиотек можно уменьшить, указав компоновщику опцию -s.

Табл. 1.26. Опции компилятора, включающие оптимизации и встраивание

¹ Эта опция автоматически включается при указании -O3.

Boost.Build предоставляет похожий механизм создания окончательной сборки: просто добавьте к требованиям цели

release

Некоторые IDE также предоставляют простой способ создания окончательной сборки. Например, как я говорил в рецепте 1.21, при создании нового проекта в Visual C++ IDE автоматически генерирует отладочную и окончательную конфигурации. Чтобы запросить окончательную сборку, просто выберите в меню Build опцию Configuration Manager и в качестве активной выберите конфигурацию Release. Также можно выбрать Release в раскрывающемся списке конфигураций на стандартной панели инструментов. При следующей сборке проекта будет создана окончательная сборка.

Аналогично при создании проекта в CodeWarrior с помощью одного из шаблонов проектов Metrowerks, называемых «принадлежности» (stationery), IDE автоматически генерирует отладочную и окончательную цели. Имя окончательной цели может быть разным, но оно всегда должно включать слово «release» или «final». Чтобы запросить окончательную сборку, в меню Project выберите пункт Set Default Target (установить цель по умолчанию), а затем выберите элемент меню, соответствующий окончательной цели. Также можно выбрать окончательную цель в раскрывающемся списке целей в окне проекта.

C++Builder не поддерживает множественных конфигураций для одного проекта, но он предоставляет простой способ создания окончательной сборки. Чтобы запросить окончательную сборку, перейдите в Project Options→Compiler и нажмите на Release. Это включит все оптимизации и встраивание и отключит отладочную информацию.

При использовании IDE, которая не предоставляет готовых отладочной и окончательной конфигураций, такой как Dev-C++, или если требуется получить дополнительный контроль над параметрами проекта, обратитесь к таблицам с 1.27 до 1.29.

Табл. 1.27. Включение оптимизаций из IDE

Табл. 1.28. Включение встраивания из IDE

Табл. 1.29. Отключение отладочной информации в IDE

Большинство наборов инструментов предлагает несколько опций оптимизации, а некоторые даже десятки. Какие оптимизации следует выбрать, зависит от требований к проекту. Например, во встраиваемых системах может потребоваться выбрать оптимизации, которые ценой некоторого уменьшения скорости приводят к созданию меньших по размеру исполняемых файлов. В других случаях приоритет может отдаваться скорости. Некоторые оптимизации сделают программу быстрее на одной платформе, но медленнее на другой. Вы можете даже столкнуться с тем, что некоторые опции сделают отдельные части программы быстрее, а другие части — медленнее.

Таблицы 1.26 и 1.27 показывают опции обобщенных оптимизаций, но для достижения наилучших результатов следует тщательно рассмотреть все требования, изучить документацию по инструментарию и провести всестороннее тестирование.

Эта ситуация аналогична встраиванию, хотя обычно инструментарии предоставляют значительно меньше опций для встраивания, чем для других оптимизаций

Рецепт 1.21.

1.23. Указание варианта библиотеки времени выполнения

Ваш инструментарий поставляется с несколькими вариантами базовых библиотек времени выполнения, и вы хотите указать компилятору и компоновщику тот вариант, который должен использоваться.

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

При использовании Boost.Build эти три выбора можно сделать, использовав функции

threading

runtime-link

variant

static

multi

При сборке из командной строки используйте опции компилятора и компоновщика, представленные в таблицах с 1.30 до 1.36. Опции командной строки и имена библиотек для отладочной и окончательной конфигураций обычно очень похожи. В следующих таблицах буквы в квадратных скобках добавляются только для отладочных конфигураций. Имена динамических вариантов библиотек времени выполнения показаны в круглых скобках. При выборе динамической компоновки эти библиотеки должны быть доступны при выполнении программы.

Табл. 1.30. Опции компилятора для выбора библиотеки времени выполнения при использовании Visual C++ или Intel (Windows)

¹ Начиная с Visual Studio 2005, в момент написания книги, находящейся в стадии бета-тестирования, опции -ML и -MLd считаются устаревшими, а однопоточные статические библиотеки времени выполнения больше не поставляются.

² Предыдущие версии Visual C++ использовали DLL msvcr71.dll, msvcr71d.dll, msvcr70.dll, msvcr70d.dll и т.д.

Табл. 1.31. Опции компилятора для выбора библиотеки времени выполнения при использовании Metrowerks (Windows)

Табл. 1.32. Опции командной строки для выбора библиотеки времени выполнения при использовании CodeWarrior 10 для Max OS X

Табл. 1.33. Опции компилятора для выбора библиотеки времени выполнения при использовании Borland

¹ Опция -WC требуется только при сборке консольного приложения.

Табл. 1.34. Опции компилятора для выбора библиотеки времени выполнения при использовании Digital Mars (все библиотеки времени выполнения многопоточны)

Табл. 1.35. Опции компилятора для выбора библиотеки времени выполнения при использовании GCC

¹ Эта опция отключает всю динамическую компоновку, а не только динамические библиотеки времени выполнения.

Например, чтобы указать динамическую окончательную сборку библиотеки времени выполнения Visual С++, используйте опцию компилятора -MD. Чтобы указать статическую однопоточную отладочную сборку библиотеки времени выполнения Metrowerks для Windows, используйте опцию компилятора -runtime ssd. Чтобы указать однопоточную динамическую сборку библиотеки времени выполнения Borland, передайте компилятору и компоновщику опции -WM- -WR -WC.

Инструкции для указания варианта библиотеки времени выполнения в IDE приведены в табл. 1.36.

Табл. 1.36. Указание варианта библиотеки времени выполнения из IDE

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

В большинстве случаев, чем больше у вас выбор, тем лучше. Однако слишком большое количество библиотек времени выполнения приводит к различным проблемам. Главной проблемой является гарантия того, что все компоненты приложения — статические библиотеки, динамические библиотеки и исполняемые файлы — используют один и тот же вариант библиотеки времени выполнения, Если это не так, то приложение может не скомпоноваться или в нем могут появиться сложные с точки зрения диагностики сбои.

Итак, как же решить, какую библиотеку времени выполнения использовать? Два выбора — одно- или многопоточную и отладочную или окончательную — вполне очевидны.

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

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

Однако компоновка с динамической библиотекой времени выполнения также имеет свои преимущества. В первую очередь благодаря тому, что очень эффективным средством организации приложения является создание набора динамических библиотек. Во-первых, это позволяет обновлять части приложения, не требуя переустановки всего приложения. Далее, в некоторых случаях, благодаря использованию возможности отложенной загрузки DLL в Windows, значительно увеличивается производительность приложения. Но так как все компоненты приложения должны использовать один и тот же вариант библиотеки времени выполнения, то если приложение использует хотя бы одну динамическую библиотеку, все компоненты этого приложения должны использовать динамическую библиотеку времени выполнения. В результате использование динамической библиотеки времени выполнения облегчает разбиение приложения на модули.

Я рекомендую в большинстве случаев выбирать динамическую компоновку. Однако, как я упоминал выше, иногда предпочтительнее статическая компоновка. Иногда, когда неизвестно, как будет использоваться написанная библиотека, невозможно узнать заранее, какой тип компоновки предпочтительнее. В этом случае общим решением является создание нескольких вариантов библиотеки, скомпонованных с использованием различных вариантов библиотеки времени выполнения.

Рецепты 1.4, 1.5, 1.21 и 1.25.

1.24. Включение строгого соответствия стандарту C++

Вы хотите, чтобы компилятор принимал только программы, которые соответствуют стандарту языка С++.

Опции командной строки для указания строгого соответствия стандарту C++ приведены в табл. 1.37. Инструкции для включения строгого соответствия в IDE приведены в табл. 1.38

Табл. 1.37. Включение строгого соответствия из командной строки

¹ Версии компилятора Intel для Linux до 9.0 использовали опцию -strict_ansi. При использовании -strict-ansi или -strict_ansi может потребоваться с помощью опции -cxxlib-icc включить стандартную библиотеку Intel

² С опцией -А некоторые стандартные заголовочные файлы библиотеки STLPort могут не компилироваться.

Табл. 1.38. Включение строгого соответствия в IDE

Язык C++ был стандартизирован Международной организацией по стандартизации (International Standards Organization — ISO) в 1998 году. В том же году стандарт ISO был одобрен и принят Национальным институтом стандартизации США (American National Standards Institute — ANSI). В 2003 году была одобрена вторая редакция стандарта, которая содержит исправления и пояснения, но также вводит несколько новых языковых возможностей. В настоящее время ведется работа над обновленной версией стандарта С++, которая будет включать несколько важных языковых функций и расширенную стандартную библиотеку.

В момент принятия стандарта в 1998 году ни один из компиляторов не достигал полного соответствия его требованиям, хотя многие были представлены как «ANSI-совместимые». Однако в течение нескольких прошедших лет поставщики много работали над тем, чтобы сделать свои инструменты более точно и строго соответствующими стандарту. По состоянию на сентябрь 2005 года последние версии компиляторов GNU, Microsoft, Intel, Metrowerks и Comeau обладают высокой степенью соответствия. Comeau и Intel с их поддержкой экспорта шаблонов могут рассматриваться как соответствующие стандарту почти на 100%[5].

Ни один из компиляторов не может обеспечить полного соответствия стандарту с точки зрения отказа компилировать любую неверную программу. И не только из-за того, что ни один из них не соответствует стандарту на 100%: более важной причиной является то, что стандарт C++ не требует от компилятора отвергать неверные программы. Имеется четкий перечень обстоятельств, в которых компилятор должен выдавать диагностическое сообщение, указывающее на неправильно написанную программу, однако для многих некорректных программ диагностики не требуется. Это программы, которые приводят к тому, что стандарт называет неопределенным поведением программы при ее выполнении. И даже тогда, когда диагностика обязательна, компилятор волен выдать сообщение и продолжить компиляцию, в результате которой возможно успешное создание исполняемого файла или библиотеки.

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

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

Для начала вот код, который полностью попустим в ранних диалектах С++, существовавших до стандартизации языка. Например, в ранних версиях C++ область видимости переменной, объявленной при инициализации цикла

for

// ВНИМАНИЕ: некорректный код!

int main() {

 for (int i = 0; i < 10; ++i)

  ;

 int j = i; // j == 10

}

Стандартом это не допускается и не имеет никаких преимуществ по сравнению со стандартными правилами областей видимости. Требование компилировать код, подобный этому, возникает только при сопровождении устаревших приложений.

Другой категорией некорректного кода является код, который использует экспериментальные расширения языка, которые по какой-либо причине не вошли в конечный стандарт C++. Например, многие компиляторы предоставляют встроенный тип

long long

typeof

sizeof

typeof

decltype

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

Третья категория некорректного кода — это код, который использует платформенно-зависимые расширения языка, необходимые для использования функций операционной системы. В эту категорию попадают атрибуты

__declspec(dllexport)

__declspec(dllimport)

__stdcall

__fastcall

__cdecl

Последней категорией некорректного кода является код, нарушающий стандарт С++, но полностью соответствующий некоторым другим стандартам. Главным примером такого стандарта является C++/CLI, который сейчас проходит последние стадии стандартизации в ECMA. C++/CLI — это расширение С++, которое состоит из интерфейса C++ к Command Language Infrastructure — ядру Microsoft .NET Framework. При компиляции приложения, использующего определенные расширения C++/CLI, соответствующий стандарту компилятор C++ должен выдавать диагностику, но при поддержке стандарта C++/CLI он может свободно генерировать работоспособное приложение.

Если вам требуется скомпилировать код, не соответствующий стандарту, вначале проверьте, будет ли он компилироваться при использовании опций, приведенных в табл. 1.37 и 138. Если нет, то некоторые компиляторы предлагают набор «дробных» опций совместимости, позволяющих использовать некоторые несовместимые конструкции, но запрещающих другие. Например, Comeau предоставляет опцию --long_long, указывающую на необходимость распознавания типа

long long

Рецепт 1.2.

1.25. Указание определенной библиотеки для автоматической компоновки с исходным файлом

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

При программировании для Windows с использованием инструментария Visual C++, Intel, Metrowerks, Borland или Digital Mars для указания имен и (при необходимости) путей готовых библиотек, с которыми должен компоноваться код, включающий заголовочные файлы вашей библиотеки, используйте в этих заголовочных файлах

pragma comment

Например, предположим, что вы хотите распространить библиотеку из примера 1.1, состоящую из статической библиотеки libjohnpaul.lib и заголовочного файла johnpaul.hpp. Измените этот заголовочный файл так, как показано в примере 1.26.

Пример 1.26. Использование pragma comment

#ifndef JОНNPAUL_HPP_INCLUDED

#define JOHNPAUL_HPP_INCLUDED

#pragma comment(lib, "libjohnpaul")

void johnpaul();

#endif // JOHNPAUL_HPP_INCLUDED

После этого изменения компоновщики Visual С++, Intel, Metrowerks, Borland и Digital Mars при компоновке кода, включающего заголовочный файл johnpaul.hpp, будут автоматически находить библиотеку libjohnpaul.lib.

В некоторых ситуациях компоновка может оказаться более сложным этапом процесса сборки, чем компиляция. Одна из наиболее часто возникающих проблем компоновки создается тогда, когда компоновщик находит неверную версию какой-либо библиотеки. Это в основном проблема Windows, где библиотеки времени выполнения и зависящие ar них библиотеки часто имеют множество вариантов. По этой причине библиотеки для Windows часто поставляются с именами, измененными так, чтобы они отражали различные конфигурации сборки. Хотя это и помогает снизить число конфликтов версий, это также затрудняет процесс компоновки, так как теперь вы должны указывать компоновщику правильное измененное имя.

По этой причине

pragma comment

До сих пор все было хорошо. Но есть одна проблема:

pragma comment

#ifndef JOHNPAUL_HPP_INCLUDED

#define JOHNPAUL_HPP_INCLUDED

#if defined(_MSC_VER) || \

 defined(__ICL) || \

 defined(__MWERKS__) && defined(_WIN32) || \

 defined(__BORLANDC__) \

 defined(__DMC__) \

/**/

#pragma comment (lib, "libjohnpaul")

#endif

void johnpaul();

#endif // JOHNPAUL_HPP_INCLUDED

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

pragma comment

_MSC_VER

#ifndef johnpaul_hpp_included

#define JOHNPAUL_HPP_INCLUDED

#define BOOST_LIB_NAME libjohnpaul

#define BOOSTAUTO_LINK_NOMANGLE

#include 

void johnpaul();

#endif // JOHNPAUL_HPP_INCLUDED

Здесь строка

#define BOOST_LIB_NAME libjohnpaul

определяет имя библиотеки, строка

#define BOOST_AUTO_LINK_NOMANGLE

указывает, что вы не хотите использовать соглашение об именах Boost, а строка

#include 

вызывает

pragma comment

Рецепт 1.23.

1.26. Использование экспортируемых шаблонов

Вы хотите собрать программу, использующую экспортируемые шаблоны, что означает, что она объявляет шаблоны в заголовочных файлах с использованием ключевого слова

export

Во-первых, скомпилируйте в объектные файлы файлы .cpp, содержащие реализации шаблонов, передав компилятору опцию командной строки, необходимую для включения экспортируемых шаблонов. Затем скомпилируйте и скомпонуйте файлы .cpp, использующие экспортируемые шаблоны, передав компилятору и компоновщику опции командной строки, необходимые для включения экспортируемых шаблонов, а также опции, указывающие директории, содержащие реализации шаблонов.

Опции для включения экспортируемых шаблонов приведены в табл 1.39. Опции для указания расположения реализаций шаблонов приведены в табл. 1.40. Если ваш инструментарий в этой таблице не указан, то он, скорее всего, не поддерживает экспортируемых шаблонов.

Табл. 1.39. Опции для включения экспортируемых шаблонов

¹ Версии компилятора Intel для Linux до 9.0 использовали опцию -strict_ansi

Табл. 1.40. Опции, указывающие расположение реализаций шаблонов

Например, предположим, что вы хотите скомпилировать программу, показанную в примере 1.27. Она содержит три файла.

• Файл plus.hpp содержит объявление экспортируемого шаблона функции

plus()

• Файл plus.cpp содержит определение

plus()

• Файл test.cpp включает объявление — но не определение —

plus()

main()

plus()

Пример 1.27. Простая программа, использующая экспортируемые шаблоны

plus.hpp:

#ifndef PLUS_HPP_INCLUDED

#define PLUS_HPP_INCLUDED

export template

T plus(const T& lhs, const T& rhs);

#endif // #ifndef PLUS_HPP_INCLUDED

plus.cpp:

#include "plus.hpp"

template

T plus(const T& lhs, const T& rhs) {

 return rhs + lhs;

}

test.cpp:

#include 

#include "plus.hpp"

int main() {

 std::cout << "2 + 2 = " << plus(2, 2) << "\n";

}

Чтобы скомпилировать plus.cpp в объектный файл plus.obj с помощью Comeau в Unix, перейдите в директорию, содержащую plus.cpp, plus.hpp и test.cpp, и введите следующую команду.

$ como -c --export plus.cpp

Эта команда также генерирует файл plus.et, описывающий реализацию шаблона, содержащегося в plus.cpp.

Затем скомпилируйте test.cpp в объектный файл test.obj с помощью команды:

$ como -c --export test.cpp

Наконец, скомпонуйте исполняемый файл test.exe.

$ como --export -о test test.obj

Две последние команды также можно объединить в одну.

$ como --export -o test test.cpp

Теперь можно запустить test.exe.

$ ./test

2 + 2 = 4

Теперь предположите, что файлы plus.hpp и plus.cpp находятся в директории с именем plus, a test.cpp находится в дочерней директории test. Чтобы скомпилировать и скомпоновать test.cpp, перейдите в директорию test и введите:

$ como --export --template_directory=../plus -I../plus -o test

test.cpp

C++ поддерживает две модели обеспечения определений шаблонов функций и статических данных-членов шаблонов классов: включающую (inclusion model) и раздельную (separation model) модели. Включающая модель знакома всем программистам, регулярно использующим шаблоны С++, но часто оказывается непонятной программистам, привыкшим писать код без шаблонов. Во включающей модели определение шаблона функции — или статических данных-членов шаблона класса — должно включаться в каждый исходный файл, ее использующий. В противоположность этому при использовании нешаблонных функций и данных достаточно включить в исходный файл только объявление; определение может быть помещено в отдельный файл .cpp.

Раздельная модель ближе к традиционной манере организации исходного кода C++. Для шаблонов, объявленных с ключевым словом

export

Раздельная модель предлагает несколько потенциальных преимуществ.

Уменьшение времени компиляции

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

Снижение «загрязнения» символов

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

Возможность поставлять скомпилированные реализации шаблонов.

Теоретически при использовании раздельной модели поставщик может распространять реализации шаблонов в скомпилированном двоичном виде, находящемся где-то посередине между исходным кодом C++ и обычными объектными файлами.

Все три потенциальных преимущества раздельной модели спорны. Во-первых, хотя некоторые пользователи сообщали о сокращении времени компиляции, раздельная модель также может в некоторых случаях привести к его увеличению. В настоящее время данных для окончательных выводов недостаточно. Во-вторых, хотя раздельная модель снижает некоторые виды загрязнения символов, правила языка, необходимые для поддержки раздельной модели, и особенно идея двухэтапного поиска, усложняют способ написания кода шаблона — даже по сравнению с включающей моделью - и имеют несколько нежелательных последствий. В-третьих, все существующие реализации раздельной модели основаны на оболочке EDG, a EDG пока еще не предоставляет никаких возможностей для компиляции исходных файлов, содержащих реализации экспортируемых шаблонов, в двоичные файлы, которые могут поставляться вместо исходников.

В 2003 году имела место попытка удалить экспортируемые шаблоны из будущих версий стандарта С++, но она провалилась. Следовательно, экспортируемые шаблоны являются постоянной частью языка С++, и вы должны научиться использовать их.

Рецепт 1.25.