Перевод статьи «Using Automake and Autoconf with C++», написанной Marry Cumming, оригинал которой можно найти по этой ссылке. Эта статья дает краткое представление о том как можно с помощью утилит автоматической конфигурации automake и autoconf достаточно легко собирать проекты написанный на С/С++ и сопровождать их под управлением Unix-подобной системы, отвечающей требованиям GNU.

Однако, для начального освоения – это весьма затруднительно. Будем наедятся, что это небольшой учебник обеспечит достаточной информацией программистов С/С++, кто только начал создавать свои проекты в Unix-подобных системах, имеют достаточно поверхностное понимание как в средствах разработки так и в различных системных утилитах.

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

Скрипт configure может быть использован для обеспечения поддержки кросс-платформенной компиляции. Применяемый скрипт configure должен интерпретировать Makefile.in, а затем создавать платформа-ориентированный Makefile . Этот будет сделано после выполнения нескольких тестов, которые определят характеристики этой платформы.

Пользователю необходимо набрать в консоли './configure', а затем 'make' для компиляции проекта на используемой им платформе.

Очевидно, что весьма хорошо написанные Make -файлы и скрипт configure будут выглядит очень похожими. Фактически, проект GNU представляет руководство о том, что должно быть в этих файлах. Следовательно, проект GNU создал утилиты automake и autoconf для упрощения процесса и позаботился, чтобы Make-файлы и скрипт configure соответствовали его стандартам.

Здесь кратко объясняется о том как эти утилиты используются. Вы можете посмотреть примеры использования этих файлов в секции «Файлы примеров».

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

Утилита autoconf просматривает файл называемый configure.ac ( или, предворительно, configure.in). Затем он создает скрипт configure, основанный на макросах, которые найдет эта утилита.

Всякий раз, когда вы добавляете макрос в configure.ac, вы обязаны выполнить aclocal так же как autoconf, потому что aclocal сканирует configure.ac для того, чтобы найти какие макросы он должен предоставить.

Строчки, которые должен иметь каждый configure.ac:

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

Макрос AM_INIT_AUTOMAKE осуществляет некоторые стандартные проверки. Он принимает первым аргументом название программы, а вторым – номер ее версии.

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

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

Макрос AC_PROG_INSTALL генерирует цель 'install' так что пользователи смогут воспользоваться 'make install' для того чтобы инсталлировать собираемое программное обеспечение.

Макрос AC_OUTPUT указывает имя Make-файла, которое будет сгенерировано.

Макрос AM_CONFIG_HEADER(config.h) указывает, что вы будете использовать файл config.h. Тогда autoconf нужен файл config.h.in, который он обработает для создания config.h. Для обеспечения людей способом изготавливать кросс-платформенные приложения, он будет подключаться по всему исходному коду(#include«config.h») с помощью директивы #define будут определяться опции конфигурации. Файл config.h.in может быть сгенерирован с помощью утилиты autoheader.

Однако, вам понадобится создать пустой файл stamp-h для того, чтобы automake ре-генерировал config.h из config.h.in. Для чего, в командной строке наберите команду:

Эта утилита просматривает файл называемый Makefile.am. Затем она создаст Makefile.in, на основании макросов которые она найдет в просматриваемом файле. Это позже будет использоваться скриптом 'configure'(см. выше).

Следует ли использовать стиль GNU или нет?

По умолчанию утилита automake попытает создать проект в стиле GNU. Она будет добавит файл COPYING и посетует, если какие-нибудь необходимые информационные файлы будут отсутствовать. Чтобы избежать этого, вам нужно добавить следующие файлы в консоле:

[arjavskov@engin hello]$ touch NEWS README AUTHORS ChangeLog

Если Вы нехотите использовать стиль GNU, тогда вы может добавить в свой файл Makefile.am добавить следующий макрос:

Спасибо Marc van Woerkom за этот совет.

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

Помните, что имя второй переменной претворяется значением первой. Это общая практика для autoconf и automake.

Принимая во-внимание,что вы уже могли создать файлы Makefile.am и configure.ac(по только что приведенным примерам), вы способны уже собрать ваш проект путем через выполнения последоствательности команд:

• 'autoheader' – создает config.h.in
• 'touch NEWS README AUTHORS ChangeLog'
• 'touch stamp-h'
• aclocal - Добавляет файл aclocal.m4 и определяет m4 macros, используемые автоматическими утилитам.
• 'autoconf '- создает configure из configure.ac
• 'automake' – создает Makefile.in из Makefile.am
• './configure' – создает Makefile из Makefile.in >
• 'make'

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

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

Когда используются директории вам необходимо сделать следующее:

1. Определить переменную SUBDIRS в файле Makefile.am, который находится в корне проекта. Например, определяем директории: doc, intl, po, src, tests.SUBDIRS = doc intl po src testsПомните, что директории разделяются друг от друга пробелом. Поэтому, старайтесь не использовать их в самих именах директорий.
2. Добавьте в каждую поддиректорию, определённой переменной SUBDIRS, файл Makefile.am. А вот добавлять в них файл configure.ac не нужно. Вместо этого, лучше позаботитесь добавить эти Make-файлы в список AC_OUPUT, который находится в корневой директории.

3. Добавьте макрос AC_PROG_RANLIB в ваш файл configure.ac. Это позволит вам собирать исходный код во-временных библиотеках, которые make затем будет компоновать вместе с оставшимся кодом.
4. Добавьте макросы в Makefile.am любой поддиректории внутри src. В них будет собираться статическая библиотека. Для чего вам нужно дать этой библиотеки название начинающееся на 'lib', указав местоположение файлов заголовочные и исходного кода. Для примера:
   
noinst_LIBRARIES = libfoo.a
libfoo_a_SOURCES = foo.h foo.cc
INCLUDES = -I@top_srcdir@/src/includes

   Помните, что макрос SOURCES использует в имени библиотеки вместо точек ('.') символ подчеркивания('_'). Так же запомните, что нужно использовать значение top_srcdir для ссылки на корень проекта.
5. Используйте LDADD_ макрос в файле Makefile.am директории выше для компоновки временной библиотеки с любым кодом, который её использует. Для примера:
LDADD = foofiles/libfoo.a


3. Make-файл в поддиректории должен содержать строчку похожу на эту:
   
   EXTRA_DIST = somefile.txt someotherfile.html
   
   Тем самым говорится automake, что вы хотите эти файлы отделить, но что они нужны вам во-время компиляции.

Здесь представлены примеры файлов configure.ac и Makefile.am. Они успешно управляют C++ проектом, который использует Стандартную библиотеку.

Читайте руководство,http://www.gnu.org/manual/manual.html, по automake и autoconf для получения информации по именам макросов и переменных используемых в этих файлах. Не хочется делать комментарии для каждой строчки в этих файлах во-избежания трудности понимания.

Примеры даны для 'Deep' проекта с следующей структурой: