Д. Стефенс - C++. Сборник рецептов

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 в каждом из подчиненных make-файлов требуется выполнить главный make-файл с опцией TARGET= xxx .

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

hellobeatles: johnpaul georgeringo

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

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

Вы хотите определить символ препроцессора name , присвоив ему либо неопределенное значение, либо значение value .

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

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

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

Символы препроцессора часто используются в коде 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. Макрос, определяемый автоматически, называется предопределенным макросом. Пример 1.25 использует предопределенный макрос WIN32для определения, под какой операционной системой он компилируется, и для включения соответствующего специфичного для платформы кода.

Однако часто настроечная информация, необходимая для выполнения подобного рода условной компиляции, в виде предопределенных макросов недоступна. В таких случаях необходимо создать собственные макросы и с помощью методов, показанных в табл. 1.15, 1.16 и 1.17, присвоить им соответствующие значения. Хорошим примером является пример 1.2. В Windows при сборке DLL georgeringo.dll функция georgeringo()должна быть объявлена с атрибутом __declspec(dllexport), а в остальных случаях — с атрибутом __declspec(dllimport). Как описано в рецепте 1.4, этого эффекта можно достичь, определив в командной строке сборки DLL символ препроцессора GEORGERINGO_DLLи не определяя его при компиляции кода, использующего эту DLL.

Если вы не указали значение макроса, то большинство компиляторов присваивают ему значение 1, но некоторые присваивают ему пустое значение. При использовании макросов для включения условной компиляции, как в примере 1.25, эта разница не имеет значения. Однако, если требуется, чтобы макрос раскрывался как определенное значение, вы должны указать это значение явно, использовав запись вида -D< name >=< value >.

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

Вы хотите передать компилятору или компоновщику опцию командной строки, но она не соответствует ни одному из параметров, доступных в 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, при его использовании обычно бывает необходимо явно ввести опции командной строки.