Но окончательный файл config.h не содержит следующее определение [...] config.h.in генерируется динамически и тоже не содержит определения.
Последнее на самом деле является ключевым вопросом. Когда вы используете AC_CONFIG_HEADERS, чтобы запросить, чтобы определения записывались в файл заголовка, а не выражались через параметры командной строки компилятора, Autoconf обрабатывает его, обрабатывая один или несколько шаблонов заголовка, таких как config.h.in, для получения получающегося заголовка ( с). Однако команда autoconf сама не создает эти шаблоны. Вы можете написать их вручную, если вы используете sh, но для выполнения этой работы доступна отдельная программа autoheader, и autoreconf (не autoconf) автоматически запускает autoheader для создания шаблона для первый заголовок, названный в первом вызове AC_CONFIG_HEADERS.
Поведение, которое вы описываете, является давно известной проблемой (без учета ошибки, per se ), которую вы можете найти обсуждаемой в архиве списка рассылки bug-autoconf . Решение было изменением документации, результат которого вы все еще можете увидеть в разделе руководства Autoconf, в котором обсуждается Autoheader :
Чтобы выполнить свою работу, необходимо autoheader вам задокументировать все символы, которые вы могли бы использовать. Обычно это делается с помощью AC_DEFINE или AC_DEFINE_UNQUOTED вызова , первый аргумент которого является буквальным символом , а третий аргумент описывает символ (см. Определение символов).
( Акцент добавлен.)
Это действительно, кажется, технически подходящее место для этих деталей. Таким образом, AC_DEFINE_UNQUOTED ведет себя так, как объявлено, что можно увидеть, отключив AC_CONFIG_HEADERS (жизнеспособный обходной путь при многих обстоятельствах), или используя одну из альтернатив, на которую указывает документ go:
Вы можете использовать AH_TEMPLATE (см. Макросы Autoheader), или вы можете предоставить подходящий входной файл для последующего файла заголовка конфигурации. Символы, определенные встроенными тестами Autoconf, уже задокументированы должным образом; вам нужно задокументировать только те, которые вы определяете сами.
Если бы вы утверждали, что было бы неплохо упомянуть и этот вопрос в документах AC_DEFINE_UNQUOTED, я бы полностью согласен с тобой. Но я также думаю, что сейчас ситуация значительно отличается от того, когда впервые было введено изменение do c из-за введения и повышения распространенности autoreconf, что скрывает участие autoheader от большинства пользователей. .
В любом случае, я проигнорирую опцию «поставь свой собственный шаблон», что немного чревато, и сосредоточусь на AH_TEMPLATE. Чтобы использовать его для поддержки конкретного случая, представленного в вопросе, можно добавить что-то вроде этого к configure.ac:
AH_TEMPLATE([USE_test], [Define to 1 to use test])
Возможно, вы спросите: «В чем тогда смысл? Я мог бы также использовать обычный AC_DEFINE «. Это хороший вопрос, который вы должны внимательно рассмотреть. Обратите внимание, что нет смысла определять произвольные макросы препроцессора, так как будут расширяться только те, которые соответствуют символам, появляющимся в одном или нескольких ваших источниках. Это не обязательно делает бесполезной генерацию имени макроса configure, но это означает, что при ведении configure.ac вы можете и должны иметь полный список всех сгенерированных имен макросов, которые необходимо поддерживать. В этом случае, вполне вероятно, что вы могли бы написать соответствующие AH_TEMPLATE вызовы для всех необходимых случаев. Тем не менее, в большинстве случаев лучше выбрать прямой (условный) AC_DEFINE s для каждого символа.