Наши партнеры








Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

На главную -> MyLDP -> Электронные книги по ОС Linux
Цилюрик О.И. Linux-инструменты для Windows-программистов
Назад Установка программного обеспечения Вперед

Создание своего конфигурируемого пакета

При некоторых навыках и сообразительности, выполнять сборку и установку, как показано выше, обычно не составляет труда (возможно, на каждом шаге анализируя сообщения об ошибках и подправляя параметры). Гораздо больше изобретательности требуется чтобы сделать свой оригинальный проект в такой же степени конфигурируемым под разные варианты операционной системы. Рассматриваем, как наиболее употребимый, инструментарий Autoconfig : очень упрощённо и по шагам проделаем конфигурирование над ранее рассмотренным проектом сборки со статической библиотекой (архив libraries.tgz) программы hello (теперь это архив Autoconf.tgz):

$ ls

hello_child.c  hello_child.h  hello_main.c  Makefile.0

Здесь файл сценария сборки Makefile, использовавшийся при отработке целевого проекта переименован в Makefile.0, потому как в результате конфигурирования будет создаваться новый Makefile.

Прежде всего, нам предстоит составить файл configure.in, содержащий макросы для тестов проверок в новой операционной системе. Но мы не станем делать это сами, а воспользуемся утилитой autoscan, которая создаст нам configure.scan как прототип будущего configure.in:

$ autoscan

$ ls

autoscan.log configure.scan  hello_child.c  hello_child.h  hello_main.c Makefile.0

$ cat configure.scan

AC_PREREQ([2.63])
AC_INIT([FULL-PACKAGE-NAME], [VERSION], [BUG-REPORT-ADDRESS])
AC_CONFIG_SRCDIR([hello_child.h])
AC_CONFIG_HEADERS([config.h]) 
# Checks for programs.
AC_PROG_CC
# Checks for libraries.
# Checks for header files.
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
AC_CONFIG_FILES([Makefile])
AC_OUTPUT 

Это только прототип-шаблон, в который нам предстоит вписать много других макросов тестов зависимостей нашего пакета. Конечным действием этого шага должно стать:

$ cp configure.scan configure.in

$ ls

autoscan.log  configure.in  configure.scan  hello_child.c  hello_child.h  hello_main.c  Makefile.0

Далее создаём config.h.in, но опять же воспользуемся для этого генератором заготовки autoheader:

$ autoheader

$ ls

autom4te.cache  autoscan.log  config.h.in  configure.in  configure.scan  hello_child.c
hello_child.h  hello_main.c  Makefile.0

$ cat config.h.in
/* config.h.in.  Generated from configure.in by autoheader.  */
/* Define to the address where bug reports for this package should be sent. */
#undef PACKAGE_BUGREPORT
/* Define to the full name of this package. */
#undef PACKAGE_NAME
...

Здесь нет ничего интересного, потому как предполагается, что вы станете сознательно править config.h.in, наполняя его этим интересным содержанием...

И далее — ключевое действие:

$ autoconf
 $ ls
 autom4te.cache  autoscan.log  config.h.in  configure  configure.in  configure.scan  hello_child.c
hello_child.h  hello_main.c  Makefile 

- создан файл configure, это скрипт с установленными флагами выполнимости!

Цель выполнения configure — создание из макета сценария сборки Makefile.in текущего сценария Makefile под конкретно сконфигурированное окружение операционной системы. Для этого предварительно скопируем этот файл макета из сценария сборки, который мы используем при отладке пакета:

$ cp Makefile Makefile.in

И выполняем лёгкое редактирование Makefile.in — выделяем в нём конфигурируемые параметры, в данном примере такой параметр один:

$ cat Makefile.in

...
LIB = lib$(TARGET)
CC = @CC@
all: $(LIB) $(TARGET)
$(LIB):  $(CHILD).c $(CHILD).h
          $(CC)  -c $(CHILD).c -o $(CHILD).o
...

Фактически, это практически тот же Makefile, который мы использовали при компиляции проекта, за одним принципиальным исключением: переменной @CC@. Значения переменным вида @XXXX@ будет присваиваться при выполнении скрипт configure, исходя из анализа тестов, которые скрипт проводит над операционной системой.

Всё! Мы можем проверять выполнение созданного конфигурационного скрипта:

$ ./configure

checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h

Конечным действием скрипта является создание нового Makefile, который мы тут же проверяем:

$ make

cc -c hello_child.c -o hello_child.o
ar -q libhello.a hello_child.o
ar: creating libhello.a
ar -t libhello.a
hello_child.o
cc hello_main.c -Bstatic -L./ -lhello -o hello

- это в точности то, что выполнял ранее созданный вручную сценарий Makefile.0.

Примечание: Основным содержательным действием, определяющим успех всего начинания, является наполнение файла configure.in (обсуждался выше) макросами тестирования возможностей операционной системы. Созданный файл начинается с макроса AC_INIT и завершается макросом AC_OUTPUT (как показано ранее в примере), между которыми можно вписывать свои собственные тесты-проверки, для очень многих требуемых случаем уже существуют предопределённые макросы. Примеры только некоторых таких макросов тестирования (для оценки разнообразия возможностей):

  • AC_TRY_CPP() используется для проверки существования конкретных заголовочных файлов (указаны параметрами).
  • AC_TRY_COMPILE() - который пытается откомпилировать небольшую вами представленную (в качестве его параметра) программу, которая проверяет возможность использования заданной синтакчсической конструкции текущим компилятором; также может использоваться для проверки структур и полей структур, которые присутствуют не во всех системах.
  • AC_TRY_LINK_FUNC() - для проверки библиотеки, функции или глобальной переменной скрипт configure попытается скомпилировать и скомпоновать небольшую программу, которая использует тестируемые возможности: создается тестовая программа для того, чтобы убедиться, что программа, чье тело состоит их прототипа и вызова указанной функции (параметр макроса), может быть скомпилирована и скомпонована.
  • AC_TRY_RUN() - тестирует поведение (отсутствие ошибок) периода выполнения указанной программы (параметр макроса).

Детальное описание всех возможных макросов смотрите в описаниях Autoconf.


Предыдущий раздел: Оглавление Следующий раздел:
Autoconf / Automake   Cmake