Стандарт кодирования GNU. : Как должно выполняться конфигурирование.

Вперед Назад Содержание

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

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

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

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

Идея другого способа состоит в том, что скрипт configure может выполнить редактировании Make-файла. Если Вы поступаете таким образом, то Ваша поставка не должна включать файл с именем 'Makefile'. Вместо него должен присутствовать файл 'Makefile.in', который содержит заготовку для редактирования. Опять же, это нужно для того, чтобы пользователи не имели возможность выполнить компиляцию до конфигурирования.

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

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

Скрипт configure должен формировать файл с именем 'config.status', описывающий конфигурацию, которая была установлена во время последнего конфигурирования. Этот файл должен быть скриптом shell, восстанавливающим в случае запуска эту самую конфигурацию.

Скрипт configure должен воспринимать параметр вида '--srcdir=dirname', для указания каталога, в котором должны находиться исходные файлы (если этот каталог не является текущим. Это дает возможность строить программу в отдельном каталоге, не модифицируя при этом содержимое каталога с исходными файлами.

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

Обычно простейший способ поддержать опцию '--srcdir' состоит в редактировании определения переменной VPATH в Make-файле. В некоторых правилах должны, тем не менее, присутствовать явные ссылки на указанный каталог. Чтобы сделать это возможным, configure может добавить в Make-файл переменную с именем srcdir, чье значение полностью определяет имя каталога.

Скрипт configure должен также уметь воспринимать аргумент, который определяет тип системы, для которой выполняется построение программы. Этот аргумент должен выглядеть так:

cpu-company-system   
Например, тип Sun 3 может быть таким: 'm68k-sun-sunos4.1'.

Скрипт configure должен уметь разбирать все в принципе возможные варианты описания машин. Так, 'sun3-sunos4.1' будет вполне допустимым синонимом, точно так же, как и 'sun3-bsd4.2', поскольку Sun OS в основе своей является BSD-системой, и нет других BSD-систем, доступных на Sun. Для многих программ, 'vax-dec-ultrix' должен быть синонимом лдя 'vax-dec-bsd', просто потому что различия между Unix и BSD редко когда существенны, но некоторые программы все-же должны различать их.

Имеется скрипт 'config.sub', который может быть использован как подпрограмма для проверки заданного типа системы и канонизации возможных синонимов.

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

'--enable-feature[=parameter]'

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

'--with-package'

Скрипт configure настраивает Ваш пакет с тем, чтобы он использовал некоторый другой предустановленный пакет. Возможные значения package: 'x', 'x-toolkit', 'gnu-as' (или 'gas'), 'gnu-ld, 'gnu-libc', 'gdb'. Не надо использовать опцию --with для указания имен \ файлов.

'--nfp'

Целевая машина не имеет процессора для выполнения операций с плавающей точкой.

'--gas'

В качестве ассемблера целевой машины должен использоваться gas ­ GNU ассемблер. Эта опция устарела: пользователи должны использовать опцию '--with-gnu-as' вместо данной.

'--x'

На целевой машине имеется установленная система X Window. Эта опция устарела; пользователи должны использовать опцию '--with-x' вместо данной.

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

Вы можете заметить, что категории '--with-' и '--enable-' являются конкретными: они предоставляют место для любого типа опций, которые Вам могут понадобиться. Так и задумано. Мы хотим ограничить возможные опции, используемые при конфигурировании GNU-программ. Мы не хотим, чтобы GNU-программы имели раздражающие наборы опций конфигурирования.

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

Способ построения кросс-компилятора, кросс-ассемблера и т.д. состоит в указании опции '--host=hosttype' при запуске configure. Это позволяет указать тип хост-системы без изменения типа целевой системы. Синтаксис для hosttype был приведен выше.

Перенос кросс-компилятора требует компиляции его на машине, отличной от той, на которой он будет выполняться. Пакеты-компиляторы должны воспринимать опцию конфигурации '--build=hosttype' для указания типа машины, на которой Вы будете компилировать пакет, если этот тип отличен от указанного в '--host'.

Программы, для которых кросс-операции не имеют смысла, не должны воспринимать опцию '--host'.

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


Вперед Назад Содержание