Autoconf

Этот файл описывает GNU Autoconf--- пакет для создания скриптов для конфигурации пакетов с исходным кодом, использующий шаблоны и наборы макросов на языке m4. Версия документа 2.13, описывает Autoconf версии 2.13.

1. Введение
2. Создание скриптов configure
3. Файлы инициализации и выходные файлы
4. Существующие тесты
5. Написание тестов
6. Результаты тестов
7. Создание макросов
8. Ручная настройка
9. Локальная конфигурация
10. Запуск скриптов configure
11. Воссоздание конфигурации
12. Вопросы об Autoconf
13. Обновление с версии 1
14. История Autoconf
15. Старые имена макросов
Индекс переменных среды
Индекс выходных переменных
Индекс символов препроцессора
Индекс макросов

 -- Детальное меню ---

Создание скриптов configure

2.1 Написание `configure.in'		Что нужно написать во входном файле Autoconf.
2.2 Использование программы autoscan для создания `configure.in'		Полуавтоматическое написание `configure.in'.
2.3 Использование программы ifnames для перечисления условных выражений		Список условных выражений в исходных текстах.
2.4 Использование программы autoconf для создания скрипта configure		Как создать скрипты конфигурации.
2.5 Использование autoreconf для обновления ваших скриптов configure		Пересоздание нескольких скриптов configure.

Файлы инициализации и выходные файлы

3.1 Нахождение ввода configure		Где Autoconf должен искать файлы.
3.2 Создание выходных файлов
3.3 Подстановки в файлах Makefile		Использование выходных переменных в файлах `Makefile'.
3.4 Заголовочные файлы конфигурации
3.5 Настройка других пакетов, находящихся в подкаталогах
3.6 Префикс по умолчанию
3.7 Номера версий в configure

Подстановки в файлах Makefile

3.3.1 Предварительная установка выходных переменных
3.3.2 Каталоги сборки программ
3.3.3 Автоматическая пересборка		Правила Makefile для настройки.

Заголовочные файлы настройки

3.4.1 Шаблоны заголовочных файлов
3.4.2 Использование autoheader для создания `config.h.in'		Как создать шаблон для заголовочного файла настройки.

Существующие тесты

4.1 Альтернативные программы
4.2 Файлы библиотек
4.3 Библиотечные функции
4.4 Заголовочные файлы
4.5 Структуры
4.6 Объявления типов
4.7 Характеристики компилятора C		Определение характеристик компилятора С.
4.8 Характеристики компилятора Fortran 77
4.9 Системные сервисы
4.10 Варианты UNIX

Альтернативные программы

4.1.1 Проверка отдельных программ
4.1.2 Общие программы и проверки файлов

Библиотечные функции

4.3.1 Проверка отдельных функций
4.3.2 Проверка базовых функций

Заголовочные файлы

4.4.1 Проверка отдельных заголовочных файлов
4.4.2 Базовые проверки заголовочных файлов

Объявления типов

4.6.1 Проверка отдельных объявлений типов
4.6.2 Базовые проверки объявлений типов

Написание тестов

5.1 Исследование деклараций
5.2 Проверка синтаксиса
5.3 Проверка библиотек
5.4 Проверка поведения во время выполнения
5.5 Переносимое программирование на языке командного процессора
5.6 Тестирование значений и файлов
5.7 Множество вариантов
5.8 Выбор языка

Проверка поведения во время выполнения

5.4.1 Запуск тестовых программ
5.4.2 Рекомендации по написанию тестовых программ
5.4.3 Тестовые функции

Результаты тестов

6.1 Определение символов препроцессора С
6.2 Установка выходных переменных
6.3 Кэширование результатов		Ускорение работы при последующих запусках configure.
6.4 Выдача сообщений

Кэширование результатов

6.3.1 Имена переменных кэша
6.3.2 Кэш-файлы		Файлы, которые configure использует для кэширования.

Создание макросов

7.1 Определение макросов		Базовый формат макросов Autoconf.
7.2 Имена макросов
7.3 Заключение в кавычки
7.4 Зависимости между макросами

Зависимости между макросами

7.4.1 Требуемые макросы
7.4.2 Предлагаемый порядок
7.4.3 Устаревшие макросы

Ручная настройка

8.1 Указание типа системы
8.2 Получение канонического типа системы
8.3 Переменные типов систем
8.4 Использование типов систем

Локальная настройка 

9.1 Работа с внешним программным обеспечением
9.2 Выбор ключей пакетов
9.3 Детали локальной конфигурации
9.4 Преобразование имен программ при установке
9.5 Установка значений по умолчанию для машины		Задание значений по умолчанию для configure

Преобразование имен программ при установке

9.4.1 Ключи преобразования		Ключи configure для преобразования имен.
9.4.2 Примеры преобразований
9.4.3 Правила преобразования		`Makefile' использующий преобразование имен.

Запуск скриптов configure

10.1 Простая установка
10.2 Компиляторы и ключи
10.3 Компиляция для нескольких архитектур
10.4 Имена для установки
10.5 Дополнительные возможности
10.6 Указание типа системы
10.7 Совместное использование значений по умолчанию		Установка значений по умолчанию для всех скриптов configure.
10.8 Контроль выполнения		Изменение поведения configure.

Вопросы об Autoconf

12.1 Распространение скриптов configure
12.2 Почему требуется GNU m4?		Почему не используется стандартный m4?
12.3 Как я могу начать работу?		Autoconf и m4 требуют наличия друг друга?
12.4 Почему не используется Imake?		Почему GNU использует configure вместо Imake?

Обновление с версии 1

13.1 Измененные имена файлов
13.2 Измененные файлы Makefile		Новые вещи, которые можно поместить в `Makefile.in'.
13.3 Измененные макросы
13.4 Использование autoupdate для обновления configure		Замена старых имен макросов в configure.in.
13.5 Измененные результаты
13.6 Измененное написание макросов

История Autoconf

14.1 Бытие		Предыстория и выбор названия configure.
14.2 Исход		Мучения с m4 и Perl.
14.3 Левит
14.4 Числа
14.5 Второзаконие

1. Введение

Физик, инженер и специалист по компьютерам спорили о природе Бога. Конечно, он был Физиком, сказал физик, поскольку в начале Творения Бог создал Свет; и вы знаете, есть уравнения Максвелла, двойная природа электромагнитных волн, уравнения относительности... "Он был Инженером!" -- сказал инженер, поскольку до создания света, Бог разделил Хаос на Землю и Воду; нужно быть настоящим инженером, чтобы обработать огромное количество грязи и последовательно разделить твердые вещества от жидких... Компьютерный специалист воскликнул: А как вы думаете, откуда взялся хаос? ---Anonymous

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

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

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

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

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

Autoconf навязывает некоторые ограничения на имена макросов, которые используются в директивах #ifdef программ на языке C (see section Индекс символов препроцессора).

Для создания скриптов Autoconf требует наличия программы GNU m4. Он пользуется возможностями, которых нет в некоторых UNIX-версиях программы m4. Он также превышает внутренние ограничения некоторых версий m4, включая GNU m4 версии 1.0. Вам необходимо использовать версию 1.1 (или более позднюю) программы GNU m4. Версии 1.3 и более поздние будут работать гораздо быстрее, чем версии 1.1 или 1.2.

See section 13. Обновление с версии 1, где описано обновление с версии 1. See section 14. История Autoconf, где описана история разработки Autoconf. See section 12. Вопросы об Autoconf, где даются ответы на некоторые общие вопросы об Autoconf.

Сообщения об ошибках и свои пожелания для Autoconf посылайте по адресу bug-gnu-utils@prep.ai.mit.edu. Включите в сообщение номер версии Autoconf, который вы можете получить, выполнив команду `autoconf --version'.

2. Создание скриптов configure

Скрипты конфигурации, создаваемые Autoconf, по принятым соглашениям называются configure. При запуске configure создает несколько файлов, заменяя в них параметры конфигурации на соответствующие системе значения. configure создает следующие файлы:

• один или несколько файлов `Makefile', по одному на каждый подкаталог пакета (see section 3.3 Подстановки в файлах Makefile);

• если задано, создается заголовочный файл для языка C, имя которого можно задать при создании скрипта и который содержит директивы #define (see section 3.4 Заголовочные файлы конфигурации);

• скрипт командного процессора с именем `config.status', который при запуске заново создаст вышеперечисленные файлы (see section 11. Воссоздание конфигурации);

• скрипт командного процессора с именем `config.cache', который сохраняет результаты выполнения многих тестов (see section 6.3.2 Кэш-файлы);

• файл с именем `config.log', который содержит все сообщения, выданные компиляторами. Этот файл может использоваться при отладке, если configure работает неправильно.

Для того, чтобы с помощью Autoconf создать скрипт configure, вам необходимо написать входной файл с именем `configure.in' и выполнить команду autoconf. Если вы напишите собственный код тестирования возможностей системы, в дополнение к поставляемым с Autoconf, то вам придется записать его в файлы с именами `aclocal.m4' и `acsite.m4'. Если вы используете заголовочный файл, который содержит директивы #define, то вы также должны создать файл `acconfig.h', и вы сможете распространять с пакетом созданный с помощью Autoconf файл `config.h.in'.

Вот диаграмма, показывающая, как создаются файлы, используемые при конфигурации. Выполняемые программы обозначены суффиксом `*'. Необязательные файлы взяты в квадратные скобки (`[]'). Программы autoconf и autoheader также читают установленные файлы с макросами Autoconf (обрабатывая файл `autoconf.m4').

Файлы, используемые при подготовке программного пакета к распространению:

Файлы исходных текстов --> [autoscan*] --> [configure.scan] --> configure.in configure.in --. .------> autoconf* -----> configure +---+ [aclocal.m4] --+ `---. [acsite.m4] ---' | +--> [autoheader*] -> [config.h.in] [acconfig.h] ----. | +-----' [config.h.top] --+ [config.h.bot] --' Makefile.in -------------------------------> Makefile.in

Файлы, используемые при конфигурации программного пакета:

.-------------> config.cache configure* ------------+-------------> config.log | [config.h.in] -. v .-> [config.h] -. +--> config.status* -+ +--> make* Makefile.in ---' `-> Makefile ---'

2.1 Написание `configure.in'		Что нужно написать во входном файле Autoconf.
2.2 Использование программы autoscan для создания `configure.in'		Полуавтоматическое написание `configure.in'.
2.3 Использование программы ifnames для перечисления условных выражений		Список условных выражений в исходных текстах.
2.4 Использование программы autoconf для создания скрипта configure		Как создать скрипты конфигурации.
2.5 Использование autoreconf для обновления ваших скриптов configure		Пересоздание нескольких скриптов configure.

2.1 Написание `configure.in'

Для создания скрипта configure для программного пакета, создайте файл с именем `configure.in', который содержит вызовы макросов Autoconf, которые проверяют системные возможности, которые нужны вашему пакету или которые он может использовать. Для многих таких возможностей макросы Autoconf уже написаны; See section 4. Существующие тесты, где находится их описание. Для большинства других возможностей вы можете использовать шаблонные макросы Autoconf, на базе которых можно создать специальные проверки; See section 5. Написание тестов, где это описано. Для особо хитроумных или специализированных возможностей, в файл `configure.in' может понадобиться включить специально написанные скрипты командного процессора. Программа autoscan может оказать вам хорошую помощь на первых порах, при создании файла `configure.in' (see section 2.2 Использование программы autoscan для создания `configure.in', где описана эта программа).

За некоторыми исключениями, порядок вызовов макросов Autoconf в `configure.in' не важен. Каждый файл `configure.in' должен в самом начале содержать вызов макроса AC_INIT, а также вызов макроса AC_OUTPUT в самом конце (see section 3.2 Создание выходных файлов). Также некоторые макросы полагаются на то, что другие макросы были вызваны первыми, поскольку для того, чтобы принять решение, они проверяют уже установленные значения переменных. Такие макросы отдельно отмечены в описании (see section 4. Существующие тесты), а при создании скрипта configure выдается предупреждение, если вы нарушили порядок вызова макросов.

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

AC_INIT(file) Проверка программ Проверка библиотек Проверка заголовочных файлов Проверка определений типов Проверка структур Проверка характеристик компилятора Проверка библиотечных функций Проверка системных сервисов AC_OUTPUT([file...])

Лучше всего помещать каждый вызов макроса на отдельную строку файла `configure.in'. Большинство макросов не добавляют дополнительных переводов строк; они полагают, что после каждого вызова макроса находится новая строка. Это позволяет сделать скрипт configure читабельнее, не добавляя ненужных пустых строк. Можно спокойно устанавливать переменные окружения в той же строке, что и вызов макроса, потому что командные процессоры позволяют выполнять присваивание в одной строке, без дополнительных пустых строк.

При вызове макросов с аргументами между открывающей скобкой и названием макроса не должно быть пробелов. Аргументы могут занимать несколько строк если они заключены в "кавычки" языка m4--- `[' и `]'. Если у вас есть длинная строка, например, список имен файлов, то можно использовать символ обратного слэша в конце строки для указания, что список продолжается на следующей строке (эта возможность реализуется командным процессором, без привлечения возможностей Autoconf).

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

В файл `configure.in' можно включать комментарии, начиная их со встроенного макроса m4--- dnl, который отбрасывает текст вплоть до начала новой строки. Эти комментарии не появятся в созданных скриптах configure. Например, полезно начинать файлы `configure.in' со строки, которая может выглядеть так:

dnl для создания скрипта configure обработайте этот файл программой autoconf.

2.2 Использование программы autoscan для создания `configure.in'

Программа autoscan может помочь вам в создании файла `configure.in' для программного пакета. autoscan выполняет анализ дерева исходных текстов, корень которого указан в командной строке или совпадает с текущим каталогом. Программа ищет в исходных текстах следы обычных проблем с переносимостью и создает файл `configure.scan', который является заготовкой для `configure.in' для данного пакета.

Вы должны сами просмотреть файл `configure.scan' перед тем, как переименовать его в `configure.in': скорее всего, он будет нуждаться в некоторых исправлениях. Иногда autoscan выдает макросы в неправильном порядке, и поэтому autoconf будет выдавать предупреждения; вам необходимо вручную передвинуть эти макросы. Также, если вы хотите, чтобы пакет использовал заголовочный файл настроек, то вы должны сами добавить вызов макроса AC_CONFIG_HEADER (see section 3.4 Заголовочные файлы конфигурации). Вам также необходимо добавить или изменить некоторые директивы препроцессора #if в вашей программе, для того, чтобы заставить ее работать с Autoconf (see section 2.3 Использование программы ifnames для перечисления условных выражений, где описана программа, которая поможет вам выполнить эту работу).

Программа autoscan использует несколько файлов данных, чтобы определить, какие макросы следует использовать при обнаружении определенных символов в исходных файлах пакета. Эти файлы данных устанавливаются вместе с дистрибутивными макро-файлами Autoconf и имеют одинаковый формат. Каждая строка состоит из символа, пробелов и имени макроса Autoconf, которое выдается в том случае, если заданный символ имеется в исходных текстах. Строки, начинающиеся с символа `#' являются комментариями.

autoscan устанавливается только в том случае, если у вас установлена программа Perl. autoscan распознает следующие ключи командной строки:

--help

Выдает список ключей командной строки и прекращает работу.

--macrodir=dir

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

--verbose

Выдает имена исследуемых файлов и потенциально интересные символы, обнаруженные в этих файлах. Выдача может быть довольно обширной.

--version

выдает номер версии Autoconf и прекращает работу.

2.3 Использование программы ifnames для перечисления условных выражений

Программа ifnames может помочь при создании файла `configure.in' для программного пакета. Она выдает список идентификаторов, которые пакет уже использует в условных выражениях препроцессора языка С. Если ваша программа уже была написана с учетом возможного переноса на другие платформы, то данная программа может помочь вам определить, какие проверки необходимо выполнить в configure. Эта программа может помочь заполнить некоторые пробелы в файле `configure.in', который был создан программой autoscan (see section 2.2 Использование программы autoscan для создания `configure.in').

Программа ifnames обрабатывает все исходные тексты на C, перечисленные в командной строке (или же принимает текст со стандартного ввода, если ни один файл не был указан) и выдает на стандартный вывод сортированный список идентификаторов, которые используются в директивах #if, #elif, #ifdef или #ifndef. Программа выдает каждый идентификатор на отдельной строке, за которым через пробел следует список файлов, в которых этот идентификатор встречается.

Программа ifnames распознает следующие ключи командной строки:

--help

-h

выдает список ключей командной строки и прекращает работу.

--macrodir=dir

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

--version

выдает номер версии Autoconf и прекращает работу.

2.4 Использование программы autoconf для создания скрипта configure

Для того, чтобы создать скрипт configure из файла `configure.in', просто запустите программу autoconf без аргументов. autoconf обработает файл `configure.in' с помощью макропроцессора m4, используя макросы Autoconf. Если вы зададите аргумент программе autoconf, то программа будет выполнять чтение заданного файла, а не файла `configure.in' и вывод будет производиться на стандартный вывод, не в в файл configure. Если вы дадите программе autoconf аргумент `-', то она будет читать со стандартного ввода, а не из файла `configure.in', а результаты будут выдаваться на стандартный вывод.

Макросы Autoconf определены в нескольких файлах. Некоторые из них распространяются вместе с Autoconf; autoconf читает их в первую очередь. Затем ищется необязательный файл `acsite.m4' в каталоге, который содержит распространяемые с Autoconf файлы макросов, и необязательный файл `aclocal.m4' в текущем каталоге. Эти файлы могут содержать макросы, специфические для вашей машины или макросы для конкретных пакетов программного обеспечения (see section 7. Создание макросов, где приведена дополнительная информация). Если определение макроса существует в нескольких файлах, которые считывает autoconf, то последнее макроопределение переопределяет все предыдущие.

autoconf распознает следующие ключи командной строки:

--help

-h

выдает список ключей командной строки и прекращает работу.

--localdir=dir

-l dir

Ищет файл `aclocal.m4' для данного пакета в каталоге dir, а не в текущем каталоге.

--macrodir=dir

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

--version

выдает номер версии Autoconf и прекращает работу.

2.5 Использование autoreconf для обновления ваших скриптов configure

Если у вас много скриптов configure, созданных с помощью Autoconf, то программа autoreconf может облегчить вашу работу. Она запускает программы autoconf (и, если необходимо, autoheader) для повторного создания скриптов configure и шаблонов заголовочных файлов настройки для исходных текстов, корневой каталог которых находится в текущем каталоге. По умолчанию, эти программы создают заново только те файлы, которые старше, чем соответствующий файл `configure.in' или (если имеется) `aclocal.m4'. Поскольку программа autoheader не изменяет время модификации выходного файла в случае, если файл не изменялся, то не обязательно будет проделано минимальное количество работы. Если вы установили новую версию Autoconf, то вы можете заставить autoreconf заново создать все файлы, задав ключ командной строки `--force'.

Если вы зададите программе autoreconf ключи командной строки `--macrodir=dir' или `--localdir=dir', то она передаст их программам autoconf и autoheader (с правильно настроенными относительными путями).

autoreconf не поддерживает нахождение в одном дереве как каталогов, которые являются частями большого проекта (и которые используют одни и те же файлы `aclocal.m4' и `acconfig.h'), так и каталогов, которые являются независимыми пакетами (которые имеют собственные файлы `aclocal.m4' и `acconfig.h'). Программа предполагает, что все каталоги являются частями одного пакета, если вы используете ключ командной строки `--localdir', или что каждый каталог является отдельным пакетом, если вы не используете этот ключ. Это ограничение может быть убрано в будущем.

See section 3.3.3 Автоматическая пересборка, где описаны правила `Makefile' для автоматического пересоздания скриптов configure, если изменяются исходные тексты этих скриптов. Этот метод корректно обрабатывает изменение шаблонов заголовочных файлов конфигурации, но не передает команде ключи командной строки `--macrodir=dir' или `--localdir=dir'.

autoreconf распознает следующие ключи командной строки:

--help

-h

выдает список ключей командной строки и прекращает работу.

--force

-f

Пересоздать даже те скрипты `configure' и заголовочные файлы настройки, которые новее, чем соответствующие входные файлы (`configure.in' и, если есть, `aclocal.m4').

--localdir=dir

-l dir

Заставляет программы autoconf и autoheader искать файлы `aclocal.m4' и (для autoheader) `acconfig.h' (но не `file.top' и `file.bot') данного пакета в каталоге dir вместо каталога, который содержит отдельный файл `configure.in'.

--macrodir=dir

-m dir

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

--verbose

Выдает имена каждого каталога, в котором autoreconf запускает autoconf (и если необходимо то и autoheader).

--version

Выдает номер версии Autoconf и прекращает работу.

3. Файлы инициализации и выходные файлы

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

3.1 Нахождение ввода configure		Где Autoconf должен искать файлы.
3.2 Создание выходных файлов
3.3 Подстановки в файлах Makefile		Использование выходных переменных в файлах `Makefile'.
3.4 Заголовочные файлы конфигурации
3.5 Настройка других пакетов, находящихся в подкаталогах
3.6 Префикс по умолчанию
3.7 Номера версий в configure

3.1 Нахождение ввода configure

Каждый скрипт configure должен первым делом вызвать макрос AC_INIT. Единственный обязательный макрос -- AC_OUTPUT (see section 3.2 Создание выходных файлов).

Macro: AC_INIT (unique-file-in-source-dir)

Обрабатывает аргументы командной строки и ищет каталог с исходными текстами. unique-file-in-source-dir--- это некоторый файл в каталоге с исходными текстами пакета; configure проверяет существование этого файла, чтобы убедиться, что это именно тот каталог с исходными текстами, какой нужно. Иногда люди указывают неверный каталог с исходными текстами, используя ключ командной строки `--srcdir'; эта проверка позволяет не допускать таких инцидентов. Для детальной информации See section 10. Запуск скриптов configure.

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

Macro: AC_CONFIG_AUX_DIR(dir)

Использует скрипты `install-sh', `config.sub', `config.guess' и Cygnus-версию configure, которые располагаются в каталоге dir. Эти вспомогательные файлы используются при конфигурировании. Значение dir может быть задано либо абсолютным путем, либо путем относительно `srcdir'. Значением по умолчанию является первый из каталогов `srcdir', `srcdir/..' или `srcdir/../..', в котором будет найден файл `install-sh'. Проверка наличия других файлов не производится, так что использование AC_PROG_INSTALL не требует включения в дистрибутив других вспомогательных файлов. Также проверяется наличие файла `install.sh', но это имя является устаревшим, поскольку некоторые программы make имеют правило, которое создает файл `install' из этого файла, в случае если `Makefile' отсутствует.

3.2 Создание выходных файлов

Каждый скрипт configure, созданный Autoconf, должен заканчиваться вызовом макроса AC_OUTPUT. Этот макрос создает файлы `Makefile' и, может быть, дополнительные файлы, которые являются результатом конфигурации. Еще одним обязательным макросом является AC_INIT (see section 3.1 Нахождение ввода configure).

Macro: AC_OUTPUT ([file... [, extra-cmds [, init-cmds]]])

Создает выходные файлы. Вызовите этот макрос один раз в конце файла `configure.in'. Аргумент file... является списком выходных файлов через пробел; этот список может быть пустым. Этот макрос создает каждый из файлов `file', копируя входной файл (который по умолчанию называется `file.in') и подставляя значения выходных переменных. Для более детального описания использования выходных переменных See section 3.3 Подстановки в файлах Makefile. Для детального описания того, как создавать такие переменные See section 6.2 Установка выходных переменных. Этот макрос создает каталог, в котором находится файл, если этот каталог не существует (но не создает родительские каталоги для этого каталога). Обычно таким образом создаются файлы `Makefile', но можно указать также и другие файлы, такие как `.gdbinit'.

Если вызывались макросы AC_CONFIG_HEADER, AC_LINK_FILES или AC_CONFIG_SUBDIRS, то этот макрос также создает файлы, указанные в аргументах этих макросов.

Типичный вызов AC_OUTPUT выглядит примерно так:

AC_OUTPUT(Makefile src/Makefile man/Makefile X/Imakefile)

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

AC_OUTPUT(Makefile:templates/top.mk lib/Makefile:templates/lib.mk) AC_OUTPUT(Makefile:templates/vars.mk:Makefile.in:templates/rules.mk)

Это позволит вам сохранить имена файлов в формате MS-DOS, или для добавления стандартных кусков кода кода в начало или конец файла.

В параметре extra-cmds можно указать команды, которые будут вставлены в файл `config.status' и сработают после того, как было сделано все остальное. В параметре init-cmds можно указать команды, которые будут вставлены непосредственно перед extra-cmds, причем configure выполнит в них подстановку переменных, команды и обратных слэшей. Аргумент init-cmds можно использовать для передачи переменных из configure в extra-cmds. Если был вызван макрос AC_OUTPUT_COMMANDS, то команды, переданные ему в качестве аргумента, выполняются прямо перед командами, переданными макросу AC_OUTPUT.

Macro: AC_OUTPUT_COMMANDS (extra-cmds [, init-cmds])

Задает дополнительные команды командного процессора, которые выполняются в конце `config.status', а также команды для инициализации переменных в configure. Этот макрос можно вызывать несколько раз. Вот нереальный пример:

fubar=27 AC_OUTPUT_COMMANDS([echo this is extra $fubar, and so on.], fubar=$fubar) AC_OUTPUT_COMMANDS([echo this is another, extra, bit], [echo init bit])

Если вам нужно запустить make в подкаталогах, то это следует делать с помощью переменной MAKE. Большинство версий программы make устанавливают значение переменной MAKE равным имени программы make с дополнительно заданными ключами. (Но многие версии не включаются сюда значения переменных, заданных в командной строке, поэтому они не передаются автоматически). Некоторые старые версии команды make не устанавливают эту переменную. Следующий макрос позволяет вам использовать переменную MAKE даже таких старых версий.

Macro: AC_PROG_MAKE_SET

Если make определяет переменную MAKE, то переменная SET_MAKE получает пустое значение. Иначе, определяется переменная SET_MAKE со значением `MAKE=make'. Для переменной SET_MAKE вызывается макрос AC_SUBST.

Для использования данного макроса поместите следующую строку в каждый из файлов `Makefile.in', в котором производится запуск MAKE для подкаталогов:

@SET_MAKE@

3.3 Подстановки в файлах Makefile

Каждый подкаталог дистрибутива, который содержит что либо, что должно компилироваться или устанавливаться, должен поставляться с файлом `Makefile.in', из которого configure создаст файл `Makefile' для данного каталога. Для создания `Makefile', configure выполнит простую подстановку переменных, заменяя вхождения `@variable@' в файле `Makefile.in' на значения, которые определены configure для данной переменной. Переменные, которые подставляются в выходных файлах таким способом, называются выходными переменными (output variables). Они являются обычными переменными командного процессора, которые устанавливаются в configure. Для того, чтобы configure подставлял в выходных файлах определенную переменную, необходимо вызвать макрос AC_SUBST с именем переменной в качестве аргумента. Любое вхождение `@variable@' для других переменных остается неизмененным. Для получения дополнительной информации о создании выходных переменных с помощью макроса AC_SUBST See section 6.2 Установка выходных переменных.

Пакеты программного обеспечения, использующие скрипт configure, должны распространяться с файлами `Makefile.in', но не с файлами `Makefile'; таким образом, пользователь должен перед компиляцией сконфигурировать программный пакет так, чтобы он соответствовал используемой системе.

See section `Makefile Conventions' in The GNU Coding Standards, для получения информации о том, что можно помещать в файлы `Makefile'.

3.3.1 Предварительная установка выходных переменных
3.3.2 Каталоги сборки программ
3.3.3 Автоматическая пересборка		Правила Makefile для настройки.

3.3.1 Предварительная установка выходных переменных

Некоторые выходные переменные заранее устанавливаются макросами Autoconf. Некоторые макросы Autoconf устанавливают дополнительные выходные переменные, которые упомянуты в описаниях этих макросов. Полный список выходных переменных находится в Индекс выходных переменных. See section `Variables for Installation Directories' in The GNU Coding Standards, для дополнительной информации о переменных с именами, которые заканчиваются на `dir'.

Variable: bindir

Каталог в который устанавливаются исполняемые программы, которые запускают пользователи.

Variable: configure_input

Комментарий, сообщающий что файл был автоматически создан скриптом configure и выдает имя входного файла. AC_OUTPUT добавляет строку комментария, содержащую эту переменную, в начало каждого создаваемого файла `Makefile'. Для других файлов вы должны сослаться на эту переменную в комментарии в заголовке каждого входного файла. Например, входной скрипт командного процессора должен начинаться примерно так:

#! /bin/sh # @configure_input@

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

Variable: datadir

Каталог, куда устанавливаются файлы данных, не зависящие от архитектуры.

Variable: exec_prefix

Префикс указывающий, куда будут устанавливаться файлы, зависящие от архитектуры.

Variable: includedir

Каталог, куда будут устанавливаться заголовочные файлы C.

Variable: infodir

Каталог, куда будет устанавливаться документация в формате Info.

Variable: libdir

Каталог куда будут устанавливаться скомпилированные библиотеки.

Variable: libexecdir

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

Variable: localstatedir

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

Variable: mandir

Каталог верхнего уровня, в который будут устанавливаться страницы руководства.

Variable: oldincludedir

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

Variable: prefix

Префикс для установки файлов, не зависящих от архитектуры.

Variable: sbindir

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

Variable: sharedstatedir

Каталог в который устанавливаются изменяемые, независящие от архитектуры файлы данных.

Variable: srcdir

Каталог, который содержит исходный код для данного `Makefile'.

Variable: sysconfdir

Каталог, в который устанавливаются неизменяемые файлы данных для данной машины.

Variable: top_srcdir

Каталог верхнего уровня, содержащий исходный код пакета. В каталоге верхнего уровня эта переменная совпадает с srcdir.

Variable: CFLAGS

Ключи оптимизации и отладочной информации для компилятора C. Если эта переменная не установлена в среде при запуске configure, то значение по умолчанию устанавливается при вызове макроса AC_PROG_CC (или равно пустому значению, если вы не вызываете этот макрос). configure использует эту переменную при компиляции программ для тестирования возможностей компилятора C.

Variable: CPPFLAGS

Каталоги поиска заголовочных файлов (`-Idir') и любые другие ключи для препроцессора и компилятора C. Если эта переменная не установлена в среде при запуске configure, то значение по умолчанию равно пустому значению. configure использует эту переменную при компиляции программ или обработке препроцессором для тестирования возможностей компилятора C.

Variable: CXXFLAGS

Ключи оптимизации и отладочной информации для компилятора C++. Если эта переменная не установлена в среде при запуске configure, то значение по умолчанию устанавливается при вызове макроса AC_PROG_CXX (или равно пустому значению, если вы не вызываете этот макрос). configure использует эту переменную при компиляции программ для тестирования возможностей компилятора C++.

Variable: FFLAGS

Ключи оптимизации и отладочной информации для компилятора Fortran 77. Если эта переменная не установлена в среде при запуске configure, то значение по умолчанию устанавливается при вызове макроса AC_PROG_F77 (или равно пустому значению, если вы не вызываете этот макрос). configure использует эту переменную при компиляции программ для тестирования возможностей компилятора Fortran 77.

Variable: DEFS

Ключи `-D', передаваемые компилятору C. Если вызывается макрос AC_CONFIG_HEADER, то configure заменяет вхождения `@DEFS@' на `-DHAVE_CONFIG_H' (see section 3.4 Заголовочные файлы конфигурации). Эта переменная не определена во время выполнения тестов configure, она определяется только при создании выходных файлов. See section 6.2 Установка выходных переменных, для описания того, как получить результаты предыдущих тестов.

Variable: LDFLAGS

Ключ для удаления отладочной информации (`-s'), а также другие ключи для компоновщика. Если не установлена в среде при запуске configure, то по умолчанию имеет пустое значение. configure использует эту переменную при компоновке программ для тестирования возможностей С.

Variable: LIBS

Ключи `-l' и `-L', передаваемые компоновщику.

3.3.2 Каталоги сборки программ

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

Для поддержки этого make использует переменную VPATH для поиска файлов, которые находятся в каталоге с исходными текстами. Такая возможность поддерживается GNU make и большинством других программ make свежих версий. Старые версии программы make не поддерживают переменную VPATH; при их использовании исходные тексты должны находиться в том же каталоге, что и объектные файлы.

Для поддержки VPATH каждый файл `Makefile.in' должен содержать две строки, которые могут выглядеть следующим образом:

srcdir = @srcdir@ VPATH = @srcdir@

Не надо устанавливать VPATH в значение другой переменной, например `VPATH = $(srcdir)', поскольку некоторые версии make не выполняют подстановку переменных для VPATH.

configure подставляет правильное значение srcdir при создании файла `Makefile'.

Не используйте переменную $< программы make, которая разворачивается в имя файла с полным путем (найденным с помощью VPATH), причем только в явных правилах. (Неявные правила, например, `.c.o', сообщают, как создать файл `.o' из файла `.c'.) Некоторые версии make не устанавливают $< в явных правилах; они подставляют вместо него пустое значение.

Вместо этого командные строки`Makefile' всегда должны ссылаться на файлы с исходными текстами, с добавлением к ним префикса `$(srcdir)/'. Например:

time.info: time.texinfo $(MAKEINFO) $(srcdir)/time.texinfo

3.3.3 Автоматическая пересборка

Вы можете поместить правила, упомянутые ниже, в файл `Makefile.in' верхнего уровня пакета, для того чтобы автоматически обновлять информацию о конфигурации при изменении файлов конфигурации. Этот пример использует все дополнительные файлы, такие как `aclocal.m4', а также то, что относятся к заголовочным файлам конфигурации. Уберите из правила для `Makefile.in' файлы, не использующиеся в вашем пакете.

Префикс `${srcdir}/' добавлен из-за ограничений механизма использования VPATH.

Файлы `stamp-' являются необходимыми, поскольку время последнего изменения файлов `config.h.in' и `config.h' останется прежним, если пересоздание этих файлов не изменит их содержимого. Эта возможность позволяет избежать ненужной перекомпиляции. Вы должны включить файл `stamp-h.in' в дистрибутив вашего пакета, так что make будет считать `config.h.in' обновленным. На некоторых старых системах BSD, команда touch или любая другая, создающая файл нулевой длины, не обновляет время изменения этого файла, так что используйте для правильной работы команду echo.

${srcdir}/configure: configure.in aclocal.m4 cd ${srcdir} && autoconf # autoheader мог не изменить config.h.in, так что обновить дату stamp-файла. ${srcdir}/config.h.in: stamp-h.in ${srcdir}/stamp-h.in: configure.in aclocal.m4 acconfig.h \ config.h.top config.h.bot cd ${srcdir} && autoheader echo timestamp > ${srcdir}/stamp-h.in config.h: stamp-h stamp-h: config.h.in config.status ./config.status Makefile: Makefile.in config.status ./config.status config.status: configure ./config.status --recheck

Вдобавок вы должны передать `echo timestamp > stamp-h' в аргументе extra-cmds макросу AC_OUTPUT, так что `config.status' будет гарантировать, что файл `config.h' будет рассматриваться как обновленный. See section 3.2 Создание выходных файлов, для дополнительной информации о AC_OUTPUT.

See section 11. Воссоздание конфигурации, где описаны дополнительные примеры обработки конфигурационных зависимостей.

3.4 Заголовочные файлы конфигурации

Когда пакет производит тестирование большого количества символов препроцессора C, то командная строка ключей `-D', передаваемых компилятору, может получиться достаточно длинной. Это вызывает две проблемы. Первая заключается в том, что вывод результатов команды make будет тяжело читать в поисках ошибок. Вторая и более серьезная заключается в том, что длина командной строки может превысить предельную длину командной строки в некоторых операционных системах. В качестве альтернативы передаче компилятору ключей `-D', скрипты configure могут создавать заголовочные файлы C, которые содержат директивы `#define'. Макрос AC_CONFIG_HEADER выбирает этот способ выдачи результатов. Макрос должен быть вызван сразу после вызова AC_INIT.

Пакет должен подключить с помощью #include заголовочный файл настройки до подключения остальных заголовочных файлов, чтобы избежать несовместимости в объявлениях (например, если этот файл переопределяет const). Используйте директиву `#include ' вместо `#include "config.h"', и передайте компилятору C ключ `-I.' (или `-I..', смотря где находится файл `config.h'). Таким образом, даже если сам каталог с исходными текстами сконфигурирован (например, для создания дистрибутива), то другие сборочные каталоги можно будет сконфигурировать, не используя при этом файл `config.h' и каталога с исходными текстами.

Macro: AC_CONFIG_HEADER (header-to-create ...)

Заставляет AC_OUTPUT создать файлы с именами из разделенного пробелами списка header-to-create, которые будут содержать директивы #define препроцессора C, и заменить `@DEFS@' в созданных файлах на `-DHAVE_CONFIG_H' вместо значения DEFS. Обычным значением для header-to-create является `config.h'.

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

Обычно входной файл называется `header-to-create.in'; однако вы можете переопределить имя входного файла, добавив к header-to-create список входных файлов, разделенный двоеточием. Примеры:

AC_CONFIG_HEADER(defines.h:defines.hin) AC_CONFIG_HEADER(defines.h:defs.pre:defines.h.in:defs.post)

Это позволяет вам сохранить имена в виде, приемлемом для использования в MS-DOS, а также для добавления стандартных кусков кода к файлам.

3.4.1 Шаблоны заголовочных файлов
3.4.2 Использование autoheader для создания `config.h.in'		Как создать шаблон для заголовочного файла настройки.

3.4.1 Шаблоны заголовочных файлов

Ваш дистрибутив должен содержать файл шаблона, который должен выглядеть так, как будет выглядеть окончательный заголовочный файл, включая комментарии, но при этом все значения директив #define в нем будут установлены по умолчанию. Например, предположим, что ваш файл `configure.in' производит следующие вызовы:

AC_CONFIG_HEADER(conf.h) AC_CHECK_HEADERS(unistd.h)

Для этого примера необходимо вставить в `conf.h.in' нижеследующий код. В системах, в которых есть `unistd.h', configure заменит 0 на 1. В других системах эта строка останется неизмененной.

/* Определить со значением 1 если у вас есть unistd.h. */ #define HAVE_UNISTD_H 0

Если ваш код проверяет конфигурацию, используя директиву препроцессора #ifdef вместо #if, то значение по умолчанию может быть удалено директивой #undef вместо определения значения. В системах в которых имеется файл `unistd.h', configure изменит вторую строку на `#define HAVE_UNISTD_H 1'. В других системах эта строка будет закомментирована (в случае, если система предопределяет этот символ).

/* Определяется, если в системе есть unistd.h. */ #undef HAVE_UNISTD_H

3.4.2 Использование autoheader для создания `config.h.in'

Программа autoheader может создать шаблон файла, содержащего директивы `#define', для использования с configure. Если `configure.in' использует AC_CONFIG_HEADER(file), то autoheader создает `file.in'; если в качестве аргумента задано несколько имен файлов, то используется только первое имя. В противном случае autoheader создаст файл `config.h.in'.

Если вы зададите аргумент программе autoheader, то она будет считывать данные из этого файла, а не из файла `configure.in' и будет выводить данные в поток стандартного вывода вместо `config.h.in'. Если вы зададите autoheader аргумент `-', то программа будет считывать данные со стандартного ввода вместо `configure.in' и выдавать результаты на стандартный вывод.

autoheader сканирует файл `configure.in' и определяет, какие символы препроцессора C могут быть определены в нем. Программа копирует комментарии и директивы #define и #undef из файла с именем `acconfig.h', который поставляется вместе с Autoconf. Программа также использует файл с именем `acconfig.h' из текущего каталога, если он присутствует. Если вы определите с помощью макроса AC_DEFINE дополнительные символы, то вы должны создать этот файл с записями для них. Для символов, определенных макросами AC_CHECK_HEADERS, AC_CHECK_FUNCS, AC_CHECK_SIZEOF или AC_CHECK_LIB, программа autoheader сама создает комментарии и директивы #undef, а не копирует их из файла, поскольку количество возможных символов фактически бесконечно.

Файл, который создается autoheader, содержит в основном директивы #define и #undef и комментарии к ним. Если `./acconfig.h' содержит строку `@TOP@', то autoheader копирует строки, которые находятся выше строки `@TOP@', прямо в заголовок создаваемого файла. Аналогично, если `./acconfig.h' содержит строку `@BOTTOM@', то autoheader скопирует строки, расположенные сразу после этой строки, в конец создаваемого файла. Можно не использовать как `@TOP@', так и `@BOTTOM@'.

Другой способ добиться точно такого же результата -- создать в текущем каталоге файлы `file.top' (обычно `config.h.top') и/или `file.bot'. Если эти файлы существуют, то autoheader копирует их содержимое в начало и в конец выводимых данных. Их использование не рекомендуется, поскольку имена этих файлов содержат две точки и не могут применяться в MS-DOS; также это увеличивает содержимое каталога еще на два файла. Но если вы воспользуетесь ключом `--localdir=dir' для использования `acconfig.h' находящегося в другом каталоге, то эти файлы позволят вам вставлять произвольные куски кода в каждый конкретный файл `config.h.in'.

autoheader распознает следующие ключи командной строки:

--help

-h

Выдает список ключей командной строки и прекращает работу.

--localdir=dir

-l dir

Искать файлы `aclocal.m4' и `acconfig.h' (но не файлы `file.top' и `file.bot') в каталоге dir вместо текущего каталога.

--macrodir=dir

-m dir

Искать инсталлированные файлы макросов и `acconfig.h' в каталоге dir. Вы можете также установить переменную среды AC_MACRODIR, указывающую на этот каталог; этот ключ переопределяет значение переменной среды.

--version

Выдает номер версии Autoconf и прекращает работу.

3.5 Настройка других пакетов, находящихся в подкаталогах

В большинстве ситуаций для создания файлов `Makefile' в подкаталогах достаточно вызова макроса AC_OUTPUT. Однако скрипты configure, которые контролируют более чем один независимый пакет, могут использовать макрос AC_CONFIG_SUBDIRS для запуска скриптов configure для других пакетов, находящихся в подкаталогах.

Macro: AC_CONFIG_SUBDIRS (dir ...)

Заставляет AC_OUTPUT запустить configure в каждом подкаталоге dir, которые заданы в списке через пробел. Если заданный каталог dir не найден, то сообщение об ошибке не выдается, поэтому скрипт configure может производить конфигурацию, даже если часть подкаталогов отсутствует. Если заданный каталог dir содержит файл `configure.in', но не содержит configure, то будет использоваться Cygnus-версия скрипта configure, местонахождение которой определяется макросом AC_CONFIG_AUXDIR.

Скриптам configure, находящимся в подкаталогах, передается та же командная строка, что задана текущему скрипту configure, только с некоторыми изменениями, когда это необходимо (например, исправление относительных путевых имен для кэш-файла или каталога с исходными текстами). Этот макрос также устанавливает выходную переменную subdirs равной списку каталогов `dir ...'. Правила `Makefile' могут использовать эту переменную для определения того, в какие подкаталоги будет осуществляться рекурсивный переход. Этот макрос может вызываться много раз.

3.6 Префикс по умолчанию

По умолчанию configure задает префикс для устанавливаемых файлов равным `/usr/local'. Пользователь configure может выбрать другой префикс, используя ключи командной строки `--prefix' и `--exec-prefix'. Есть два способа изменения значения по умолчанию: при создании configure и при его запуске.

Некоторые пакеты программного обеспечения могут требовать установки по умолчанию в каталог, отличный от `/usr/local'. Чтобы изменить значение по умолчанию, используйте макрос AC_PREFIX_DEFAULT.

Macro: AC_PREFIX_DEFAULT (prefix)

Устанавливает значение префикса установки по умолчанию в значение prefix вместо `/usr/local'.

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

Macro: AC_PREFIX_PROGRAM (program)

Если пользователь не указал префикс для установки (используя ключ `--prefix'), то попробовать определить значение префикса на основе поиска program в списке каталогов из PATH. Если program найдена, то установить префикс равным родительскому каталогу каталога, в котором находится program; иначе оставить неизмененным значение префикса, указанного `Makefile.in'. Например, если значением program является gcc, а в путях найдена программа `/usr/local/gnu/bin/gcc', то значением префикса будет `/usr/local/gnu'.

3.7 Номера версий в configure

Следующие макросы используются для работы с номерами версий в скриптах configure. Их использование не обязательно.

Macro: AC_PREREQ (version)

Обеспечивает проверку того, что используется достаточно свежая версия Autoconf. Если версия Autoconf, используемая для создания configure, является более старой, чем version, то в стандартный поток сообщений об ошибках выдается сообщение и configure не создается. Например:

AC_PREREQ(1.8)

Этот макрос полезен в том случае, если ваш `configure.in' полагается на неочевидное поведение, которое изменилось между версиями Autoconf. Если вам необходимы только недавно добавленные макросы, то AC_PREREQ чуть менее полезен, поскольку программа autoconf и так сообщит пользователю о том, какие макросы не найдены. То же самое случится в том случае, если файл `configure.in' будет обрабатываться версией Autoconf, более старой, чем та, в которой был добавлен макрос AC_PREREQ.

Macro: AC_REVISION (revision-info)

Копирует метки ревизий revision-info в скрипт configure, удаляя знаки доллара и двойные кавычки. Этот макрос позволяет вам помещать метки версий из файла `configure.in' в configure, но при этом RCS или CVS не станут изменять их при помещении configure в репозиторий. Таким образом, вы можете легко определить, какая версия `configure.in' соответствует конкретному configure.

Хорошей идеей является вызов этого макроса перед AC_INIT, чтобы номер ревизии располагался в начале и `configure.in', и configure. Для поддержки этого выдача AC_REVISION начинается с `#! /bin/sh', подобно обычному началу скрипта configure.

Вот пример этой строки в `configure.in':

AC_REVISION($Revision: 1.30 $)dnl

это создает в configure строки:

#! /bin/sh # From configure.in Revision: 1.30

4. Существующие тесты

Эти макросы выполняют проверку отдельных возможностей системы, в которых пакет нуждается или которые он может использовать. Если вам необходимо протестировать возможность, которую не проверяет ни один из имеющихся макросов, то, скорее всего, вы сможете это сделать путем вызова примитивных макросов с соответствующими аргументами (see section 5. Написание тестов).

Эти тесты сообщают пользователю, что именно они проверяют и каков результат проверки. Результаты кэшируются для ускорения последующих запусков configure (see section 6.3 Кэширование результатов).

Некоторые из этих макросов устанавливают выходные переменные. See section 3.3 Подстановки в файлах Makefile, для того, чтобы узнать о том, как получить значения этих переменных. Фраза "определить name" ниже используется как сокращение, обозначающее "определить символ name препроцессора C в значение 1". See section 6.1 Определение символов препроцессора С, для того, чтобы узнать о том, как получить определения этих символов в вашей программе.

4.1 Альтернативные программы
4.2 Файлы библиотек
4.3 Библиотечные функции
4.4 Заголовочные файлы
4.5 Структуры
4.6 Объявления типов
4.7 Характеристики компилятора C		Определение характеристик компилятора С.
4.8 Характеристики компилятора Fortran 77
4.9 Системные сервисы
4.10 Варианты UNIX

4.1 Альтернативные программы

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

4.1.1 Проверка отдельных программ
4.1.2 Общие программы и проверки файлов

4.1.1 Проверка отдельных программ

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

Macro: AC_DECL_YYTEXT

Определяет YYTEXT_POINTER, если yytext имеет тип `char *', а не `char []'. Также устанавливает значение выходной переменной LEX_OUTPUT_ROOT равным основе имени файла, создаваемого лексическим генератором; обычно это значение равно `lex.yy', но иногда используется что-то другое. Эти результаты различаются в зависимости от того, используется ли lex или flex.

Macro: AC_PROG_AWK

Проверяет наличие mawk, gawk, nawk и awk, в таком порядке и устанавливает выходную переменную AWK, равную имени найденной программы. Сначала пытается найти mawk, который считается самой быстрой реализацией.

Macro: AC_PROG_CC

Определяет компилятор C, который надо использовать. Если переменная среды CC не установлена, то проверить наличие gcc и использовать cc, если gcc не найден. Устанавливает выходную переменную CC, равную имени найденного компилятора.

Если используется компилятор GNU C, то значение переменной GCC устанавливается в значение `yes', в противном случае оно остается пустым. Если выходная переменная CFLAGS еще не была установлена, то установить ее равной `-g -O2' для компилятора GNU C (`-O2' на системах, в которых GCC не понимает ключа `-g') или равной `-g' для других компиляторов.

Если используемый компилятор C не создает исполняемых файлов, которые могут запускаться в той системе, где исполняется configure, то переменной командного процессора cross_compiling присваивается значение `yes', в противном случае она получает значение `no'. Другими словами, здесь проверяется, отличается ли тип системы, для которой производится сборка, от системы, на которой производится сборка (тип целевой системы не относится к этому тесту). Для получения дополнительной информации о кросс-компиляции See section 8. Ручная настройка.

Macro: AC_PROG_CC_C_O

Если компилятор C не может запускаться одновременно с ключами `-c' и `-o', то определяется переменная NO_MINUS_C_MINUS_O.

Macro: AC_PROG_CPP

Значение выходной переменной CPP устанавливается равным имени команды, которая запускает препроцессор C. Если `$CC -E' не работает, то используется `/lib/cpp'. Переносимым решением является запуск CPP только для обработки файлов с расширением `.c'.

Если текущим языком является C (see section 5.8 Выбор языка), то многие специфические тесты косвенно используют значение переменной CPP, вызывая макросы AC_TRY_CPP, AC_CHECK_HEADER, AC_EGREP_HEADER или AC_EGREP_CPP.

Macro: AC_PROG_CXX

Определяет имя используемого компилятора C++. Проверяется, установлены ли переменные среды CXX или CCC (именно в таком порядке); если одна из них установлена, то значение выходной переменной CXX устанавливается равным значению этой переменной. В противном случае производится поиск компилятора C++, используя вероятные имена (c++, g++, gcc, CC, cxx и cc++). Если ни одна из этих проверок не прошла успешно, то в качестве последнего шанса значение переменной CXX устанавливается равным gcc.

Если используется компилятор GNU C++, то переменная командного процессора GXX получает значение `yes', иначе ей присваивается пустое значение. Если выходная переменная CXXFLAGS еще не была установлена, то ей присваивается значение `-g -O2' для компилятора GNU C++ (`-O2' на системах, где G++ не распознает ключ `-g') или значение `-g' для других систем.

Если используемый компилятор C++ не создает исполняемых файлов, которые могут запускаться в системе, где выполняется configure, то переменной командного процессора cross_compiling присваивается значение `yes', в противном случае устанавливается значение `no'. Другими словами, здесь проверяется, отличается ли тип системы, для которой производится сборка, от системы, на которой производится сборка (тип целевой системы не относится к этому тесту). Для получения дополнительной информации о кросс-компиляции See section 8. Ручная настройка.

Macro: AC_PROG_CXXCPP

Значение выходной переменной CXXCPP устанавливается равным имени команды, которая запускает препроцессор C++. Если `$CXX -E' не работает, то используется `/lib/cpp'. Переносимым решением является запуск CXXCPP только для обработки файлов с расширениями `.c', `.C' или `.cc'.

Если текущим языком является C++ (see section 5.8 Выбор языка), то многие специфические тесты косвенно используют значение переменной CXXCPP, вызывая AC_TRY_CPP, AC_CHECK_HEADER, AC_EGREP_HEADER или AC_EGREP_CPP.

Macro: AC_PROG_F77

Определяет имя используемого компилятора Fortran 77. Если переменная среды F77 не установлена, то производится проверка наличия программ g77, f77 and f2c, в описанном порядке. Имя найденной программы присваивается выходной переменной F77.

Если используется программа g77 (компилятор GNU Fortran 77), то макрос AC_PROG_F77 установит переменную G77 равной значению `yes', а в противном случае ей будет присвоено пустое значение. Если выходная переменная FFLAGS не была установлена в среде, то для g77 данной переменной присваивается значение `-g -02' (или `-O2' в тех случаях когда g77 не принимает ключ `-g'). Иначе, для всех остальных компиляторов Fortran 77, переменной FFLAGS присваивается значение `-g'.

Macro: AC_PROG_F77_C_O

Выполняет проверку того, что компилятор Fortran 77 может запускаться одновременно с ключами `-c' и `-o'. Если компилятор не принимает эти ключи одновременно, то определяется переменная F77_NO_MINUS_C_MINUS_O.

Macro: AC_PROG_GCC_TRADITIONAL

Добавляет строку `-traditional' к выходной переменной CC в том случае, если используемый компилятор GNU C и функции ioctl неправильно работают без нее. Обычно это случается, если в старой системе не были установлены исправленные заголовочные файлы. Поскольку свежие версии компилятора GNU C при установке исправляют заголовочные файлы, это становится менее распространенной проблемой.

Macro: AC_PROG_INSTALL

Устанавливает выходную переменную INSTALL, равной полному пути к совместимой с BSD программе install, если она найдена в текущей переменной PATH. Иначе, переменная INSTALL получает значение `dir/install-sh -c', проверяя каталоги, указанные в AC_CONFIG_AUX_DIR (или каталоги по умолчанию) для определения dir (see section 3.2 Создание выходных файлов). Этот макрос также устанавливает переменные INSTALL_PROGRAM и INSTALL_SCRIPT равными значениям `${INSTALL}', а INSTALL_DATA значение `${INSTALL} -m 644'.

Этот макрос не замечает версии install о которых известно, что они не работают. Этот макрос также предпочитает использовать программу на языке C вместо скриптов командного процессора. Вместо `install-sh', он также может использовать `install.sh', но это имя устарело, поскольку некоторые программы make имеют правило, которое создает файл `install' из этого файла, если нет файла `Makefile'.

Копия `install-sh', которую вы можете использовать, поставляется с Autoconf. Если вы используете AC_PROG_INSTALL, то вы должны включить в свой дистрибутив либо `install-sh', либо `install.sh', иначе configure выдаст ошибку, сообщающую о том, что он не может найти эти файлы--- даже если система имеет нормальную программу install. Это мера безопасности, чтобы вы случайно не забыли про этот файл, тем самым лишив пользователя возможности установить ваш пакет в системе, в которой нет BSD-совместимой программы install.

Если вам необходимо использовать вашу собственную программу установки (поскольку она имеет возможности, отсутствующие в стандартных программах install), то нет никакой надобности в использовании макроса AC_PROG_INSTALL; просто поместите путь к вашей программе в ваши файлы `Makefile.in'.

Macro: AC_PROG_LEX

Если найдена программа flex, то выходная переменная LEX получает значение `flex', а LEXLIB -- значение `-lfl', в случае, если библиотека располагается в стандартном месте. Иначе переменная LEX получает значение `lex', а LEXLIB --- значение `-ll'.

Macro: AC_PROG_LN_S

Если команда `ln -s' работает в текущей файловой системе (и операционная, и файловая системы поддерживают символьные ссылки), то выходная переменная LN_S получает значение `ln -s', в противном случае значение равно `ln'.

Если ссылка помещается в другой, отличный от текущего, каталог, то смысл этой ссылки зависит от того, какая команда будет использована: `ln' или `ln -s'. Чтобы безбоязненно создавать ссылки, используя `$(LN_S)', либо определите, какая форма команды используется и соответственно измените ее аргументы, либо всегда запускайте ln в том каталоге, где будет создаваться ссылка.

Другими словами, не делайте

$(LN_S) foo /x/bar

Вместо этого выполняйте

(cd /x && $(LN_S) foo bar)

Macro: AC_PROG_RANLIB

Если команда ranlib найдена, то выходная переменная RANLIB получает значение равное `ranlib', в противном случае используется значение `:' (не делать ничего).

Macro: AC_PROG_YACC

Если найдена программа bison, то выходная переменная YACC получает значение `bison -y'. В противном случае, если найдена команда byacc, то переменная YACC получит значение `byacc'. В противном случае YACC устанавливается в `yacc'.

4.1.2 Общие программы и проверки файлов

Эти макросы используются для обнаружения программ, для которых нет отдельных макросов. Если вам необходимо проверить не только присутствие программы, но и ее поведение, то вам необходимо написать свой тест для данной программы (see section 5. Написание тестов). По умолчанию эти макросы используют переменную среды PATH. Если вам необходимо проверить наличие программы, которая может находится в каталогах пользовательской переменной PATH, то вы можете передать макросу измененную переменную PATH, вот как в этом случае:

AC_PATH_PROG(INETD, inetd, /usr/libexec/inetd, $PATH:/usr/libexec:/usr/sbin:/usr/etc:etc)

Macro: AC_CHECK_FILE (file [, action-if-found [, action-if-not-found]])

Выполняет проверку, существует ли в системе файл file. Если он найден, то выполняются команды action-if-found, в противном случае выполняется action-if-not-found, если задано.

Macro: AC_CHECK_FILES (files[, action-if-found [, action-if-not-found]])

Выполняет макрос AC_CHECK_FILE для каждого из файлов в списке files. Дополнительно определяет переменную `HAVEfile' для каждого из найденных файлов и устанавливает ее равной 1.

Macro: AC_CHECK_PROG (variable, prog-to-check-for, value-if-found [, value-if-not-found [, path, [ reject ]]])

Проверяет, находится ли программа prog-to-check-for в каталогах, перечисленных в переменной PATH. Если эта программа найдена, то переменная variable устанавливается равным значению value-if-found, в противном случае равным значению value-if-not-found (если оно задано). Никогда не использует reject (имя файла с абсолютным путем), даже если такая программа была найдена в путях поиска; в этом случае переменная variable устанавливается, используя абсолютное имя найденной программы prog-to-check-for, которая не является reject. Если переменная variable уже установлена, то ничего не делается. Вызывает макрос AC_SUBST для variable.

Macro: AC_CHECK_PROGS (variable, progs-to-check-for [, value-if-not-found [, path]])

Проверяет наличие в PATH каждой программы из списка через пробел progs-to-check-for. Если программа найдена, то переменная variable устанавливается в значение, равное имени найденной программы. В противном случае продолжается проверка наличия следующей программы. Если ни одна из программ не найдена, то переменная variable получает значение value-if-not-found; если value-if-not-found не указано, то значение variable не изменяется. Вызывает макрос AC_SUBST для variable.

Macro: AC_CHECK_TOOL (variable, prog-to-check-for [, value-if-not-found [, path]])

Работает подобно AC_CHECK_PROG, но сначала проверяет наличие prog-to-check-for с префиксом типа системы, который определяется макросом AC_CANONICAL_HOST, за которым следует тире (see section 8.2 Получение канонического типа системы). Например, если пользователь запустит `configure --host=i386-gnu', то этот вызов:

AC_CHECK_TOOL(RANLIB, ranlib, :)

установит переменную RANLIB в значение `i386-gnu-ranlib', если эта программа находится в каталогах, перечисленных в PATH, или в `ranlib', если эта программа находится в PATH, или в `:', если ни одна из программ не существует.

Macro: AC_PATH_PROG (variable, prog-to-check-for [, value-if-not-found [, path]])

Работает подобно AC_CHECK_PROG, но устанавливает variable равной полному пути к найденной программе prog-to-check-for.

Macro: AC_PATH_PROGS (variable, progs-to-check-for [, value-if-not-found [, path]])

Подобен макросу AC_CHECK_PROGS, но если найдена любая из программ progs-to-check-for, то переменная variable получает значение, равное полному пути к найденной программе.

4.2 Файлы библиотек

Нижеописанные макросы проверяют наличие определенных библиотек C, C++ или Fortran 77.

Macro: AC_CHECK_LIB (library, function [, action-if-found [, action-if-not-found [, other-libraries]]])

В зависимости от текущего языка (see section 5.8 Выбор языка), макрос пытается убедиться, что функция C, C++ или Fortran 77 с именем function доступна (путем проверки, что тестовая программа компонуется с библиотекой library для получения доступа к функции). library является базовым именем библиотеки; например, для `-lmp', используйте `mp' в качестве аргумента library.

action-if-found является списком команд командного процессора, которые запускаются в случае, если процесс компоновки прошел удачно; action-if-not-found является списком команд, которые запускаются, если процесс компоновки потерпел неудачу. Если аргумент action-if-found не указан, то действие по умолчанию добавит `-llibrary' в переменную LIBS и определит переменную `HAVE_LIBlibrary' (все буквы заглавные).

Если при компоновке с library выдаются сообщения о ненайденных символах, которые могут быть найдены, компонуя программы с дополнительными библиотеками, то вы должны передать список этих библиотек через пробелы в аргументе other-libraries: `-lXt -lX11'. В противном случае этот макрос не сможет определить, что библиотека library присутствует, поскольку компоновка тестовой программы всегда будет аварийно завершаться с сообщениями о ненайденных символах.

Macro: AC_HAVE_LIBRARY (library, [, action-if-found [, action-if-not-found [, other-libraries]]])

Этот макрос аналогичен вызову AC_CHECK_LIB с аргументом function, равным main. Вдобавок, library может быть указана как `foo', `-lfoo' или `libfoo.a'. Во всех этих случаях компилятору передается строка `-lfoo'. Однако library не может быть переменной командного процессора; ее значение должно быть символьным именем. Этот макрос считается устаревшим.

Macro: AC_SEARCH_LIBS (function, search-libs [, action-if-found [, action-if-not-found [, other-libraries]]])

Производит поиск библиотеки, определяющей функцию function, если она еще не доступна. Это подобно вызову макроса AC_TRY_LINK_FUNC сначала без указания библиотек, а затем для каждой из библиотек, перечисленных в списке search-libs.

Если функция найдена, то выполняются команды action-if-found, в противном случае выполняются action-if-not-found.

Если при компоновке с library выдаются сообщения о ненайденных символах, которые могут быть найдены, компонуя программы с дополнительными библиотеками, то вы должны передать список этих библиотек через пробел, используя аргумент other-libraries: `-lXt -lX11'. В противном случае этот макрос не сможет определить, что библиотека library присутствует, поскольку компоновка тестовой программы всегда будет аварийно завершаться с сообщениями о ненайденных символах.

Macro: AC_SEARCH_LIBS (function, search-libs[, action-if-found [, action-if-not-found]])

Этот макрос эквивалентен вызову AC_TRY_LINK_FUNC для каждой из библиотек, перечисленных в списке search-libs. Макрос добавляет `-llibrary' к содержимому переменной LIBS для первой библиотеки, которая содержит function и выполняет action-if-found. В противном случае выполняется action-if-not-found.

4.3 Библиотечные функции

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

4.3.1 Проверка отдельных функций
4.3.2 Проверка базовых функций

4.3.1 Проверка отдельных функций

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

Macro: AC_FUNC_ALLOCA

Проверяет, как получить alloca. Макрос пробует получить встроенную версию, проверяя наличие файла `alloca.h' или предопределенных макросов препроцессора C __GNUC__ и _AIX. Если этот макрос находит `alloca.h', то определяется переменная HAVE_ALLOCA_H.

Если эти попытки оканчиваются неудачей, то макрос будет искать функцию в стандартной библиотеке C. Если любой из этих методов закончится успешно, то будет определена переменная HAVE_ALLOCA. В противном случае выходная переменная ALLOCA получит значение `alloca.o' и будет определена переменная C_ALLOCA (так что программы смогут периодически вызывать `alloca(0)' для сборки мусора). Эта переменная отделена от LIBOBJS, так что несколько программ смогут использовать одно и то же значение ALLOCA, без необходимости создания настоящей библиотеки, если лишь некоторые из них используют код в LIBOBJS.

Эти макросы не пытаются получить alloca из библиотеки System V R3 `libPW' или из библиотеки System V R4 `libucb', поскольку эти библиотеки содержат некоторые несовместимые функции, что может в дальнейшем вызвать проблемы. Некоторые версии библиотек даже не содержат alloca или содержат версию с ошибками. Если вы все таки хотите использовать alloca из этих библиотек, то вместо компиляции файла `alloca.c' используйте ar для извлечения из них `alloca.o'.

Для правильного объявления этой функции исходные тексты, использующие alloca, должны начинаться примерно с нижеизложенного кода. В некоторых версиях AIX, объявление alloca должно предшествовать всему, за исключением комментариев и директив препроцессора. Директива #pragma специальным образом выровнена (перед ней стоит несколько пробелов), чтобы старые не-ANSI компиляторы C игнорировали ее, а не выдавали ошибку.

/* AIX требует, чтобы это было первым кодом в файле. */ #ifndef __GNUC__ # if HAVE_ALLOCA_H # include # else # ifdef _AIX #pragma alloca # else # ifndef alloca /* предопределено в cc +Olibcalls фирмы HP */ char *alloca (); # endif # endif # endif #endif

Macro: AC_FUNC_CLOSEDIR_VOID

Если значение, возвращаемое функцией closedir, не несет полезной информации, то определяется CLOSEDIR_VOID. В противном случае тот, кто вызывает эту функцию, может проверить возвращаемое значение на наличие ошибки.

Macro: AC_FUNC_FNMATCH

Если функция fnmatch доступна и работает (в отличие от имеющейся в SunOS 5.4), то определяется переменная HAVE_FNMATCH.

Macro: AC_FUNC_GETLOADAVG

Проверка того, как получить данные о загрузке системы. Если система имеет функцию getloadavg, то этот макрос определяет переменную HAVE_GETLOADAVG, и добавляет к LIBS библиотеки, необходимые для получения этой функции.

В противном случае макрос добавляет `getloadavg.o' к выходной переменной LIBOBJS и, возможно, определяет другие макросы препроцессора C и выходные переменные:

1. Он определяет SVR4, DGUX, UMAX или UMAX4_3 на соответствующих системах.

2. Если он находит `nlist.h', то он определяет переменную NLIST_STRUCT.

3. Если `struct nlist' имеет поле `n_un', то определяется переменная NLIST_NAME_UNION.

4. Если компиляция `getloadavg.c' определяет LDAV_PRIVILEGED, то программы необходимо специальным образом устанавливать на эту систему, чтобы getloadavg работала, и этот макрос определяет GETLOADAVG_PRIVILEGED.

5. Этот макрос устанавливает выходную переменную NEED_SETGID. Ее значением является `true', если требуется специальная установка, и `false' в противном случае. Если NEED_SETGID равен `true', то этот макрос устанавливает KMEM_GROUP в значение, равное названию группы, которая должна владеть установленной программой.

Macro: AC_FUNC_GETMNTENT

Проверяет наличие getmntent в библиотеках `sun', `seq' и `gen' для Irix 4, PTX и Unixware, соответственно. Затем, если функция getmntent доступна, определяется переменная HAVE_GETMNTENT.

Macro: AC_FUNC_GETPGRP

Если getpgrp запускается без аргументов (версия POSIX.1), то определяется GETPGRP_VOID. В противном случае функция является BSD-версией, которая принимает в качестве аргумента идентификатор процесса. Этот макрос не выполняет проверку наличия getpgrp; если вам необходимо работать в такой ситуации, то сначала вызовите AC_CHECK_FUNC для getpgrp.

Macro: AC_FUNC_MEMCMP

Если функция memcmp недоступна, или не работает с восьмибитными данными (как функция в SunOS 4.1.3), то `memcmp.o' добавляется к выходной переменной LIBOBJS.

Macro: AC_FUNC_MMAP

Если функция mmap существует и работает правильно, то определяется переменная HAVE_MMAP. Проверяется только фиксированное приватное отображение уже отображенной памяти.

Macro: AC_FUNC_SELECT_ARGTYPES

Определяет правильный тип, передаваемый каждому из аргументов функции select, и определяет эти типы в переменных SELECT_TYPE_ARG1, SELECT_TYPE_ARG234 и SELECT_TYPE_ARG5. Значением по умолчанию для SELECT_TYPE_ARG1 является `int', для SELECT_TYPE_ARG234 типом по умолчанию является `int *' и для SELECT_TYPE_ARG5 типом по умолчанию является `struct timeval *'.

Macro: AC_FUNC_SETPGRP

Если setpgrp запускается без аргументов (версия POSIX.1), то определяется SETPGRP_VOID. В противном случае, функция является BSD-версией, которая принимает в качестве аргумента идентификатор процесса. Этот макрос не выполняет проверку наличия setpgrp; если вам необходимо работать в такой ситуации, то сначала вызовите AC_CHECK_FUNC для setpgrp.

Macro: AC_FUNC_SETVBUF_REVERSED

Если setvbuf принимает тип буферизации как второй аргумент, а указатель на буфер как третий аргумент, а не наоборот, то определяется переменная SETVBUF_REVERSED. Это справедливо для System V до выпуска 3.

Macro: AC_FUNC_STRCOLL

Если функция strcoll существует и работает правильно, то определяется переменная HAVE_STRCOLL. Этот макрос выполняет больше проверок, чем просто вызов `AC_CHECK_FUNCS(strcoll)', потому что некоторые системы имеют неправильные определения strcoll, которыми не следует пользоваться.

Macro: AC_FUNC_STRFTIME

Проверка наличия strftime в библиотеке `intl', для SCO UNIX. Затем, если strftime доступна, определяется переменная HAVE_STRFTIME.

Macro: AC_FUNC_UTIME_NULL

Если вызов `utime(file, NULL)' устанавливает время модификации файла file в текущее время, то определить переменную HAVE_UTIME_NULL.

Macro: AC_FUNC_VFORK

Если найден файл `vfork.h', то определяется переменная HAVE_VFORK_H. Если работающая версия vfork не найдена, то определить vfork как fork. Этот макрос проверяет несколько известных ошибок в реализации vfork и если найдена одна из таких реализаций, то считается, что система не имеет работающей версии vfork. Макрос не считает, ошибкой реализации, если при вызове потомком функции signal изменяются обработчики сигналов родителя, поскольку потомки редко изменяют обработчики сигналов родительского процесса.

Macro: AC_FUNC_VPRINTF

Если найдена функция vprintf, то определяется переменная HAVE_VPRINTF. В противном случае, если найдена функция _doprnt, то определяется переменная HAVE_DOPRNT. (Если функция vprintf доступна, то вы можете считать, что функции vfprintf и vsprintf тоже доступны).

Macro: AC_FUNC_WAIT3

Если функция wait3 найдена, и заполняет содержимое своего третьего аргумента (`struct rusage *'), чего не делает HP-UX, то определяется переменная HAVE_WAIT3.

4.3.2 Проверка базовых функций

Macro: AC_CHECK_FUNC (function, [action-if-found [, action-if-not-found]])

Если функция C с именем function доступна, то запускаются команды командного процессора action-if-found, в противном случае запускаются action-if-not-found. Если вы просто хотите определить символ препроцессора, если функция существует, то вместо этого макроса попробуйте использовать AC_CHECK_FUNCS. Этот макрос проверяет компоновку с библиотекой C, даже если был вызван макрос AC_LANG_CPLUSPLUS, поскольку C++ является более стандартизованным, чем C. (see section 5.8 Выбор языка, для дополнительной информации о выборе языка, для которого проводятся проверки).

Macro: AC_CHECK_FUNCS (function... [, action-if-found [, action-if-not-found]])

Для каждой из заданных function в списке, разделенном пробелами, в случае если она доступна, определить переменную HAVE_function (все буквы заглавные). Если задан аргумент action-if-found, то выполняется дополнительный код командного процессора, если одна из функций найдена. Вы можете задать значение `break' для прекращения цикла при нахождении первой функции. Если задан аргумент action-if-not-found, то эти команды выполняются, когда одна из функций не найдена.

Macro: AC_REPLACE_FUNCS (function...)

Этот макрос подобен вызову макроса AC_CHECK_FUNCS, используя код action-if-not-found, который добавляет `function.o' к выходной переменной LIBOBJS. Вы можете объявить функцию, для которой будет использована ваша замена, поместив ее прототип между директивами `#ifndef HAVE_function'. Если система имеет нужную функцию, то эта функция, вероятно, будет объявлена в заголовочном файле, который вы должны включить в свою программу, так что вы не должны повторно объявлять ее, во избежание конфликта объявлений.

4.4 Заголовочные файлы

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

4.4.1 Проверка отдельных заголовочных файлов
4.4.2 Базовые проверки заголовочных файлов

4.4.1 Проверка отдельных заголовочных файлов

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

Macro: AC_DECL_SYS_SIGLIST

Определяет переменную SYS_SIGLIST_DECLARED, если переменная sys_siglist объявлена в системном заголовочном файле--- либо в `signal.h', либо в `unistd.h'.

Macro: AC_DIR_HEADER

Подобен вызову макросов AC_HEADER_DIRENT и AC_FUNC_CLOSEDIR_VOID, но определяет немного другой набор макросов препроцессора C, для указания того, какой заголовочный файл найден. Этот макрос и имена, которые он определяет, считаются устаревшими. Макрос определяет следующие имена:

`dirent.h'

DIRENT

`sys/ndir.h'

SYSNDIR

`sys/dir.h'

SYSDIR

`ndir.h'

NDIR

Вдобавок, если функция closedir не возвращает информативного значения, то определяется переменная VOID_CLOSEDIR.

Macro: AC_HEADER_DIRENT

Проверка следующих заголовочных файлов, и для первого файла, который найден и определяет `DIR', определить нижеследующие макросы препроцессора C:

`dirent.h'

HAVE_DIRENT_H

`sys/ndir.h'

HAVE_SYS_NDIR_H

`sys/dir.h'

HAVE_SYS_DIR_H

`ndir.h'

HAVE_NDIR_H

В исходном тексте объявления библиотеки каталогов должны выглядеть примерно так:

#if HAVE_DIRENT_H # include # define NAMLEN(dirent) strlen((dirent)->d_name) #else # define dirent direct # define NAMLEN(dirent) (dirent)->d_namlen # if HAVE_SYS_NDIR_H # include # endif # if HAVE_SYS_DIR_H # include # endif # if HAVE_NDIR_H # include # endif #endif

Используя нижеследующие объявления, программа должна объявить переменные с типом struct dirent, а не struct direct, а доступ к полю длины имени каталога она должна получать путем передачи указателя на struct dirent макросу NAMLEN.

Этот макрос также проверяет наличие библиотек `dir' и `x' в SCO Xenix.

Macro: AC_HEADER_MAJOR

Если `sys/types.h' не определяет major, minor и makedev, но это делается в `sys/mkdev.h', то определяется переменная MAJOR_IN_MKDEV; в противном случае, если эти функции определяются в `sys/sysmacros.h', то определяется переменная MAJOR_IN_SYSMACROS.

Macro: AC_HEADER_STDC

Определяет STDC_HEADERS, если система имеет заголовочные файлы ANSI C. Это макрос проверяет наличие `stdlib.h', `stdarg.h', `string.h' и `float.h'; если система имеет эти файлы, то, скорее всего, имеются и остальные заголовочные файлы ANSI C. Этот макрос также проверяет, что `string.h' объявляет memchr (и поэтому, скорее всего, еще и другие функции mem), объявляется ли в `stdlib.h' функция free (и, по видимому, malloc и другие относящиеся к ним функции), и будут ли макросы из `ctype.h' работать с символами с установленным старшим битом, как этого требует ANSI C.

Используйте STDC_HEADERS вместо of __STDC__ для определения, имеются ли в системе совместимые с ANSI заголовочные файлы (и, вероятно, функции библиотеки C), поскольку многие системы, имеющие GCC, не имеют заголовочные файлы ANSI C.

На системах без заголовочных файлов ANSI C существует так много вариантов, что, вероятно, легче объявить используемые вами функции, чем точно определять, какой из заголовочные файлов определяет эти функции. Некоторые системы содержат смесь функций ANSI и BSD; некоторые из них по большей части совместимы с ANSI, но не имеют `memmove'; некоторое определяют функции BSD как макросы в файлах `string.h' или `strings.h'; некоторые из них имеют только функции BSD, но с `string.h'; некоторые объявляют функции работы с памятью в `memory.h', некоторые в `string.h'; и т. п. Скорее всего, достаточно проверить наличие одной функции работы со строками и одной функции работы с памятью; если библиотека имеет ANSI-версии этих функций, то, скорее всего, она имеет и большинство других функций. Вы должны поместить следующий код в `configure.in':

AC_HEADER_STDC AC_CHECK_FUNCS(strchr memcpy)

а затем, в вашем коде вы можете поместить следующие строки:

#if STDC_HEADERS # include #else # ifndef HAVE_STRCHR # define strchr index # define strrchr rindex # endif char *strchr (), *strrchr (); # ifndef HAVE_MEMCPY # define memcpy(d, s, n) bcopy ((s), (d), (n)) # define memmove(d, s, n) bcopy ((s), (d), (n)) # endif #endif

Если вы используете функции, которые не имеют эквивалентов в BSD, такие как memchr, memset strtok или strspn, то просто макросов будет недостаточно; вы должны предоставить реализацию каждой из функций. Простой способ подключить ваши реализации только если они действительно нужны (потому что функции из системной библиотеки могут быть вручную оптимизированы) --- это, например, поместить функцию memchr в файл `memchr.c', и использовать макрос `AC_REPLACE_FUNCS(memchr)'.

Macro: AC_HEADER_SYS_WAIT

Если `sys/wait.h' существует и совместим с POSIX.1, то определяется переменная HAVE_SYS_WAIT_H. Несовместимость может возникнуть, если файла `sys/wait.h' не существует, или для сохранения значения статуса он использует старую BSD-версию union wait вместо int. Если `sys/wait.h' не является совместимым с POSIX.1, то вместо его включения определяется макрос POSIX.1 с его обычной реализацией. Вот пример:

#include #if HAVE_SYS_WAIT_H # include #endif #ifndef WEXITSTATUS # define WEXITSTATUS(stat_val) ((unsigned)(stat_val) >> 8) #endif #ifndef WIFEXITED # define WIFEXITED(stat_val) (((stat_val) & 255) == 0) #endif

Macro: AC_MEMORY_H

Определяет NEED_MEMORY_H, если memcpy, memcmp, и т. п. не объявлены в файле `string.h' и существует файл `memory.h'. Этот макрос является устаревшим; вместо него используйте вызов AC_CHECK_HEADERS(memory.h). Смотрите пример для AC_HEADER_STDC.

Macro: AC_UNISTD_H

Определяет переменную HAVE_UNISTD_H, если в системе имеется файл `unistd.h'. Этот макрос является устаревшим; вместо него используйте вызов `AC_CHECK_HEADERS(unistd.h)'.

Для проверки того, что система поддерживает POSIX.1, можно использовать следующий код:

#if HAVE_UNISTD_H # include # include #endif #ifdef _POSIX_VERSION /* Код для систем POSIX.1 */ #endif

_POSIX_VERSION определяется, когда `unistd.h' подключен в системах, совместимых с POSIX.1. Если файла `unistd.h' не существует, то, скорее всего, эта система не относится к POSIX.1. Однако некоторые не-POSIX.1 системы имеют файл `unistd.h'.

Macro: AC_USG

Определяет USG, если система не имеет файла `strings.h', rindex, bzero и т. п. Это означает, что система имеет `string.h', strrchr, memset и т. п.

Символ USG является устаревшим. Вместо этого макроса смотрите пример для AC_HEADER_STDC.

4.4.2 Базовые проверки заголовочных файлов

Эти макросы используются для нахождения системных заголовочных файлов, для которых не существует отдельного теста. Если вам надо проверить не только наличие заголовочного файла, но и его содержимое, то придется написать для этого собственный тест (see section 5. Написание тестов).

Macro: AC_CHECK_HEADER (header-file, [action-if-found [, action-if-not-found]])

Если системный заголовочный файл header-file существует, то исполняются команды командного процессора action-if-found, в противном случае выполняются action-if-not-found. Если вы просто хотите определить символ, если заголовочный файл доступен, то лучше используйте макрос AC_CHECK_HEADERS.

Macro: AC_CHECK_HEADERS (header-file... [, action-if-found [, action-if-not-found]])

Для каждого системного заголовочного файла header-file, заданного в списке через пробел, в случае его существования определить переменную HAVE_header-file (все буквы заглавные). Если задан аргумент action-if-found, то выполняется дополнительный код командного процессора в случае, когда файл найден. Вы можете задать аргумент `break' для прекращения итераций, когда найден первый файл. Если задан аргумент action-if-not-found, то он выполняется, когда заголовочный файл не найден.

4.5 Структуры

Следующие макросы проверяют наличие определенных структур или полей структур. Для проверки структур, не перечисленных в этом разделе, используйте макрос AC_EGREP_CPP (see section 5.1 Исследование деклараций) или AC_TRY_COMPILE (see section 5.2 Проверка синтаксиса).

Macro: AC_HEADER_STAT

Если макросы S_ISDIR, S_ISREG и т. п., определенные в `sys/stat.h', работают неправильно (возвращая неверные положительные результаты), то определяется переменная STAT_MACROS_BROKEN. Это происходит на системах Tektronix UTekV, Amdahl UTS и Motorola System V/88.

Macro: AC_HEADER_TIME

Если программа может подключать как `time.h', так и `sys/time.h', то определяется переменная TIME_WITH_SYS_TIME. В некоторых старых системах `sys/time.h' подключает `time.h', но `time.h' не защищен от многократного подключения, так что программы не должны явно подключать оба файла. Этот макрос полезен для программ, которые, например, используют структуры struct timeval или struct timezone, вместе с struct tm. Этот макрос лучше всего использовать вместе с HAVE_SYS_TIME_H, который может быть проверен с помощью AC_CHECK_HEADERS(sys/time.h).

#if TIME_WITH_SYS_TIME # include # include #else # if HAVE_SYS_TIME_H # include # else # include # endif #endif

Macro: AC_STRUCT_ST_BLKSIZE

Если struct stat содержит поле st_blksize, то определяется переменная HAVE_ST_BLKSIZE.

Macro: AC_STRUCT_ST_BLOCKS

Если struct stat содержит поле st_blocks, то определяется переменная HAVE_ST_BLOCKS. В противном случае, `fileblocks.o' добавляется к выходной переменной LIBOBJS.

Macro: AC_STRUCT_ST_RDEV

Если struct stat содержит поле st_rdev, то определяется переменная HAVE_ST_RDEV.

Macro: AC_STRUCT_TM

Если `time.h' не определяет struct tm, то определяется символ TM_IN_SYS_TIME, что означает, что `sys/time.h' следовало бы определить struct tm.

Macro: AC_STRUCT_TIMEZONE

Определяет, как получить текущую временную зону. Если struct tm имеет поле tm_zone, то определяется переменная HAVE_TM_ZONE. В противном случае, если найден внешний массив tzname, то определяется переменная HAVE_TZNAME.

4.6 Объявления типов

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

4.6.1 Проверка отдельных объявлений типов
4.6.2 Базовые проверки объявлений типов

4.6.1 Проверка отдельных объявлений типов

Эти макросы проверяют конкретные объявления типов C в файлах `sys/types.h' и `stdlib.h' (если он существует).

Macro: AC_TYPE_GETGROUPS

Определяет GETGROUPS_T равным gid_t или int, в зависимости от того, что именно является базовым типом массива-аргумента функции getgroups.

Macro: AC_TYPE_MODE_T

Если mode_t не определен, то определить тип mode_t равным int.

Macro: AC_TYPE_OFF_T

Если off_t не определен, то определить off_t равным long.

Macro: AC_TYPE_PID_T

Если pid_t не определен, то определить pid_t равным int.

Macro: AC_TYPE_SIGNAL

Если `signal.h' определяет signal как возвращающий указатель на функцию, возвращающую void, то переменная RETSIGTYPE становится равной void; в противном случае она определяется с типом int.

Определить обработчики сигналов как возвращающие тип RETSIGTYPE:

RETSIGTYPE hup_handler () { ... }

Macro: AC_TYPE_SIZE_T

Если size_t не определен, то определить size_t как unsigned.

Macro: AC_TYPE_UID_T

Если uid_t не определен, то определить uid_t равным int и gid_t равным int.

4.6.2 Базовые проверки объявлений типов

Эти макросы используются для проверки определений типов (typedef), которые не были описаны в разделе конкретных макросов проверок.

Macro: AC_CHECK_TYPE (type, default)

Если тип type не определен в `sys/types.h', или в `stdlib.h', или в `stddef.h' (если они существуют), то определить этот тип равным встроенному типу C (или C++) default; например, `short' или `unsigned'.

4.7 Характеристики компилятора C

Следующие макросы выполняют проверку свойств компилятора C или архитектуры машины. Для проверки характеристик, не перечисленных в этом разделе, используйте макросы AC_TRY_COMPILE (see section 5.2 Проверка синтаксиса) или AC_TRY_RUN (see section 5.4 Проверка поведения во время выполнения).

Macro: AC_C_BIGENDIAN

Если слова хранятся в порядке, когда самый значимый байт хранится первым (подобно процессорам Motorola и SPARC, но не Intel и VAX), то определяется переменная WORDS_BIGENDIAN.

Macro: AC_C_CONST

Если компилятор C не поддерживает полностью ключевое слово const, то макросу const присваивается пустое значение. Некоторые компиляторы C не определяют константу __STDC__, но поддерживают const; некоторые компиляторы, определяющие __STDC__, не полностью поддерживают const. Программы могут просто использовать const, как будто любой компилятор C поддерживает его; для тех компиляторов, которые не имеют такой поддержки, `Makefile' или заголовочный файл настройки определят это слово как имеющее пустое значение.

Macro: AC_C_INLINE

Если компилятор C поддерживает inline, то ничего не делается. В противном случае, inline определяется равным __inline__ или __inline, если компилятор поддерживает один из этих вариантов, иначе inline определяется равным пустому значению.

Macro: AC_C_CHAR_UNSIGNED

Если тип C char является беззнаковым, то определяется переменная __CHAR_UNSIGNED__ (если компилятор C еще не определил ее).

Macro: AC_C_LONG_DOUBLE

Если компилятор C поддерживает тип long double, то определяется переменная HAVE_LONG_DOUBLE. Некоторые компиляторы C, которые не определяют __STDC__, поддерживают long double; а некоторые компиляторы, определяющие __STDC__, не поддерживают тип long double.

Macro: AC_C_STRINGIZE

Если препроцессор C поддерживает строковый (stringizing) оператор, то определяется переменная HAVE_STRINGIZE. Строковым (stringinzing)оператором является `#' и он используется в макросах, например:

#define x(y) #y

Macro: AC_CHECK_SIZEOF (type [, cross-size])

Определить SIZEOF_uctype равным числу байтов во встроенном типе C (или C++) type, например, `int' или `char *'. Если `type' неизвестен компилятору, то переменная получает значение 0. uctype является type, со строчными буквами, преобразованными в прописные, пробелы преобразуются в знаки подчеркивания, и знаки звездочка (*) заменяются на `P'. Если производится кросс-компиляция, то используется значение cross-size (если оно задано), в противном случае configure прекращает работу с выдачей сообщения об ошибке.

Например, вызов

AC_CHECK_SIZEOF(int *)

определяет SIZEOF_INT_P равным 8 на системах DEC Alpha AXP.

Macro: AC_INT_16_BITS

Если тип int имеет размер 16 бит, то определяется переменная INT_16_BITS. Этот макрос является устаревшим; вместо него лучше использовать общий макрос `AC_CHECK_SIZEOF(int)'.

Macro: AC_LONG_64_BITS

Если тип long int имеет размер 64 бита, то определяется переменная LONG_64_BITS. Этот макрос является устаревшим; вместо него лучше использовать вызов `AC_CHECK_SIZEOF(long)'.

4.8 Характеристики компилятора Fortran 77

Следующие макросы используются для проверки характеристик компилятора Fortran 77. Для проверки характеристик, не перечисленных в этом разделе, используйте макросы AC_TRY_COMPILE (see section 5.2 Проверка синтаксиса) или AC_TRY_RUN (see section 5.4 Проверка поведения во время выполнения), убедившись, что перед этим вы установили Fortran 77 текущим языком. AC_LANG_FORTRAN77 (see section 5.8 Выбор языка).

Macro: AC_F77_LIBRARY_LDFLAGS

Определяет ключи командной строки компоновщика (например, `-L' и `-l') для внутренних библиотек Fortran 77 и библиотек времени исполнения, которые требуются для правильной компоновки программ на Fortran 77 или разделяемых библиотек. Выходная переменная FLIBS устанавливается равной этим флагам.

Этот макрос предназначен для использования в ситуациях, когда необходимо смешать исходный код, например на C++ и Fortran 77, в одну программу или разделяемую библиотеку (see section `Смешивание кода Fortran 77 с кодом на C и C++' in GNU Automake).

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

Однако в этих случаях должны быть подключены и внутренние библиотеки Fortran 77, а также библиотеки времени исполнения, а компилятор/компоновщик C++ просто не знает, какие библиотеки Fortran 77 должны быть добавлены. Для определения библиотек Fortran 77 и был создан макрос AC_F77_LIBRARY_LDFLAGS.

4.9 Системные сервисы

Следующие макросы проверяют наличие сервисов операционной системы или ее возможности.

Macro: AC_CYGWIN

Проверяет наличие среды Cygwin. Если она присутствует, то переменная среды CYGWIN получает значение `yes'. В противном случае переменная CYGWIN получает пустое значение.

Macro: AC_EXEEXT

Определяет переменную подстановки EXEEXT, основанную на расширении файла, выдаваемого компилятором, после исключения файлов с расширениями .c, .o и .obj. Для Unix обычным значением является пустая строка, а для Win32 --- `.exe' и `.EXE'.

Macro: AC_OBJEXT

Определяет переменную подстановки OBJEXT, основанную на выводе компилятора, после исключения файлов с расширением .c. Обычно имеет значение `.o' в Unix, и `.obj' на системах Win32.

Macro: AC_MINGW32

Проверяет наличие среды компилятора MingW32. Если она присутствует, то переменная MINGW32 получает значение `yes'. В противном случае переменная MINGW32 получает пустое значение.

Macro: AC_PATH_X

Этот макрос пробует определить расположение заголовочных файлов и библиотек X Window System. Если пользователь задал ключи командной строки `--x-includes=dir' и `--x-libraries=dir', то используются заданные каталоги. Если один из ключей или оба не заданы, то пропущенные значения получают запуском xmkmf для простого `Imakefile' и разбора полученного файла `Makefile'. Если произошел сбой (например, если xmkmf отсутствует), то производится поиск в нескольких каталогах, где часто располагаются эти файлы. Если один из этих способов был удачен, то переменные командного процессора x_includes и x_libraries устанавливаются равными найденным каталогам (в том случае, если эти каталоги не входят в пути, в которых компилятор по умолчанию производит поиск).

Если оба этих метода дают сбой, или пользователь задал ключ командной строки `--without-x', то переменная командного процессора no_x получает значение `yes'; в противном случае она получает пустое значение.

Macro: AC_PATH_XTRA

Расширенная версия AC_PATH_X. Она добавляет к выходной переменной X_CFLAGS ключи компилятора C, которые необходимы X, а также флаги X для компоновщика к переменной X_LIBS. Если X не доступна, то добавляется `-DX_DISPLAY_MISSING' к X_CFLAGS.

Этот макрос также выполняет проверки специальных библиотек, в которых нуждаются некоторые системы для того, чтобы скомпилировать программу для X. Он добавляет все, что необходимо для таких систем, к выходной переменной X_EXTRA_LIBS. Он также проверяет наличие специальных библиотек X11R6, которые необходимо скомпоновать до использования `-lX11', и добавляет найденные библиотеки к выходной переменной X_PRE_LIBS.

Macro: AC_SYS_INTERPRETER

Проверяет, поддерживает ли система начало скриптов со строки в форме `#! /bin/csh' для выбора интерпретатора, который будет использоваться для данного скрипта. После запуска этого макроса код командного процессора в configure.in может проверить переменную interpval; она будет равна `yes', если система поддерживает `#!', и `no' в противном случае.

Macro: AC_SYS_LONG_FILE_NAMES

Если система поддерживает имена файлов длиннее 14 символов, то будет определена переменная HAVE_LONG_FILE_NAMES.

Macro: AC_SYS_RESTARTABLE_SYSCALLS

Если система автоматически перезапускает системный вызов, который был прерван сигналом, то определяется переменная HAVE_RESTARTABLE_SYSCALLS.

4.10 Варианты UNIX

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

Macro: AC_AIX

На AIX определяет переменную _ALL_SOURCE. Позволяет использовать некоторые функции BSD. Должен вызываться до макросов, запускающих компилятор C.

Macro: AC_DYNIX_SEQ

На Dynix/PTX (Sequent UNIX) добавляет `-lseq' к выходной переменной LIBS. Этот макрос является устаревшим; используйте вместо него AC_FUNC_GETMNTENT.

Macro: AC_IRIX_SUN

На IRIX (Silicon Graphics UNIX) добавляет `-lsun' к выходной переменной LIBS. Этот макрос является устаревшим. Если вы используете его для проверки наличия getmntent, то вместо него используйте макрос AC_FUNC_GETMNTENT. Если вы использовали его для NIS-версий функций работы с паролями и группами, то вместо него используйте `AC_CHECK_LIB(sun, getpwnam)'.

Macro: AC_ISC_POSIX

На POSIX-версии ISC UNIX определяет переменную _POSIX_SOURCE и добавляет `-posix' (для компилятора GNU C) или `-Xp' (для других компиляторов C) к выходной переменной CC. Это позволяет использовать возможности POSIX. Макрос должен быть вызван после вызова AC_PROG_CC и до вызова любых других макросов, которые запускают компилятор C.

Macro: AC_MINIX

На Minix определяет переменные _MINIX и _POSIX_SOURCE и определяет _POSIX_1_SOURCE со значением 2. Это позволяет использовать возможности POSIX. Должен вызываться до вызова других макросов, запускающих компилятор C.

Macro: AC_SCO_INTL

На SCO UNIX добавляет `-lintl' к выходной переменной LIBS. Этот макрос является устаревшим; вместо него используйте макрос AC_FUNC_STRFTIME.

Macro: AC_XENIX_DIR

На Xenix добавляет `-lx' к выходной переменной LIBS. Также, если используется `dirent.h', то к переменной LIBS добавляется `-ldir'. Этот макрос является устаревшим; вместо него используйте AC_HEADER_DIRENT.

5. Написание тестов

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

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

Эти макросы проверяют вывод системного компилятора C. Они не кэшируют результаты тестов для последующего использования (see section 6.3 Кэширование результатов), поскольку для генерации имени переменной кэша они не имеют достаточно информации о том, что они проверяют. Также по некоторым причинам они не печатают никаких сообщений. Проверки отдельных свойств компилятора С вызывают эти макросы и кэшируют свои результаты, а также выводят сообщения о том, что они проверяют.

Когда вы пишете тест свойства, который может быть применим для более чем одного пакета программного обеспечения, то лучше всего будет описать его как новый макрос. Для того, чтобы узнать, как это делается See section 7. Создание макросов.

5.1 Исследование деклараций
5.2 Проверка синтаксиса
5.3 Проверка библиотек
5.4 Проверка поведения во время выполнения
5.5 Переносимое программирование на языке командного процессора
5.6 Тестирование значений и файлов
5.7 Множество вариантов
5.8 Выбор языка

5.1 Исследование деклараций

Макрос AC_TRY_CPP используется для проверки существования конкретных заголовочных файлов. You can check for one at a time, or more than one if you need several header files to all exist for some purpose.

Macro: AC_TRY_CPP (includes, [action-if-true [, action-if-false]])

includes содержит директивы #include языков C или C++, а также объявления, над которыми выполняются подстановки переменных командного процессора, обратных кавычек и обратных слэшей. (В действительности, includes может быть любой программой на C, но другие выражения, вероятно, бесполезны). Если препроцессор не выдает сообщений об ошибках в течении обработки директивы, то выполняется код командного процессора action-if-true. В противном случае выполняется код action-if-false.

Этот макрос использует переменную CPPFLAGS, а не CFLAGS, поскольку `-g', `-O' и т. п. не являются правильными ключами для многих препроцессоров C.

Вот как узнать, содержит ли конкретный заголовочный файл определенное объявление, например, объявление типа, структуры, члена структуры или функции. Используйте макрос AC_EGREP_HEADER вместо прямого запуска команды grep для заголовочного файла; в некоторых системах символ может быть объявлен в другом заголовочном файле, а не в том, который вы проверяете в `#include'.

Macro: AC_EGREP_HEADER (pattern, header-file, action-if-found [, action-if-not-found])

Если вывод препроцессора, запущенного для системного заголовочного файла header-file соответствует регулярному выражению egrep pattern, то выполняются команды командного процессора action-if-found, в противном случае выполняются команды action-if-not-found.

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

AC_EGREP_CPP(yes, [#ifdef _AIX yes #endif ], is_aix=yes, is_aix=no)

Macro: AC_EGREP_CPP (pattern, program, [action-if-found [, action-if-not-found]])

program является текстом программы на C или C++, для которой выполняются подстановки переменных командного процессора, обратных кавычек и обратных слэшей. Если вывод препроцессора, обрабатывавшего program, соответствует регулярному выражению команды egrep pattern, то выполняется код командного процессора action-if-found, иначе выполняется action-if-not-found.

Этот макрос вызывает AC_PROG_CPP или AC_PROG_CXXCPP (в зависимости от того, какой из языков является текущим, see section 5.8 Выбор языка), если эти макросы еще не вызывались.

5.2 Проверка синтаксиса

Для проверки синтаксических возможностей компиляторов C, C++ или Fortran 77, например, распознавания определенных ключевых слов, используется макрос AC_TRY_COMPILE, который пробует откомпилировать маленькую программу, которая использует заданную возможность. Вы также можете использовать этот макрос для проверки структур и полей структур, которые присутствуют не во всех системах.

Macro: AC_TRY_COMPILE (includes, function-body, [action-if-found [, action-if-not-found]])

Создает тестовую программу на C, C++ или Fortran 77 (в зависимости от того, какой язык является текущим, see section 5.8 Выбор языка), для того, чтобы убедиться, что функция, чье тело состоит из function-body может быть скомпилирована.

Для C и C++, includes является любыми директивами #include, в которых нуждается код в function-body (параметр includes будет проигнорирован, если текущим языком является Fortran 77). Этот макрос при компиляции помимо переменной CPPFLAGS также использует переменные CFLAGS или CXXFLAGS, если текущим языком является C или C++. Переменная FFLAGS будет использована при компиляции, если текущим языком является Fortran 77.

Если файл компилируется нормально, то выполняются команды action-if-found, иначе выполняется action-if-not-found.

Этот макрос не пытается выполнить компоновку программы -- для этого вам придется использовать макрос AC_TRY_LINK (see section 5.3 Проверка библиотек).

5.3 Проверка библиотек

Для проверки библиотеки, функции или глобальной переменной скрипт configure попытается скомпилировать и скомпоновать небольшую программу, которая использует тестируемые возможности. Этим Autoconf отличается от Metaconfig, который обрабатывает файлы библиотеки C, используя nm или ar, чтобы определить, какие функции доступны. Попытка скомпоновать программу с функцией -- более надежный вариант, поскольку он избавляет от необходимости обрабатывать различные ключи командной строки и форматы выдачи результатов программ nm и ar, а также выяснять расположение стандартных библиотек. Этот подход также позволяет конфигурировать кросс-компиляцию, а также проверять поведение функции во время выполнения. С другой стороны, этот подход может оказаться значительно более медленным, чем однократное сканирование библиотек.

Компоновщики в нескольких существующих системах не возвращают статус ошибки, если не могут найти какие-либо символы при компоновке. Эта ошибка делает невозможным использование на таких системах скриптов настройки, созданных Autoconf. Однако, некоторым из них могут быть заданы ключи, которые позволяют получить правильный статус завершения работы. Эту проблему в настоящий момент Autoconf не может обработать автоматически. Если пользователь столкнется с таким, то он может решить эту проблему установкой переменной среды LDFLAGS, передавая компоновщику необходимые ключи командной строки (например, `-Wl,-dn' на MIPS RISC/OS).

Макрос AC_TRY_LINK используется для компиляции тестовой программы для проверки функций и глобальных переменных. Он также используется макросом AC_CHECK_LIB для проверки библиотек (see section 4.2 Файлы библиотек), временно добавляя проверяемую библиотеку в переменную LIBS и пытаясь скомпоновать маленькую программу.

Macro: AC_TRY_LINK (includes, function-body, [action-if-found [, action-if-not-found]])

В зависимости от текущего языка (see section 5.8 Выбор языка), создается тестовая программа, для того чтобы выяснить, может ли быть скомпилирована и скомпонована функция, чье тело состоит из аргумента function-body.

Для C и C++, includes является любыми директивами #include, в которых нуждается код в function-body (параметр includes будет проигнорирован, если текущим языком является Fortran 77). Этот макрос при компиляции помимо переменной CPPFLAGS также использует переменные CFLAGS или CXXFLAGS, если текущим языком является C или C++. Переменная FFLAGS будет использована при компиляции, если текущим языком является Fortran 77. Однако в любом случае при компоновке будут использованы переменные LDFLAGS и LIBS.

Если файл компилируется и компонуется, то выполняются команды action-if-found, в противном случае --- action-if-not-found.

Macro: AC_TRY_LINK_FUNC (function, [action-if-found [, action-if-not-found]])

В зависимости от текущего языка see section 5.8 Выбор языка), создается тестовая программа для того, чтобы убедиться, что программа, чье тело состоит их прототипа и вызова function, может быть скомпилирована и скомпонована.

Если файл компилируется и компонуется без ошибок, то выполняется код action-if-found, в противном случае выполняется action-if-not-found.

Macro: AC_TRY_LINK_FUNC (function, [action-if-found [, action-if-not-found]])

Этот макрос пробует скомпилировать и скомпоновать маленькую программу, которая компонуется с function. Если файл компилируется и компонуется без ошибок, то запускается код командного процессора action-if-found, в противном случае выполняется action-if-not-found.

Macro: AC_COMPILE_CHECK (echo-text, includes, function-body, action-if-found [, action-if-not-found])

Этот макрос является устаревшей версией AC_TRY_LINK. Он отличается тем, что выдает сообщение `checking for echo-text' в поток стандартного вывода, в том случае, если аргумент echo-text не является пустым. Вместо этого макроса для выдачи сообщений используйте AC_MSG_CHECKING и AC_MSG_RESULT (see section 6.4 Выдача сообщений).

5.4 Проверка поведения во время выполнения

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

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

5.4.1 Запуск тестовых программ
5.4.2 Рекомендации по написанию тестовых программ
5.4.3 Тестовые функции

5.4.1 Запуск тестовых программ

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

Macro: AC_TRY_RUN (program, [action-if-true [, action-if-false [, action-if-cross-compiling]]])

Аргумент program является текстом программы на языке C, для которой выполняются подстановки переменных командного процессора, а также обратных кавычек и обратных слэшей. Если она компилируется и компонуется, и при выполнении возвращает код завершения 0, то выполняется код командного процессора action-if-true. В противном случае выполняются команды action-if-false; код завершения тестовой программы доступен в переменной командного процессора `$?'. При компиляции этот макрос использует переменные CFLAGS или CXXFLAGS, CPPFLAGS, LDFLAGS и LIBS.

Если используемый компилятор C не создает исполняемых файлов, которые запускаются на той же системе, где выполняется скрипт configure, то тестовая программа не запускается. Если задан аргумент action-if-cross-compiling, то вместо программы запускается код, заданный в этом аргументе. В противном случае configure выдает сообщение об ошибке и прекращает работу.

Постарайтесь сделать значения по умолчанию пессимистическими, если кросс-компиляция не позволяет проверить поведение времени выполнения. Это можно сделать, передав макросу AC_TRY_RUN необязательный последний аргумент. autoconf выдает предупреждающее сообщение при создании configure каждый раз, когда встречается вызов макроса AC_TRY_RUN с незаданным аргументом action-if-cross-compiling. Вы можете игнорировать это предупреждение, хотя пользователи не смогут настроить ваш пакет для кросс-компиляции. Несколько макросов, поставляемых в составе Autoconf, выдают это предупреждающее сообщение.

Для конфигурирования для кросс-компиляции вы также можете выбрать значения параметров, основываясь на каноническом имени системы (see section 8. Ручная настройка). В качестве альтернативы, вы можете установить правильное значение для целевой системы в кэш-файле с результатами тестов (see section 6.3 Кэширование результатов).

Для задания значений по умолчанию для вызовов макроса AC_TRY_RUN, которые включены в другие макросы (включая те, которые поставляются с Autoconf), вы можете вызвать макрос AC_PROG_CC до их вызова. Затем, если переменная командного процессора cross_compiling имеет значение `yes', то используется альтернативный метод для получения результатов, вместо вызова макросов.

Macro: AC_C_CROSS

Этот макрос является устаревшим; он ничего не делает.

5.4.2 Рекомендации по написанию тестовых программ

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

Тестовые программы могут использовать директивы #if или #ifdef для проверки значений макросов препроцессора, определенных уже проведенными тестами. Например, если вы вызовете AC_HEADER_STDC, то далее в `configure.in' можно использовать тестовую программу, которая в зависимости от условия включает заголовочные файлы ANSI C:

#if STDC_HEADERS # include #endif

Если тестовой программе нужно использовать или создать файл данных, то задавайте этому файлу имя, которое начинаются с `conftest', например, `conftestdata'. Скрипт configure после выполнения тестовых программ а также в случае прерывания работы скрипта удаляет эти файлы с помощью команды `rm -rf conftest*'.

5.4.3 Тестовые функции

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

#ifdef __cplusplus foo(int i) #else foo(i) int i; #endif

Функции, которые объявляются в тестовых программах, должны быть также объявлены с применением прототипов `extern "C"', для использования с компиляторами C++. Убедитесь, что вы не включаете заголовочные файлы, содержащие конфликтующие прототипы.

#ifdef __cplusplus extern "C" void *malloc(size_t); #else char *malloc(); #endif

Если тестовая программа вызывает функцию с неправильными параметрами (просто чтобы убедиться, что такая существует), то организуйте программу таким образом, чтобы эта функция никогда не была вызвана. Это можно сделать путем вызова ее в другой функции, которая никогда не вызывается. Вы не можете сделать это, поместив вызов функции после вызова функции exit, поскольку GCC версии 2 знает о том, что функция exit никогда не возвращается в точку вызова, и оптимизирует любой код, который следует за ней в том же блоке.

Если вы включаете какой-либо заголовочный файл, то убедитесь, что функции, находящиеся в этих файлах, вызываются с правильным числом параметров, даже если все эти параметры равны нулю. Это нужно, чтобы избежать ошибок компиляции из-за несоответствия прототипов. GCC версии 2 имеет внутренние прототипы нескольких функций, которые он встраивает в код автоматически; например, к таким относится memcpy. Для того, чтобы избежать ошибок при их проверке, либо передавайте этим функциям правильное количество аргументов, либо повторно объявите эти функции с другим типом возвращаемого значения (например, как char).

5.5 Переносимое программирование на языке командного процессора

Есть определенные техники программирования скриптов командного процессора, которых вам следует избегать, чтобы ваш код был переносим. Bourne shell и совместимые с ним процессора, такие как Bash и Korn, развивались в течении многих лет, но для того, чтобы избежать трудностей, не используйте возможностей, которые были добавлены после выпуска UNIX версии 7, примерно в 1977 году. Вы не должны использовать функции командного процессора, псевдонимы (aliases), отрицательные классы символов и другие возможности, которые присутствуют не во всех версиях командных процессоров, совместимых с процессором Bourne; ограничьте себя общим знаменателем. Даже unset не поддерживается всеми командными процессорами! При указании интерпретатора ставьте пробел после символов `#!', например,

#! /usr/bin/perl

Если вы уберете пробел перед путевым именем, то системы типа 4.2BSD, такие как Sequent DYNIX, будут просто игнорировать эту строку, поскольку они интерпретируют `#! /' как 4-х байтовое магическое число.

Набор внешних программ, которые можно запускать из скрипта configure, довольно мал. See section `Utilities in Makefiles' in GNU Coding Standards, ниже приведен список этих программ. Это ограничение позволяет пользователям начать с небольшого количества программ, постепенно компилируя остальные, и избежать слишком большого числа зависимостей между пакетами.

Многие такие внешние утилиты обладают общим подмножеством переносимых возможностей; например, не полагайтесь на то, что команда ln имеет ключ `-f', а cat вообще имеет какие-либо ключи. Скрипты sed не должны содержать комментариев или использовать метки длиннее 8 символов. Не используйте `grep -s' для запрещения вывода, поскольку `grep -s' на System V не запрещает вывод, а запрещает только сообщения об ошибках. Вместо этого ключа лучше перенаправьте стандартные потоки вывода и сообщений об ошибках (сообщения о несуществующих файлах) программы grep на устройство `/dev/null'. Проверяйте код возврата grep, чтобы узнать, произошло ли совпадение.

5.6 Тестирование значений и файлов

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

Программа test используется для выполнения многих проверок файлов и строк. Она часто запускается альтернативным способом, через имя `[', но использование этого имени в коде Autoconf приведет к ошибкам, потому что этот символ является символом кавычек в m4.

Если вам необходимо выполнить несколько проверок, используя команду test, то объединяйте их с помощью операторов командного процессора `&&' и `||', а не используйте операторы программы test `-a' и `-o'. На System V приоритеты операторов `-a' и `-o' неправильно соотносятся с приоритетами унарных операторов; из-за этого POSIX не определяет эти операторы, так что их использование приводит к непереносимому коду. Если вы в одном выражении используете как `&&', так и `||', то помните, что они имеют одинаковый приоритет.

Скрипты configure, поддерживающие кросс-компиляцию, не должны не делать ничего, что тестирует свойства системы, на которой выполняется скрипт. Но иногда вам может понадобиться проверить, существует ли определенный файл. Чтобы сделать это используйте команды `test -f' или `test -r'. Не используйте команду `test -x', поскольку 4.3BSD не поддерживает ее.

Другой непереносимой конструкцией программирования командного процессора является

var=${var:-value}

Она предназначена для установки значения переменной var равным value, но только в тех случаях, когда переменная еще не имеет значения. Если var уже было присвоено значение, даже равное пустой строке, то оно остается неизменным. Старые командные процессоры BSD, включая Ultrix-версию sh, не воспринимают символ двоеточия, выдают ошибку и прекращают работу. Переносимым эквивалентом данной конструкции является

: ${var=value}

5.7 Множество вариантов

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

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

AC_MSG_CHECKING(как получить тип файловой системы) fstype=no # Порядок этих действий является важным. AC_TRY_CPP([#include #include ], AC_DEFINE(FSTYPE_STATVFS) fstype=SVR4) if test $fstype = no; then AC_TRY_CPP([#include #include ], AC_DEFINE(FSTYPE_USG_STATFS) fstype=SVR3) fi if test $fstype = no; then AC_TRY_CPP([#include #include ], AC_DEFINE(FSTYPE_AIX_STATFS) fstype=AIX) fi # (остальные варианты пропущены в этом примере) AC_MSG_RESULT($fstype)

5.8 Выбор языка

Пакеты, использующие одновременно и C, и C++, нуждаются в проверке возможностей обоих компиляторов. Созданные Autoconf скрипты configure по умолчанию выполняют проверку возможностей компилятора C. Нижеописанные макросы определяют, компилятор какого языка будет использоваться в тестах, которые последуют за вызовом этого макроса в `configure.in'.

Macro: AC_LANG_C

Выполняет тесты компиляции, используя переменные CC и CPP, а также используя расширение `.c' для тестовых программ. Устанавливает переменную командного процессора cross_compiling в значение, вычисленное макросом AC_PROG_CC, если он был запущен, и в пустое значение в противном случае.

Macro: AC_LANG_CPLUSPLUS

Выполняет тесты компиляции, используя переменные CXX и CXXPP, а также используя расширение `.C' для тестовых программ. Устанавливает переменную командного процессора cross_compiling в значение, вычисленное макросом AC_PROG_CXX, если он был запущен, и в пустое значение в противном случае.

Macro: AC_LANG_FORTRAN77

Выполняет тесты компиляции, используя переменную F77, а также используя расширение `.f' для тестовых программ. Устанавливает переменную командного процессора cross_compiling в значение, вычисленное макросом AC_PROG_F77, если он был запущен, и в пустое значение в противном случае.

Macro: AC_LANG_SAVE

Запоминает в стеке значение текущего языка (установленное макросами AC_LANG_C, AC_LANG_CPLUSPLUS или AC_LANG_FORTRAN77). Не изменяет значение текущего языка. Используйте этот макрос и AC_LANG_RESTORE в макросах, которым необходимо временно переключиться на конкретный язык.

Macro: AC_LANG_RESTORE

Выбирает язык, который был сохранен на вершине стека, где он был сохранен макросом AC_LANG_SAVE, и удаляет его со стека. Этот макрос эквивалентен вызову AC_LANG_C, AC_LANG_CPLUSPLUS или AC_LANG_FORTRAN77, в зависимости от того, который из них действовал во время последнего вызова макроса AC_LANG_SAVE.

Не вызывайте этот макрос больше раз, чем было вызовов AC_LANG_SAVE.

Macro: AC_REQUIRE_CPP

Убеждается, что препроцессор, который должен сейчас использоваться, был найден. Вызывает макрос AC_REQUIRE (see section 7.4.1 Требуемые макросы) с аргументом, равным либо AC_PROG_CPP, либо AC_PROG_CXXCPP, в зависимости от того, какой язык был выбран.

6. Результаты тестов

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

6.1 Определение символов препроцессора С
6.2 Установка выходных переменных
6.3 Кэширование результатов		Ускорение работы при последующих запусках configure.
6.4 Выдача сообщений

6.1 Определение символов препроцессора С

Обычно после проверки какой-либо возможности устанавливается символ препроцессора, отражающий результат проверки. Это происходит при вызове макроса AC_DEFINE или AC_DEFINE_UNQUOTED.

По умолчанию макрос AC_OUTPUT помещает символы, определенные этими макросами в выходную переменную DEFS, которая по одному ключу `-Dsymbol=value' на каждый символ. В отличии от Autoconf версии 1, переменная DEFS не определена в течении работы configure. Для проверки того, определен ли уже какой-либо символ препроцессора C, проверьте значение соответствующей переменной кэша, как показано в этом примере:

AC_CHECK_FUNC(vprintf, AC_DEFINE(HAVE_VPRINTF)) if test "$ac_cv_func_vprintf" != yes; then AC_CHECK_FUNC(_doprnt, AC_DEFINE(HAVE_DOPRNT)) fi

Если был вызван макрос AC_CONFIG_HEADER, то AC_OUTPUT вместо определения переменной DEFS создает заголовочный файл путем подстановки правильных значений в директивы #define, заданные в файле-шаблоне. See section 3.4 Заголовочные файлы конфигурации, для дополнительной информации об этом способе вывода результатов.

Macro: AC_DEFINE (variable [, value [, description]])

Определяет переменную препроцессора C variable. Если аргумент value задан, то устанавливает переменную variable в это значение (без изменений), в противном случае устанавливает ее равной 1. value не должен содержать символов перевода строки, а если вы не используете AC_CONFIG_HEADER, то он не должен содержать символы `#', поскольку make имеет склонен проглатывать их. Для использования переменной командного процессора (которая необходима, если нужно определить значение, содержащее символ, являющийся кавычкой в m4 `[' или `]') вам следует использовать AC_DEFINE_UNQUOTED. Аргумент description полезен только в том случае, если вы используете макрос AC_CONFIG_HEADER. В этом случае description будет помещен в созданный файл `config.h.in' в качества комментария к определению символа; макросу не нужно быть упомянутым в `acconfig.h'. Следующий пример определяет переменную препроцессора C EQUATION со значением, равным строковой константе `"$a > $b"':

AC_DEFINE(EQUATION, "$a > $b")

Macro: AC_DEFINE_UNQUOTED (variable [, value [, description]])

Подобно AC_DEFINE, но над переменными variable и value выполняется ряд преобразований: подстановка переменных (`$'), подстановка результатов выполнения команд (``') и экранирование символов обратной косой черты (`\'). Символы одиночных и двойных кавычек в value не имеют специального смысла. Используйте этот макрос вместо AC_DEFINE, когда variable или value являются переменными командного процессора. Примеры:

AC_DEFINE_UNQUOTED(config_machfile, "${machfile}") AC_DEFINE_UNQUOTED(GETGROUPS_T, $ac_cv_type_getgroups) AC_DEFINE_UNQUOTED(${ac_tr_hdr})

Из-за синтаксических странностей командного процессора Bourne не следует использовать точку с запятой для разделения вызовов макросов AC_DEFINE или AC_DEFINE_UNQUOTED от вызова других макросов или кода командного процессора; это может привести к синтаксическим ошибкам в результирующем скрипте configure. Вместо этого используйте пробелы или переводы строк. То есть, следует писать так:

AC_CHECK_HEADER(elf.h, AC_DEFINE(SVR4) LIBS="$LIBS -lelf")

либо так:

AC_CHECK_HEADER(elf.h, AC_DEFINE(SVR4) LIBS="$LIBS -lelf")

но не так:

AC_CHECK_HEADER(elf.h, AC_DEFINE(SVR4); LIBS="$LIBS -lelf")

6.2 Установка выходных переменных

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

Macro: AC_SUBST (variable)

Создает выходную переменную из переменной командного процессора. Заставляет AC_OUTPUT подставлять переменную variable в выходные файлы (обычно это один или несколько файлов `Makefile'). Это означает, что AC_OUTPUT будет заменять вхождения `@variable@' во входных файлах на значение переменной командного процессора variable, которое она имела при вызове макроса AC_OUTPUT. Значение variable не должно содержать символы новой строки.

Macro: AC_SUBST_FILE (variable)

Другой способ создания выходной переменной из переменной командного процессора. Заставляет AC_OUTPUT вставить (без подстановок) в выходные файлы содержимое файла, указанного в переменной командного процессора variable. Это означает, что AC_OUTPUT будет заменять вхождения `@variable@' в выходных файлах (таких как `Makefile.in') на содержимое файла, имя которого содержалось в переменной variable в момент вызова макроса AC_OUTPUT. Установите значение этой переменной в `/dev/null' для случаев, когда вставляемый файл отсутствует.

Этот макрос полезен для вставки фрагментов `Makefile', содержащих специальные зависимости или другие директивы make для отдельных типов машин и целей в результирующие файлы `Makefile'. Например, файл `configure.in' может содержать:

AC_SUBST_FILE(host_frag)dnl host_frag=$srcdir/conf/sun4.mh

и файл `Makefile.in' может содержать:

@host_frag@

6.3 Кэширование результатов

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

Macro: AC_CACHE_VAL (cache-id, commands-to-set-it)

Проверяет, что доступны результаты проверки, на которые указывает cache-id. Если результаты проверки находятся в кэше, и скрипту configure не был задан ключ `--quiet' или `--silent', то выдать сообщение о том, что результаты были взяты из кэша; в противном случае запустить код командного процессора commands-to-set-it. Эти команды не должны иметь побочных эффектов, за исключением установки переменной cache-id. В частности, они не должны вызывать макрос AC_DEFINE; это должен делать код, следующий за вызовом AC_CACHE_VAL, основываясь на кэшированном значении. Они также не должны выдавать никаких сообщений, например, с помощью макроса AC_MSG_CHECKING; это надо выполнять до вызова AC_CACHE_VAL, так что сообщения будут печататься вне зависимости от того, будут ли результаты взяты из кэша или будут определены с помощью выполнения кода командного процессора. Если для определения значения будет запущен код командного процессора, то полученное значение будет сохранено в кэш-файле перед тем, как configure будет создавать выходные файлы. See section 6.3.1 Имена переменных кэша, для того чтобы узнать, как выбрать имя переменной cache-id.

Macro: AC_CACHE_CHECK (message, cache-id, commands)

Обертка для макроса AC_CACHE_VAL, которая берет на себя заботу о выдаче сообщений. Этот макрос обеспечивает удобную и короткую форму записи наиболее распространенных способов использования этих макросов. Он вызывает макрос AC_MSG_CHECKING для выдачи сообщения message, затем вызывает AC_CACHE_VAL с аргументами cache-id и commands и, наконец, вызывает AC_MSG_RESULT с аргументом cache-id.

Macro: AC_CACHE_LOAD

Загружает значения из существующего кэш-файла, или создает новый, если кэш-файл не найден. Автоматически вызывается из макроса AC_INIT.

Macro: AC_CACHE_SAVE

Записывает все кэшированные значения в кэш-файл. Этот макрос автоматически из макроса AC_OUTPUT, но полезно бывает вызывать AC_CACHE_SAVE в ключевых точке файла `configure.in'. При это кэш сохраняется на тот случай, если работа скрипта `configure' будет прервана.

6.3.1 Имена переменных кэша
6.3.2 Кэш-файлы		Файлы, которые configure использует для кэширования.

6.3.1 Имена переменных кэша

Имена переменных кэша должны иметь следующий формат:

package-prefix_cv_value-type_specific-value[_additional-options]

Например, `ac_cv_header_stat_broken' или `ac_cv_prog_gcc_traditional'. Имя переменной состоит из следующих частей:

package-prefix

Сокращенное название вашего пакета или организации; с такого же префикса вы должны начинать локальные макросы Autoconf, но только здесь этот префикс записывается в нижнем регистре. Макросы, распространяемые с Autoconf, используют префикс `ac'.

_cv_

Показывает, что эта переменная командного процессора является кэшированным значением.

value-type

Соглашение по классификации значений кэша, для создания рациональной системы наименования. Значения, используемые в Autoconf, перечислены в 7.2 Имена макросов.

specific-value

Для какого члена класса кэшированных значений применяется данный тест. Например, к какой функции (`alloca'), программе (`gcc') или выходной переменной (`INSTALL').

additional-options

Конкретное поведение конкретного члена класса, к которому применяется этот тест. Например, `broken' ("сломано") или `set' ("установлено"). Эта часть имени может быть опущена.

Значения кэшированных переменных не могут содержать переводы строк. Обычно их значения являются логическими значениями (`yes' или `no') или именами файлов или функций, поэтому это ограничение не критично.

6.3.2 Кэш-файлы

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

По умолчанию в качестве кэш-файла `configure' использует файл `./config.cache', создавая его, если он не существует. configure распознает ключ командной строки `--cache-file=file', который позволяет использовать другой кэш-файл; этот ключ используется configure, когда он вызывает скрипты configure, находящиеся в подкаталогах, так что они используют общий кэш. See section 3.5 Настройка других пакетов, находящихся в подкаталогах, где описано, как задавать подкаталоги с помощью макроса AC_CONFIG_SUBDIRS.

Использование ключа `--cache-file=/dev/null' запрещает кэширование, например, для отладки configure. Скрипт `config.status' смотрит на кэш-файл только если запустить его с ключом `--recheck', чтобы повторно выполнить configure. Если вы предчувствуете долгий период отладки, то можете запретить загрузку и сохранение кэша путем переопределения макросов работы с кэшем в начале `configure.in':

define([AC_CACHE_LOAD], )dnl define([AC_CACHE_SAVE], )dnl AC_INIT(whatever) ... rest of configure.in ...

Попытка распространения кэш-файлов для определенных типов систем неверна в корне. Пытаясь сделать это, вы получаете полную свободу совершать ошибки, а также сталкиваетесь с массой административных проблем, связанных с поддержкой этих файлов. Для возможностей, которые нельзя определить автоматически, используйте стандартный способ канонического типа системы и компоновки файлов (see section 8. Ручная настройка).

На отдельной системе кэш-файл постепенно будет накапливать результаты запусков скрипта configure; первоначально он вообще не будет существовать. Запуск configure объединяет новые кэшированные результаты с уже существующим кэш-файлом. Для того, чтобы сделать работу скрипта более простой, скрипт инициализации на данной машине, может указать общесистемный кэш-файл, который будет использоваться вместо используемого по умолчанию, поскольку каждый раз используется один и тот же компилятор С (see section 9.5 Установка значений по умолчанию для машины). Если ваш скрипт, или макрос, вызываемые из `configure.in', прерывает процесс настройки, то полезно будет сохранить кэшированные данные несколько раз в ключевых точках скрипта. Делая это, вы уменьшите время, затраченное при перезапуске скрипта конфигурации после исправления ошибки, которая вызвала предыдущий останов работы.

... AC_INIT, etc. ... dnl проверки программ AC_PROG_CC AC_PROG_GCC_TRADITIONAL ... дополнительные проверки программ... AC_CACHE_SAVE dnl проверка библиотек AC_CHECK_LIB(nsl, gethostbyname) AC_CHECK_LIB(socket, connect) ... другие проверки библиотек ... AC_CACHE_SAVE dnl Might abort... AM_PATH_GTK(1.0.2, , exit 1) AM_PATH_GTKMM(0.9.5, , exit 1)

6.4 Выдача сообщений

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

AC_MSG_RESULT([never mind, I found the BASIC compiler])

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

Macro: AC_MSG_CHECKING (feature-description)

Уведомляет пользователя о том, что configure проверяет конкретную возможность. Этот макрос печатает сообщение, которое начинается с `checking ' и заканчивается `...' без перехода на новую строку. Вслед за вызовом этого макроса следует использовать макрос AC_MSG_RESULT, который выдает результат проверки и символ перевода строки. Аргумент feature-description должен содержать что-нибудь типа `понимает ли компилятор Fortran комментарии в стиле C++' или `for c89'.

Этот макрос ничего не выводит, если configure запущен с ключами `--quiet' или `--silent'.

Macro: AC_MSG_RESULT (result-description)

Уведомляет пользователя о результатах проверки. Аргумент result-description почти всегда содержит значение переменной кэша для данного теста, обычно равно `yes', `no' или имени файла. Этот макрос должен вызываться после вызова AC_MSG_CHECKING и аргумент result-description по смыслу должен дополнять сообщение выданное вызовом AC_MSG_CHECKING.

Этот макрос ничего не выводит, сели configure запущен с ключами `--quiet' или `--silent'.

Macro: AC_MSG_ERROR (error-description)

Уведомляет пользователя об ошибке, которая препятствует работе configure. Этот макрос печатает сообщение об ошибке в стандартный поток вывода и заканчивает работу configure с ненулевым статусом. Аргумент error-description должен содержать что-то подобное `неправильное значение $HOME для \$HOME'.

Macro: AC_MSG_WARN (problem-description)

Уведомляет пользователя configure о возможной проблеме. Этот макрос выдает сообщение в стандартный поток сообщений об ошибках; после этого configure продолжает свое выполнение, так что макросы, вызвавший AC_MSG_WARN должен предоставить действия по умолчанию для ситуаций, о которых он выдавал предупреждения. Аргумент problem-description должен содержать что-то подобное `кажется ln -s создает жесткие ссылки'.

Следующие два макроса являются устаревшими и являются альтернативой для макросов AC_MSG_CHECKING и AC_MSG_RESULT.

Macro: AC_CHECKING (feature-description)

Этот макрос подобен AC_MSG_CHECKING, за исключением того, что он выдает символ перевода строки после вывода feature-description. Он в основном полезен для выдачи общего описания группы проверок, например:

AC_CHECKING(if stack overflow is detectable)

Macro: AC_VERBOSE (result-description)

Этот макрос подобен AC_MSG_RESULT, за исключением того, что его вызов следует за вызовом AC_CHECKING, а не AC_MSG_CHECKING; выдаваемое им сообщение начинается с символа табуляции. Этот макрос считается устаревшим.

7. Создание макросов

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

7.1 Определение макросов		Базовый формат макросов Autoconf.
7.2 Имена макросов
7.3 Заключение в кавычки
7.4 Зависимости между макросами

7.1 Определение макросов

Макросы Autoconf определяются с помощью макроса AC_DEFUN, который подобен встроенному макросу define программы m4. В добавление к определению макроса, AC_DEFUN добавляет к нему некоторый код, который используется для ограничения порядка вызовы макросов (see section 7.4.1 Требуемые макросы).

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

AC_DEFUN(macro-name, [macro-body])

Квадратные скобки не показывают необязательный параметр: они должны присутствовать в определении макроса для избежания проблем расширения макроса (see section 7.3 Заключение в кавычки). Вы можете ссылаться на передаваемые макросу параметры с помощью переменных `$1', `$2' и т.п.

Для ввода комментариев в m4, используйте встроенный макрос m4 dnl; он заставляет m4 игнорировать текст до начала новой строки. Он не нужен между определениями макросов в файлах `acsite.m4' и `aclocal.m4', поскольку весь вывод удаляется до вызова AC_INIT.

See section `How to define new macros' in GNU m4, для более полной информации о написании макросов m4.

7.2 Имена макросов

Все макросы Autoconf названы именами, состоящими из букв заглавных букв и начинающихся с префикса `AC_', для того, чтобы избежать конфликтов с другим текстом. Все переменные командного процессора, которые используются для внутренних целей в этих макросах, как правило называются именами из прописных букв и начинаются с `ac_'. Чтобы обеспечить, что ваши макросы не конфликтовали с существующими или будущими макросами Autoconf, вы должны использовать собственный префикс для ваших макросов и переменных командного процессора. В качестве возможных значений вы можете использовать ваши инициалы, или сокращенное название вашей организации или пакета программ.

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

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

C

Встроенные возможности языка C.

DECL

Объявления переменных C в заголовочных файлах.

FUNC

Функции в библиотеках.

GROUP

Группа UNIX владеющая файлами.

HEADER

Заголовочные файлы.

LIB

Библиотеки C.

PATH

Полные путевые имена файлов, включая программы.

PROG

Базовые имена программ.

STRUCT

Определения структур C в заголовочных файлах.

SYS

Свойства операционной системы.

TYPE

Встроенные или объявленные типы C.

VAR

Переменные C в библиотеках.

После категории следует имя тестируемого свойства. Любые дополнительные слова в имени макроса указывают на специфические аспекты тестируемого свойства. Например, AC_FUNC_UTIME_NULL проверяет поведение функции utime при вызове ее с указателем равным NULL.

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

7.3 Заключение в кавычки

Макросы, которые вызываются другими макросами оцениваются программой m4 несколько раз; каждая оценка может потребовать другого уровня кавычек для предотвращения нежелательных расширений макросов или встроенных возможностей m4, таких как `define' и `$1'. Кавычки также требуются вокруг аргументов макросов, которые содержат запятые, поскольку запятые разделяют аргументы макроса. Также хорошей привычкой является заключение в кавычки аргументов, которые содержат символы новой строки или вызовы других макросов.

Autoconf изменяет символ-кавычку программы m4 со значений по умолчанию ``' и `'' на `[' и `]', поскольку многие из макросов используют не сочетаемые ``' и `''. Однако в нескольких местах макросам необходимо использовано символов-скобок (обычно в тексте программ на языке C или в регулярных выражениях). В этих местах макросы используют встроенную команду m4 changequote для временного изменения символа-кавычек на `<<' и `>>'. (Иногда, если им нет нужды заключать в кавычки что-либо, то они запрещают заключение в кавычки установкой символов-кавычек равных пустым символам). Вот пример использования:

AC_TRY_LINK( changequote(<<, >>)dnl <<#include #ifndef tzname /* For SGI. */ extern char *tzname[]; /* RS6000 and others reject char **tzname. */ #endif>>, changequote([, ])dnl [atoi(*tzname);], ac_cv_var_tzname=yes, ac_cv_var_tzname=no)

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

Однако также возможно поместить слишком много уровней кавычек. Если это случается, то полученный скрипт configure будет содержать не-расширенный макрос. Программа autoconf выполняет проверку этой проблемы, выполняя команду `grep AC_ configure'.

7.4 Зависимости между макросами

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

7.4.1 Требуемые макросы
7.4.2 Предлагаемый порядок
7.4.3 Устаревшие макросы

7.4.1 Требуемые макросы

Макрос, которое вы можете написать, может нуждаться в значениях, которые перед этим были вычислены другими макросами. Например, AC_DECL_YYTEXT проверяет вывод flex или lex, так что он зависит от AC_PROG_LEX, который должен быть вызван перед этим для установки переменной командного процессора LEX.

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

Macro: AC_REQUIRE (macro-name)

Если макрос m4 с именем macro-name еще не был вызван, то необходимо вызвать его (без каких-либо аргументов). Убедитесь, что вы поместили имя macro-name в квадратные кавычки. macro-name должен быть определен с использованием макроса AC_DEFUN или должен содержать вызов макроса AC_PROVIDE для того, чтобы указать, что он был вызван.

Альтернативой этому использованию AC_DEFUN является использование define и вызов макроса AC_PROVIDE. Поскольку этот подход не предотвращает вложенных сообщений, то эта техника является устаревшей.

Macro: AC_PROVIDE (this-macro-name)

Запоминает тот факт, что макрос this-macro-name был вызван. this-macro-name должен быть именем макроса, который вызывает AC_PROVIDE. Для простого получения этого имени используйте встроенную переменную m4 с именем $0, примерно так:

AC_PROVIDE([$0])

7.4.2 Предлагаемый порядок

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

Autoconf предоставляет макрос AC_BEFORE для предупреждения пользователя о тех случаях, когда этот макросы вызываются в неправильном порядке в файле `configure.in'. Предупреждение выдается при создании скрипта configure из файла `configure.in', а не при запуске созданного configure. Например, AC_PROG_CPP проверяет может ли компилятор C запустить препроцессор C с ключом `-E'. Он должен быть вызван после любого из макросов, который изменяет поведение используемого компилятора C, такого как AC_PROG_CC. Так что макрос AC_PROG_CC должен содержать:

AC_BEFORE([$0], [AC_PROG_CPP])dnl

Это вызывает выдачу предупреждения пользователю, если вызов AC_PROG_CPP уже произошел до вызова макроса AC_PROG_CC.

Macro: AC_BEFORE (this-macro-name, called-macro-name)

Заставляет m4 выдать предупреждающее сообщение в стандартный поток сообщений об ошибках в том случае, если макроса called-macro-name уже был вызван. this-macro-name должен быть именем макроса, который вызывает AC_BEFORE. Макрос called-macro-name должен быть определен используя макрос AC_DEFUN или должен содержать вызов AC_PROVIDE для того, чтобы показать, что он был вызван.

7.4.3 Устаревшие макросы

Технология настройки и переносимости развивалась многие годы. Часто разрабатывались лучшие решения отдельных проблем, или систематизировались специальные подходы. Этот процесс происходил во многих частях Autoconf. Результатом этого является то, что некоторые макросы в настоящее время считаются устаревшими; они до сих пор работают, но не считаются лучшим способом решения. Autoconf предоставляет макрос AC_OBSOLETE, который предупреждает пользователей создающих скрипты configure о том, что они используют устаревшие макросы, чтобы поощрить их к использованию современных макросов. Простой вызов этого макроса выглядит так:

AC_OBSOLETE([$0], [; use AC_CHECK_HEADERS(unistd.h) instead])dnl

Macro: AC_OBSOLETE (this-macro-name [, suggestion])

Заставляет m4 выдать сообщение в стандартный поток сообщений об ошибках, которое говорит о том, что макрос this-macro-name является устаревшим, и выдает имя файла и номер строки где был вызван этот макрос this-macro-name должен именем макроса, который производит вызов AC_OBSOLETE. Если задан аргумент suggestion, то он выдается в конце предупреждающего сообщения; например, он может быть советом о том, что нужно использовать вместо this-macro-name.

8. Ручная настройка

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

8.1 Указание типа системы
8.2 Получение канонического типа системы
8.3 Переменные типов систем
8.4 Использование типов систем

8.1 Указание типа системы

Подобно другим скриптам GNU configure, созданные Autoconf скрипты configure могут делать заключение основываясь на каноническом имени типа системы, которое имеет форму:

cpu-company-system

configure обычно может определить каноническое имя типа системы на которой он запущен. Для этого он запускает скрипт с именем config.guess, который определяет имя, используя команду uname или символы определенные препроцессором C.

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

--build=build-type

тип системы на которой настраивается и компилируется пакет (используется редко);

--host=host-type

тип системы на которой будет запускаться пакет;

--target=target-type

тип системы для которой утилиты компилятора будут создавать код.

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

CC=m68k-coff-gcc configure --target=m68k-coff

configure распознает короткие алиасы для многих типов систем; например, в командной строке может быть задано имя `decstation' вместо `mips-dec-ultrix4.2'. configure запускает скрипт с именем config.sub для канонизации алиасов типов систем.

8.2 Получение канонического типа системы

Следующие макросы делают тип системы доступным для скриптов configure. Они запускают скрипт командного процессора config.guess для определения значений для каждого из типов систем, в которых они нуждаются, и которые пользователь не указал в командной строке. Они запускают config.sub для канонизации заданных пользователем псевдонимов. Если вы используете эти макросы, то вы должны распространять эти два файла вместе с вашим исходным кодом. See section 3.2 Создание выходных файлов, для получения информации о макросе AC_CONFIG_AUX_DIR, который вы можете использовать для контроля того, в каком именно каталоге configure будет искать эти файлы. Если вы не используете ни один из этих макросов, то configure игнорирует заданные ключи `--host', `--target' и `--build'.

Macro: AC_CANONICAL_SYSTEM

Определяет тип системы и устанавливает выходные переменные равными именам канонических типов систем. See section 8.3 Переменные типов систем, где описано, какие именно переменные устанавливаются этим макросом.

Macro: AC_CANONICAL_HOST

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

Macro: AC_VALIDATE_CACHED_SYSTEM_TUPLE (cmd)

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

8.3 Переменные типов систем

После вызова AC_CANONICAL_SYSTEM информация о типе системы содержится в нижеперечисленных выходных переменных. После AC_CANONICAL_HOST устанавливаются только те из перечисленных переменных, чьи имена начинаются на host.

build, host, target

канонические имена систем;

build_alias, host_alias, target_alias

имена, указанные пользователем или канонические имена, если был использован файл config.guess;

build_cpu, build_vendor, build_os

host_cpu, host_vendor, host_os

target_cpu, target_vendor, target_os

отдельные части канонического имени (для удобства).

8.4 Использование типов систем

Как использовать канонический тип системы? Обычно вы используете его в одном или нескольких операторах case в `configure.in' для выбора специфических для системы файлов C. Затем делает ссылки на файлы, чьи имена содержат информацию о системе, чтобы они назывались также своим обобщенным именем, например, `host.h' или `target.c'. Шаблоны в операторе case могут использовать специальные символы командного процессора для группировки нескольких вариантов вместе, например как в таком фрагменте: