Переменные для каталогов установки

Каталоги установки всегда должны именоваться переменными, чтобы было легко установить их в нестандартном месте. Стандартные имена для этих переменных и значения, которые они должны иметь в пакетах GNU, описаны ниже. Они основаны на стандартной структуре файловой системы; её варианты используются в GNU/Linux и других современных операционных системах.

Инсталляторы должны переопределять эти значения при вызове make (например, make prefix=/usr install) или configure (например, configure --prefix=/usr). Пакеты GNU не должны пытаться угадать, какое значение должно быть подходящим для этих переменных на системе, на которую они устанавливаются: используйте значения по умолчанию, указанные здесь, чтобы все пакеты GNU вели себя одинаково, позволяя инсталлятору достичь любой желаемой структуры.

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

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

prefix

Префикс, используемый при построении значений по умолчанию переменных, перечисленных ниже. Значение по умолчанию для prefix должно быть /usr/local. При построении полной системы GNU префикс будет пустым, а /usr будет символической ссылкой на /. (Если вы используете Autoconf, запишите как ‘@prefix@’.)

Запуск ‘make install’ с другим значением prefix по сравнению со значением, используемым при построении программы, не должен перекомпилировать программу.

exec_prefix

Префикс, используемый при построении значений по умолчанию некоторых переменных, перечисленных ниже. Значение по умолчанию для exec_prefix должно быть $(prefix). (Если вы используете Autoconf, запишите как ‘@exec_prefix@’.)

Как правило, $(exec_prefix) используется для каталогов, содержащих машинно-специфичные файлы (такие как исполняемые файлы и библиотеки подпрограмм), в то время как $(prefix) используется непосредственно для других каталогов.

Запуск ‘make install’ с другим значением exec_prefix по сравнению со значением, используемым при построении программы, не должен перекомпилировать программу.

Исполняемые программы устанавливаются в одном из следующих каталогов.

bindir

Каталог для установки исполняемых программ, которые могут запускаться пользователями. Обычно это /usr/local/bin, но запишите как $(exec_prefix)/bin. (Если вы используете Autoconf, запишите как ‘@bindir@’.)

sbindir

Каталог для установки исполняемых программ, которые могут запускаться из оболочки, но обычно полезны только системным администраторам. Обычно это /usr/local/sbin, но запишите как $(exec_prefix)/sbin. (Если вы используете Autoconf, запишите как ‘@sbindir@’.)

libexecdir

Каталог для установки исполняемых программ, которые запускаются другими программами, а не пользователями. Этот каталог обычно должен быть /usr/local/libexec, но запишите как $(exec_prefix)/libexec. (Если вы используете Autoconf, запишите как ‘@libexecdir@’.)

Определение ‘libexecdir’ одинаково для всех пакетов, поэтому вы должны устанавливать свои данные в подкаталоге. Большинство пакетов устанавливают свои данные в $(libexecdir)/package-name/, возможно, внутри дополнительных подкаталогов, таких как $(libexecdir)/package-name/machine/version.

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

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

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

Ниже перечислены переменные, которые Makefiles должны использовать для указания каталогов для размещения различных типов файлов:

‘datarootdir’

Корень дерева каталогов для файлов данных, независимых от архитектуры и предназначенных для чтения. Обычно это /usr/local/share, но запишите как $(prefix)/share. (Если вы используете Autoconf, запишите как ‘@datarootdir@’.) Значение по умолчанию для ‘datadir’ основано на этой переменной; также и для ‘infodir’, ‘mandir’ и других.

‘datadir’

Каталог для установки специфичных для программы файлов данных, независимых от архитектуры и предназначенных для чтения. Часто совпадает с местом расположения ‘datarootdir’, но мы используем две отдельные переменные, чтобы вы могли перемещать эти файлы, специфичные для программы, не изменяя расположение файлов Info, man-страниц и т. д.

Обычно это /usr/local/share, но запишите как $(datarootdir). (Если вы используете Autoconf, запишите как ‘@datadir@’.)

Определение ‘datadir’ одинаково для всех пакетов, поэтому вы должны устанавливать свои данные в подкаталоге. Большинство пакетов устанавливают свои данные в $(datadir)/package-name/.

‘sysconfdir’

Каталог для установки файлов данных, предназначенных для одной конкретной машины (то есть файлы для настройки хоста). Файлы конфигурации почтового клиента и сети, /etc/passwd и т. д. должны быть здесь. Все файлы в этом каталоге должны быть обычными текстовыми ASCII-файлами. Обычно этот каталог — /usr/local/etc, но запишите как $(prefix)/etc. (Если вы используете Autoconf, запишите как ‘@sysconfdir@’.)

Не устанавливайте исполняемые файлы в этом каталоге (они, вероятно, должны быть в $(libexecdir) или $(sbindir)). Также не устанавливайте файлы, которые изменяются в обычном процессе их использования (программы, предназначенные для изменения конфигурации системы, исключены). Они, вероятно, должны быть в $(localstatedir).

‘sharedstatedir’

Каталог для установки файлов данных, независимых от архитектуры, которые программы изменяют во время выполнения. Обычно это /usr/local/com, но запишите как $(prefix)/com. (Если вы используете Autoconf, запишите как ‘@sharedstatedir@’.)

‘localstatedir’

Каталог для установки файлов данных, которые программы изменяют во время выполнения и которые относятся к одной конкретной машине. Пользователи никогда не должны изменять файлы в этом каталоге для настройки работы пакета; поместите такую информацию о конфигурации в отдельные файлы, которые находятся в $(datadir) или $(sysconfdir). $(localstatedir) обычно равен /usr/local/var, но запишите как $(prefix)/var. (Если вы используете Autoconf, запишите как ‘@localstatedir@’.)

‘runstatedir’

Каталог для установки файлов данных, которые программы изменяют во время выполнения, относятся к одной конкретной машине и не должны сохраняться дольше, чем выполнение программы — которая обычно долговечна, например, до следующей перезагрузки. Файлы PID для системных демонов — типичное использование. Кроме того, этот каталог не должен очищаться, за исключением, возможно, при перезагрузке, в то время как общий /tmp (TMPDIR) может быть очищен произвольно. Обычно это /var/run, но запишите как $(localstatedir)/run. Наличие отдельной переменной позволяет использовать /run, если это необходимо, например. (Если вы используете Autoconf 2.70 или более позднюю версию, запишите как ‘@runstatedir@’.)

Эти переменные указывают каталог для установки определённых типов файлов, если ваша программа их использует. Каждый пакет GNU должен иметь файлы Info, поэтому каждой программе нужен ‘infodir’, но не всем нужна ‘libdir’ или ‘lispdir’.

‘includedir’

Директория для установки заголовочных файлов, которые должны включаться пользовательскими программами с помощью препроцессорной директивы C ‘#include’. Обычно это /usr/local/include, но запишите как $(prefix)/include. (Если вы используете Autoconf, запишите как ‘@includedir@’.)

Большинство компиляторов, кроме GCC, не ищут заголовочные файлы в директории /usr/local/include. Поэтому установка заголовочных файлов таким образом полезна только с GCC. Иногда это не проблема, потому что некоторые библиотеки предназначены только для работы с GCC. Но некоторые библиотеки предназначены для работы с другими компиляторами. Они должны устанавливать свои заголовочные файлы в два места, одно из которых указано в includedir, а другое — в oldincludedir.

‘oldincludedir’

Директория для установки заголовочных файлов ‘#include’ для использования с компиляторами, отличными от GCC. Обычно это /usr/include. (Если вы используете Autoconf, можете записать как ‘@oldincludedir@’.)

Команды Makefile должны проверить, пустое ли значение oldincludedir. Если да, они не должны пытаться использовать его; они должны отменить вторую установку заголовочных файлов.

Пакет не должен заменять существующий заголовок в этой директории, если этот заголовок не из того же пакета. Таким образом, если ваш пакет Foo предоставляет заголовочный файл foo.h, он должен установить заголовочный файл в директорию oldincludedir, если (1) там нет foo.h или (2) существующий foo.h пришёл из пакета Foo.

Чтобы определить, пришёл ли foo.h из пакета Foo, поместите магическую строку в файл — часть комментария — и grep для этой строки.

‘docdir’

Директория для установки файлов документации (кроме Info) для этого пакета. По умолчанию это должно быть /usr/local/share/doc/yourpkg, но следует записать как $(datarootdir)/doc/yourpkg. (Если вы используете Autoconf, запишите как ‘@docdir@’.) Поддиректория yourpkg, которая может включать номер версии, предотвращает столкновения среди файлов с общими именами, такими как README.

‘infodir’

Директория для установки файлов Info для этого пакета. По умолчанию это должно быть /usr/local/share/info, но следует записать как $(datarootdir)/info. (Если вы используете Autoconf, запишите как ‘@infodir@’.) infodir отделено от docdir для совместимости с существующей практикой.

‘htmldir’

‘dvidir’

‘pdfdir’

‘psdir’

Директории для установки файлов документации в определённом формате. По умолчанию все они должны быть установлены в $(docdir). (Если вы используете Autoconf, запишите их как ‘@htmldir@’, ‘@dvidir@’ и т. д.) Пакеты, которые предоставляют несколько переводов своей документации, должны устанавливать их в ‘$(htmldir)/’ll, ‘$(pdfdir)/’ll и т. д., где ll — аббревиатура языка, например ‘en’ или ‘pt_BR’.

‘libdir’

Директория для объектных файлов и библиотек объектного кода. Не устанавливайте исполняемые файлы здесь; они, вероятно, должны быть в $(libexecdir). Значение libdir обычно должно быть /usr/local/lib, но запишите его как $(exec_prefix)/lib. (Если вы используете Autoconf, запишите как ‘@libdir@’.)

‘lispdir’

Директория для установки файлов Emacs Lisp в этом пакете. По умолчанию это /usr/local/share/emacs/site-lisp, но следует записать как $(datarootdir)/emacs/site-lisp.

Если вы используете Autoconf, запишите значение по умолчанию как ‘@lispdir@’. Для работы ‘@lispdir@’ вам нужны следующие строки в файле configure.ac:

lispdir='${datarootdir}/emacs/site-lisp'
AC_SUBST(lispdir)

‘localedir’

Директория для установки языковых каталогов сообщений для этого пакета. По умолчанию это /usr/local/share/locale, но следует записать как $(datarootdir)/locale. (Если вы используете Autoconf, запишите как ‘@localedir@’.) Эта директория обычно содержит поддиректории для каждого языка.

Документация в формате Unix-style man устанавливается в одной из следующих директорий:

‘mandir’

Основная директория для установки страниц man (если таковые имеются) для этого пакета. Обычно это /usr/local/share/man, но вы должны записать её как $(datarootdir)/man. (Если вы используете Autoconf, запишите как ‘@mandir@’.)

‘man1dir’

Директория для установки страниц man 1. Запишите как $(mandir)/man1.

‘man2dir’

Директория для установки страниц man 2. Запишите как $(mandir)/man2

‘…’

Не делайте основную документацию для какого-либо ПО GNU страницами man. Вместо этого пишите руководство в Texinfo. Страницы man предназначены только для тех, кто использует ПО GNU на Unix, что является вторичным применением.

‘manext’

Расширение имени файла для установленной страницы man. Оно должно содержать точку, за которой следует соответствующая цифра; обычно это ‘.1’.

‘man1ext’

Расширение имени файла для установленных страниц man 1.

‘man2ext’

Расширение имени файла для установленных страниц man 2.

‘…’

Используйте эти имена вместо ‘manext’, если пакет должен устанавливать страницы man в нескольких разделах руководства.

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

‘srcdir’

Директория исходных кодов, которые компилируются. Значение этой переменной обычно вставляется скриптом оболочки configure. (Если вы используете Autoconf, используйте ‘srcdir = @srcdir@’.)

Например:

# Common prefix for installation directories.
# NOTE: This directory must exist when you start the install.
prefix = /usr/local
datarootdir = $(prefix)/share
datadir = $(datarootdir)
exec_prefix = $(prefix)
# Where to put the executable for the command 'gcc'.
bindir = $(exec_prefix)/bin
# Where to put the directories used by the compiler.
libexecdir = $(exec_prefix)/libexec
# Where to put the Info files.
infodir = $(datarootdir)/info

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

Не ожидайте, что пользователь будет включать имя поддиректории в значение какой-либо из переменных, перечисленных выше. Идея наличия единого набора имён переменных для директорий установки заключается в том, чтобы пользователю можно было указать одни и те же значения для нескольких разных пакетов GNU. Для того, чтобы это было полезно, все пакеты должны быть разработаны таким образом, чтобы они работали осмысленно, когда пользователь это делает.

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