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

Когсуэлл Джефф

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

johnpaul georgeringo hellobeatles:

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

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

MAKE

раскрывается как имя запущенного в данный момент экземпляра make. Обычно это будет

make

, но на некоторых системах это может быть

gmake

. Во-вторых, опция командной строки – -directory=<path>

заставляет make вызваться с

<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

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

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, просто добавьте в требования цели свойство вида

<define>name[=value]

, как показано в табл. 1.15 и примере 1.12.

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

Инструментарий	Опции
Все	– Dname[-value]

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

IDE	Конфигурация
Visual C++	На страницах свойств проекта перейдите к Configuration Properties→C/C++→Preprocessor и в Preprocessor Definitions (определения препроцессора) введите name[=value] , для разделения нескольких записей используя точку с запятой
CodeWarrior	В окне Target Settings перейдите к Language Settings→C/C++ Preprocessor и введите: #define name[=value] в поле с именем Prefix Text
C++Builder	В Project Options перейдите к Directories/Conditionals и в Preprocessor Definitions введите name[=value] , для разделения нескольких записей используя точку с запятой
Dev-C++	В Project Options выберите Parameters и введите: – Dname[=value] в области C++ Compiler

Обсуждение

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

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

#ifdef _WIN32

# include <windows.h>

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

# include <sys/stat.h>

#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>

.