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

Хорошо составленный pkg-descr описывает порт достаточно полно, чтобы пользователю не приходилось сверяться с документацией или посещать вебсайт для понимания того, что делает данное программное обеспечение, чем оно может быть полезно или какие хорошие функции у него имеются. Упоминание про определённые требования, такие как используемый графический инструментарий, тяжёлые зависимости, окружение для запуска или используемый язык программирования помогут пользователям определиться, будет ли этот порт для них работать.

Включите сюда URL официальной домашней страницы Интернет. Перед одним из сайтов (выберите основной) добавьте WWW: (с последующим единичным пробелом) для того, чтобы вспомогательные утилиты работали правильно. Если URI является корнем сайта или каталогом, то значение должно быть дополнено косой чертой.

Следующий пример показывает, как должен выглядеть ваш pkg-descr:

This is a port of oneko, in which a cat chases a poor mouse all over
the screen.
 :
(etc.)

WWW: http://www.oneko.org/

Здесь перечисляются все файлы, устанавливаемые портом. Его также называют «списком для упаковки», потому что пакет генерируется упаковкой файлов, которые здесь указаны. Имена путей указываются относительно установочного префикса (обычно /usr/local). Если вы используете переменные MANn (а вы должны это делать), то указывать страницы справочника здесь не нужно. Если порт во время установки создает каталоги, убедитесь, что добавили строку @dirrm для удаления каталогов при удалении пакета.

Вот маленький пример:

bin/oneko
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm
@dirrm lib/X11/oneko

Обратитесь к странице справочной системы по команде pkg_create(1) с подробным описанием формата списка упаковки.

Существует только одно исключение, когда у порта может отсутствовать pkg-plist. Если порт устанавливает лишь несколько файлов, а возможно, и каталогов, то они могут быть перечислены в переменных PLIST_FILES и PLIST_DIRS, соответственно, внутри файла Makefile порта. К примеру, мы можем обойтись без файла pkg-plist у приведённого выше порта oneko, добавив следующие строки в Makefile:

PLIST_FILES=    bin/oneko \
                lib/X11/app-defaults/Oneko \
                lib/X11/oneko/cat1.xpm \
                lib/X11/oneko/cat2.xpm \
                lib/X11/oneko/mouse.xpm
PLIST_DIRS=     lib/X11/oneko

Конечно, переменная PLIST_DIRS не должна задаваться, если порт не устанавливает никаких каталогов.

Обратной стороной такого способа перечисления файлов и каталогов порта является невозможность использования последовательностей команд, описанных в pkg_create(1). Поэтому он подходит для простых портов, что делает их ещё более простыми. Одновременно с этим положительным моментом является уменьшение количества файлов в коллекции портов. Пожалуйста, подумайте над использованием этой техники, прежде чем создавать pkg-plist.

Далее мы увидим, как можно использовать файлы pkg-plist и PLIST_FILES выполнения более сложных задач.

В переменной PORTNAME вы должны указать основную часть имени вашего порта, а в переменной PORTVERSION - номер версии.

Две необязательные переменные, PKGNAMEPREFIX и PKGNAMESUFFIX, объединяются со значениями PORTNAME и PORTVERSION для формирования PKGNAME в форме ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. Добейтесь того, чтобы это соответствовало нашим рекомендациям по правильному выбору названий для пакетов. В частности, в переменной PORTVERSION не разрешается использование дефиса (-). Кроме того, если в имени пакета присутствует часть language- или -compiled.specifics (смотрите ниже), то используйте переменные PKGNAMEPREFIX и PKGNAMESUFFIX, соответственно. Не делайте их частью значения переменной PORTNAME.

LATEST_LINK задает в процессе построения пакета короткое имя ссылки, которые могут использоваться при выполнении команды pkg_add -r. Это позволяет, к примеру, установить последнюю версию perl, используя pkg_add -r perl, без знания точного номера версии. Такое имя должно быть уникальным и очевидным для пользователей.

В некоторых случаях в коллекции портов может присутствовать несколько версий программы одновременно. Обе системы, построения индексов и построения пакетов, нуждаются в способности их видеть как разные, независимые порты, хотя все они могут иметь схожее значение для PORTNAME, PKGNAMEPREFIX и даже PKGNAMESUFFIX. В этих случаях для всех портов кроме «главного» следует присвоить различные значения для необязательной переменной LATEST_LINK — чтобы получить пример ее использования, смотрите порты lang/gcc46 и lang/gcc, а также семейство www/apache*. При установке NO_LATEST_LINK ссылки не создаются; эта необязательная переменная может быть указана во всех версиях, кроме «главной». Обратите внимание, как выбирать «главную» версию — «самую популярную», «самую поддерживаемую», «с наименьшими изменениями» и так далее — это выходит за рамки рекомендаций этого руководства; мы всего лишь сообщаем вам, как указывать версии других портов после того, как вы выбрали «главный».

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

Имя пакета должно иметь вид language_region-name-compiled.specifics-version.numbers.

Имя пакета определяется как ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. Вы должны задавать значения переменных в соответствии с этим форматом.

Вот несколько (реальных) примеров того, как преобразовать имя из оригинального, придуманного авторами, к подходящему для имени пакета:

Если в исходном коде абсолютно нет информации о номере версии и не похоже, что автор собирается выпускать другую версию, то в качестве номера версии задайте просто 1.0 (как в примере с piewm выше). В противном случае спросите автора программы или используйте дату (0.0.yyyy.mm.dd) в качестве номера версии.

В процессе создания пакета он помещается в каталог /usr/ports/packages/All, а в одном или более подкаталогов из /usr/ports/packages создаются на него ссылки. Имена этих подкаталогов определяются переменной CATEGORIES. Такая схема нужна для облегчения жизни пользователя, когда он сталкивается с массой пакетов на FTP-сервере или компакт-диске. Пожалуйста, посмотрите на текущий список категорий и выберите те из них, которые более всего подходят к вашему порту.

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

Вот текущий список категорий. Те, которые отмечены звёздочкой (*), являются виртуальными категориями—они не имеют собственного подкаталога в дереве портов. Они используются только в качестве вторичных категорий, и только для поиска.

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

Если вы не уверены в правильности выбора категории, пожалуйста, отметьте это в вашем сообщении через send-pr(1), чтобы мы могли обсудить это до того, как включить порт в Коллекцию. Если вы являетесь коммиттером, пошлите замечание на адрес Список рассылки, посвящённый Портам FreeBSD, чтобы мы могли обсудить это. Зачастую новые порты помещаются не в ту категорию только для того, чтобы их оттуда сразу же удалили. Это приводит к излишнему и ненужному росту основного хранилища исходных текстов.

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

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

Основной причиной для этого является то, что такое изменение создает изрядное количество работы и для коммиттеров, и для всех тех пользователей, которые отслеживают изменения в Коллекции Портов. В дополнение, предложенная категория создает естественное разногласие. (Пожалуй, потому что не существует четкого соглашения, является ли категория «слишком большой», или должны ли категории предоставлять себя для просмотра (и, таким образом, какое количество категорий было бы идеальным значением), и так далее.)

Процедура:

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

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

В переменной DISTNAME указывается имя порта так, как назвали его создатели программного обеспечения. Значение DISTNAME по умолчанию совпадает с ${PORTNAME}-${PORTVERSION}, так что переопределяете её значение только в случае необходимости. DISTNAME используется только в двух местах. Во-первых, список дистрибутивных файлов (DISTFILES) по умолчанию состоит из ${DISTNAME}${EXTRACT_SUFX}. И во-вторых, предполагается, что дистрибутивный файл будет распакован в подкаталог с именем WRKSRC, значение которого по умолчанию есть не что иное, как work/${DISTNAME}.

Названия некоторых дистрибутивов, которые не укладываются в ${PORTNAME}-${PORTVERSION}-схему, могут быть автоматически обработаны посредством установки переменной DISTVERSION. PORTVERSION и DISTNAME будут унаследованы автоматически, но конечно же могут быть переопределены. Следующая таблица демонстрирует некоторые примеры:

Содержит часть с каталогом FTP/HTTP-URL, которая указывает на оригинальный архив на сервере MASTER_SITES. Не забудьте лидирующий слэш (/)!

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

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

Если оригинальный архив находится на одном из таких популярных серверов, как SourceForge, GNU или Perl CPAN, то указывайте эти сайты в простой форме при помощи MASTER_SITE_* (к примеру, MASTER_SITE_SOURCEFORGE, MASTER_SITE_GNU или MASTER_SITE_PERL_CPAN. Просто укажите в переменной MASTER_SITES одно из этих значений, а в переменной MASTER_SITE_SUBDIR задайте путь к архиву. Вот пример:

MASTER_SITES=         ${MASTER_SITE_GNU}
MASTER_SITE_SUBDIR=   make

Или можно использовать сокращенный формат:

MASTER_SITES=	GNU/make

Эти переменные определены в файле /usr/ports/Mk/bsd.sites.mk. Всё время добавляются новые записи, так что обращайтесь к последней версии этого файла перед тем, как послать нам свой порт.

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

MASTER_SITES=   SF

Если попытка угадать не удалась, то это может быть переписано следующим образом.

MASTER_SITES=   SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION}

Что также можно записать в таком виде:

MASTER_SITES=	SF
MASTER_SITE_SUBDIR=	stardict/WyabdcRealPeopleTTS/${PORTVERSION}

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

К примеру, если дистрибутивный файл носит имя foo.tgz, а не более привычное foo.tar.gz, вы должны написать:

DISTNAME=      foo
EXTRACT_SUFX=  .tgz

Переменные USE_BZIP2, USE_XZ и USE_ZIP при необходимости автоматически устанавливают значение EXTRACT_SUFX в .tar.bz2, .tar.xz или .zip. Если ни одна из этих переменных не задана, то значение EXTRACT_SUFX по умолчанию устанавливается в .tar.gz.

Иногда имена сгружаемых файлов не соответствуют имени порта. К примеру, файл может называться source.tar.gz или подобным образом. В других случаях исходный код приложения может располагаться в нескольких отличающихся архивах, и все они должны быть сгружены.

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

DISTFILES=     source1.tar.gz source2.tar.gz

Если переменная DISTFILES не задана явно, то её значением по умолчанию будет ${DISTNAME}${EXTRACT_SUFX}.

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

DISTFILES=     source.tar.gz manual.html
EXTRACT_ONLY=  source.tar.gz

Если ни один из DISTFILES не должен распаковываться, то установите пустое значение переменной EXTRACT_ONLY.

EXTRACT_ONLY=

Если вашему порту требуются некоторых дополнительные патчи, которые доступны по FTP или HTTP, задайте имена этих файлов в переменной PATCHFILES, а в переменной PATCH_SITES укажите URL того каталога, в котором они содержатся (формат такой же, как для MASTER_SITES).

Если патч не относится к самому верху дерева исходных текстов (то есть WRKSRC), потому что он содержит некоторые дополнительные пути, установите соответственно значение переменной PATCH_DIST_STRIP. В частности, если все имена путей в патче имеют дополнительный путь foozolix-1.0/ перед именем файла, то задайте PATCH_DIST_STRIP=-p1.

Не волнуйтесь, если патчи упакованы; они будут распакованы автоматически, если имена файлов оканчиваются на .gz или .Z.

Если патч распространяется вместе с какими-то другими файлами, такими, как документация, в виде tar-архива gzip, вы не можете просто использовать PATCHFILES. Если это ваш случай, добавьте имя и местоположение архива с патчем к DISTFILES и MASTER_SITES. Затем воспользуйтесь переменной EXTRA_PATCHES для указания этих файлов, и bsd.port.mk автоматически применит эти патчи. В частности, не копируйте файлы с патчами в каталог PATCHDIR—этот каталог может быть недоступным для записи.

(Этот раздел можно считать немного «повышенной трудности»; те, кто впервые знакомятся с этим текстом, могут пропустить этот раздел).

В этом разделе находится информация о механизме сгрузки, известном как MASTER_SITES:n и MASTER_SITES_NN. Далее мы будем называть этот механизм MASTER_SITES:n.

Сначала немного общей информации. В OpenBSD имеется полезная возможность, используемая в переменных DISTFILES и PATCHFILES, которая позволяет закреплять после имен файлов и патчей идентификаторы типа :n. Здесь n может быть из диапазона [0-9] и обозначать закреплённую группу. К примеру:

DISTFILES=      alpha:0 beta:1

В OpenBSD дистрибутивный файл alpha будет связан с переменной MASTER_SITES0, но не с нашей общей переменной MASTER_SITES, а файл beta с переменной MASTER_SITES1.

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

Просто представьте себе 2 файла в DISTFILES и 20 сайтов в MASTER_SITES; сайты очень медленные, причём beta находится на всех сайтах из MASTER_SITES, а alpha может быть найден только на 20-м сайте. Будет неправильно проверять их все, если создатель знает об этом, не правда ли? Неподходящее начало для таких прекрасных выходных!

Теперь, когда вы получили общее представление, просто представьте ещё большее количество DISTFILES и MASTER_SITES. Конечно, наш «магистр доступности дистрибутивов» представляет масштабы нагрузки на сеть, которую это даёт.

В последующих разделах информация будет даваться вместе с реализацией этой идеи во FreeBSD. Мы несколько улучшили концепцию OpenBSD.

MASTER_SITES=   ftp://ftp.example1.com/:source1 \
                ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
                source2.tar.gz:source2

MASTER_SITES=   ftp://ftp.example1.com/:source1 \
                ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
                source2.tar.gz:source2 \
                source3.tar.gz:source2

Не позволяйте вашему порту засорять /usr/ports/distfiles. Если вашему порту требуется сгрузить много файлов, или он содержит имя файла, могущее вызвать конфликты с другими портами (например, Makefile), то укажите в переменной DIST_SUBDIR имя порта (должны подойти ${PORTNAME} или ${PKGNAMEPREFIX}${PORTNAME}). Это изменит значение переменной DISTDIR со значения по умолчанию /usr/ports/distfiles к значению /usr/ports/distfiles/DIST_SUBDIR, и в результате всё, что требуется для порта, будет помещено в этот подкаталог.

Он заглянет также в подкаталог с тем же именем на основном резервном сервере ftp.FreeBSD.org. (Явное задание переменной DISTDIR в вашем файле Makefile этого не сделает, так что, пожалуйста, воспользуйтесь DIST_SUBDIR.)

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

.if defined(PACKAGE_BUILDING)
DISTFILES+=             foo.tar.gz
ALWAYS_KEEP_DISTFILES=  yes
.endif

При добавлении дополнительных файлов в DISTFILES убедитесь, что вы их также добавляете в distinfo. Кроме того, дополнительные файлы обычно распаковываются также в WRKDIR, что для некоторых портов может вызывать нежелательные подобные эффекты и требовать особую обработку.

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

LIB_DEPENDS=   libjpeg.so:${PORTSDIR}/graphics/jpeg

проверит наличие библиотеки jpeg с любым номером версии и перейдет в подкаталог graphics/jpeg вашего дерева портов для ее построения и установки, если библиотека отсутствует.

Зависимость проверяется дважды, один раз внутри цели extract, а затем из цели install. Кроме того, имя зависимости помещается в пакет, так что pkg_add(1) будет автоматически её устанавливать, если её нет на пользовательской системе.

В этой переменной перечисляются выполнимые файлы или файлы, от которых зависит работа порта. Это список пар вида path:dir[:target] где path - это имя программы или файла, а dir - каталог, в котором можно найти порт в случае, если его нет в системе, и target - это цель, которую нужно вызвать в этом каталоге. Если path начинается со слэша (/), он воспринимается как файл и его существование проверяется командой test -e; в противном случае предполагается, что это выполнимый файл, и для определения того, имеется ли программа в пути поиска, используется команда which -s.

Например,

RUN_DEPENDS=   ${LOCALBASE}/news/bin/innd:${PORTSDIR}/news/inn \
	       xmlcatmgr:${PORTSDIR}/textproc/xmlcatmgr

проверит существование файла или каталога /usr/local/news/bin/innd, и если ничего не будет найдено, то построит и установит порт из подкаталога news/inn дерева портов. Также будет выполнена проверка, присутствует ли в пути поиска исполняемый файл с именем xmlcatmgr, и перейдет в подкаталог textproc/xmlcatmgr вашего дерева портов для его построения и установки, если он не будет найден.

/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

Зависимость проверяется внутри цели install. Кроме того, имя зависимости помещается в пакет, так что программа pkg_add(1) будет автоматически его устанавливать, если он не будет найден в пользовательской системе. Часть target может быть опущена, если она совпадает с DEPENDS_TARGET.

Довольно распространенной является ситуация, когда RUN_DEPENDS буквально такая же как BUILD_DEPENDS, особенно если переносимое программное обеспечение написано на языке сценариев, или если оно требует такое же окружение для исполнения, как и используемое во время построения. В этом случае, очень заманчивым или довольно естественным является присвоение одного другому:

RUN_DEPENDS= ${BUILD_DEPENDS}

Тем не менее, подобные присвоения могут загрязнять зависимости времени исполнения содержимым, не заданным в BUILD_DEPENDS исходного порта. Такое случается из-за ленивого вычисления в make(1) присваиваемых переменных. Представьте Makefile с переменными USE_*, которые обрабатываются в ports/Mk/bsd.*.mk для пополнения первоначальных зависимостей построения. Например, USES= gmake добавляет devel/gmake в BUILD_DEPENDS. Для предотвращения загрязнения RUN_DEPENDS подобными дополнительными зависимостями проявляйте осторожность с присвоением с раскрытием, т.е. с раскрытием значения перед его присвоением переменной:

RUN_DEPENDS:=  ${BUILD_DEPENDS}

В этой переменной перечисляются выполнимые или обычные файлы, которые требуются порту для его построения. Как и RUN_DEPENDS, это список пар path:dir[:target] Например,

BUILD_DEPENDS=  unzip:${PORTSDIR}/archivers/unzip

будет проверять наличие выполнимого фала с именем unzip и перейдет в подкаталог archivers/unzip вашего дерева портов для его построения и установки, если последний не будет найден.

В этой переменной перечисляются выполняемые файлы или просто файлы, которые требуются порту для сгрузки. Как и предыдущие две переменные, это список пар path:dir[:target] Например,

FETCH_DEPENDS=  ncftp2:${PORTSDIR}/net/ncftp2

будет проверять наличие выполняемого файла с именем ncftp2 и перейдет в каталог net/ncftp2 вашего дерева портов для его построения и установки, если тот не будет найден.

Зависимость проверяется при выполнении цели fetch. Часть target может быть опущена, если она совпадает с DEPENDS_TARGET.

В этой переменной указываются программы или файлы, которые требуются для распаковки порта. Как и в предыдущих случаях, это список пар вида path:dir[:target]. Например,

EXTRACT_DEPENDS=        unzip:${PORTSDIR}/archivers/unzip

будет проверять наличие программы с именем unzip, и перейдёт в подкаталог archivers/unzip вашего дерева портов для её построения и установки, если такой программы не будет найдено.

Зависимость проверяется внутри цели extract. Часть target может быть опущена, если она совпадает с DEPENDS_TARGET.

Эта переменная указывает на программы или файлы, которые нужны порту для применения патчей. Как и в предыдущих случаях, это список пар вида path:dir[:target]. Например,

PATCH_DEPENDS=  ${NONEXISTENT}:${PORTSDIR}/java/jfc:extract

будет переходить в подкаталог java/jfc вашего дерева портов для распаковки.

Зависимость проверяется внутри цели patch. Часть target может быть опущена, если она совпадает с DEPENDS_TARGET.

Существует несколько параметров для определения различных видов характерных особенностей и зависимостей, которыми обладает рассматриваемый порт. Они могут быть указаны путём добавления следующей строки в Makefile порта:

USES= feature[:arguments]

Для получения полного списка значений смотрите Раздел 15.1, «Значения USES».

Для определения общих зависимостей, совместно используемых многими портами, предназначено несколько переменных. Их использование является необязательным, но помогает упростить избыточность файлов Makefile порта. Каждый из них оформляется как USE_*. Эти переменные можно использовать только в Makefile порта и ports/Mk/bsd.*.mk. Они не предназначены для установки пользователями параметров — используйте для этих целей PORT_OPTIONS.

USE_GCC=X.Y

Переменные, относящиеся к gmake и сценарию configure, описаны в Раздел 6.3, «Механизмы построения», а autoconf, automake и libtool описаны в Раздел 6.4, «Использование GNU autotools». Переменные, связанные с Perl, описаны в Раздел 6.6, «Использование Perl». Переменные X11 перечислены в Раздел 6.7, «Использование X11». Раздел 6.8, «Использование GNOME» работает с переменными GNOME и Раздел 6.10, «Использование KDE» с KDE. Раздел 6.11, «Использование Java» описывает переменные Java, а Раздел 6.12, «Веб-приложения, Apache и PHP» содержит информацию об Apache, PHP и модулях PEAR. Python обсуждается в Раздел 6.13, «Использование Python», а Ruby в Раздел 6.16, «Использование Ruby». Раздел 6.17, «Использование SDL» предоставляет переменные, используемые для приложений SDL, и, наконец, Раздел 6.20, «Использование Xfce» содержит информацию о приложении Xfce.

Минимальная версия зависимости может быть указана в любой переменной *_DEPENDS, за исключением LIB_DEPENDS, с использованием следующего синтаксиса:

p5-Spiffy>=0.26:${PORTSDIR}/devel/p5-Spiffy

Первое поле содержит название зависимого пакета, которое обязано совпадать с записью в базе данные пакетов, знак сравнения и версию версию пакета. Зависимость удовлетворяется если на машине установлен p5-Spiffy-0.26 или новее.

Как уже отмечено выше, целью, которая вызывается по умолчанию в случае, когда это требует зависимость, является DEPENDS_TARGET. Она по умолчанию есть install. Это пользовательская переменная; она нигде не определена в файле Makefile порта. Если вашему порту требуется особый метод обработки зависимости, воспользуйтесь частью :target переменной *_DEPENDS вместо того, чтобы переопределять DEPENDS_TARGET.

Когда вы набираете команду make clean, эта операция также выполняется и над зависимостями этого порта. Если вы не хотите, чтобы это случилось, определите переменную NOCLEANDEPENDS в вашем окружении. Это может быть особенно нужным, если порт имеет нечто, что занимает много времени на построение, в своём списке зависимостей, например, KDE, GNOME или Mozilla.

Чтобы безусловно зависеть от другого порта, укажите переменную ${NONEXISTENT} в качестве первого поля переменной BUILD_DEPENDS или RUN_DEPENDS. Пользуйтесь этим, только когда вам нужно иметь исходный код другого порта. Вы можете сэкономить время на компиляции, указав также и цель. Например,

BUILD_DEPENDS=   ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract

всегда будет переходить в каталог с портом jpeg и распаковывать его.

Технология построения портов не защищена от зацикленных зависимостей. Если вы создадите такую, то у кого-нибудь и где-нибудь установка FreeBSD будет немедленно сломана, а у остальных сломается несколько позже. Это на самом деле очень трудно распознать; если вы сомневаетесь, то перед внесением изменений проверьте, что выполнили следующее: cd /usr/ports; make index. Этот процесс может быть достаточно медленным на старых машинах, хотя мы сможете спасти большое количество людей—включая себя—от грядущих бед.

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

.include <bsd.port.pre.mk>

.if exists(${LOCALBASE}/bin/foo)
LIB_DEPENDS=	bar:${PORTSDIR}/foo/bar
.endif

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

OPTIONS_DEFINE=	BAR
BAR_DESC=	Bar support

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MBAR}
LIB_DEPENDS=	bar:${PORTSDIR}/foo/bar
.endif

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

Переменные USE_ задаются мейнтейнером порта для определения программного обеспечения, от которого этот порт зависит. Порт, для которого нужен Firefox, укажет

USE_FIREFOX=	yes

Некоторые переменные USE_ могут принимать номера версий или другие параметры. Например, порт, который требует Apache 2.2, укажет

USE_APACHE=	22

В некоторых случаях для большего контроля над зависимостями используются переменные WANT_, которые позволяют указывать требования в более точной форме. Например, взгляните на порт mail/squirrelmail. Этому порту нужны несколько модулей PHP, которые перечислены в переменной USE_PHP:

USE_PHP=	session mhash gettext mbstring pcre openssl xml

Эти модули доступны в версиях CLI и web, поэтому версия web выбрана с переменной WANT_:

WANT_PHP_WEB=	yes

Имеющиеся переменные USE_ и WANT_ определены в файлах /usr/ports/Mk.

При использовании сценария GNU configure, следите за тем, какие необязательные функции задействуются посредством автоматической активации. Отключайте явным образом те необязательные функции, которые вы не хотели бы использовать, через передачу соответствующих --without-xxx или --disable-xxx в переменной CONFIGURE_ARGS.

.if ${PORT_OPTIONS:MFOO}
LIB_DEPENDS+=		libfoo.so:${PORTSDIR}/devel/foo
CONFIGURE_ARGS+=	--enable-foo
.endif

В приведенном выше примере представьте себе библиотеку libfoo, установленную в системе. Пользователь не желает, чтобы приложение использовало libfoo, и поэтому он выключает соответствующую опцию в диалоге make config. Но сценарий configure приложения определяет наличие библиотеки в системе и включает ее поддержку в итоговый исполняемый файл. Теперь, когда пользователь решит удалить libfoo из системы, система портов позволит это сделать (т.к. зависимость от libfoo не была записана), но приложение перестанет работать.

.if ${PORT_OPTIONS:MFOO}
LIB_DEPENDS+=		libfoo.so:${PORTSDIR}/devel/foo
CONFIGURE_ARGS+=	--enable-foo
.else
CONFIGURE_ARGS+=	--disable-foo
.endif

Во втором примере библиотека libfoo отключена явным образом. Сценарий configure не включает соответствующие функции в приложении, несмотря на присутствие библиотеки в системе.

.if !empty(VARIABLE:MVALUE)
# as an alternative to
.if ${VARIABLE:MVALUE}

Существует несколько макросов, упрощающих запись условных значений, которые отличаются в зависимости от набора параметров.

Если переменная OPTIONS_SUB имеет значение yes, то каждый из указанных в OPTIONS_DEFINE параметров будет добавлен в PLIST_SUB. Следующая запись:

OPTIONS_DEFINE=	OPT1
OPTIONS_SUB=	yes

соответствует:

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
PLIST_SUB+=	OPT1=""
.else
PLIST_SUB+=	OPT1="@comment "
.endif

X_CONFIGURE_ENABLE дописывает в CONFIGURE_ARGS строку --enable-${X_CONFIGURE_ENABLE} или --disable-${X_CONFIGURE_ENABLE} в соответствии с состоянием X. Следующая запись:

OPTIONS_DEFINE=	OPT1
OPT1_CONFIGURE_ENABLE=	test

соответствует:

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
CONFIGURE_ARGS+=	--enable-test
.else
CONFIGURE_ARGS+=	--disable-test
.endif

X_CONFIGURE_WITH дописывает в CONFIGURE_ARGS строку --with-${X_CONFIGURE_WITH} или --without-${X_CONFIGURE_WITH} в соответствии с состоянием X. Следующая запись:

OPTIONS_DEFINE=	OPT1
OPT1_CONFIGURE_WITH=	test

соответствует:

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
CONFIGURE_ARGS+=	--with-test
.else
CONFIGURE_ARGS+=	--without-test
.endif

Значение переменной X_CONFIGURE_ON будет дописано в CONFIGURE_ARGS в соответствии с состоянием X. Следующая запись:

OPTIONS_DEFINE=	OPT1
OPT1_CONFIGURE_ON=	--add-test

соответствует:

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
CONFIGURE_ARGS+=	--add-test
.endif

Значение переменной X_CONFIGURE_OFF будет дописано в CONFIGURE_ARGS в соответствии с состоянием X. Следующая запись:

OPTIONS_DEFINE=	OPT1
OPT1_CONFIGURE_OFF=	--no-test

соответствует:

OPTIONS_DEFINE=	OPT1
.include <bsd.port.options.mk>
.if ! ${PORT_OPTIONS:MOPT1}
CONFIGURE_ARGS+=	--no-test
.endif

Значение переменной X_CMAKE_ON будет дописано в CMAKE_ARGS в соответствии с состоянием X. Следующая запись:

OPTIONS_DEFINE=	OPT1
OPT1_CMAKE_ON=	-DTEST:BOOL=true

соответствует:

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
CMAKE_ARGS+=	-DTEST:BOOL=true
.endif

Значение переменной X_CMAKE_OFF будет дописано в CMAKE_ARGS в соответствии с состоянием X. Следующая запись:

OPTIONS_DEFINE=	OPT1
OPT1_CMAKE_OFF=	-DTEST:BOOL=false

соответствует:

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ! ${PORT_OPTIONS:MOPT1}
CMAKE_ARGS+=	-DTEST:BOOL=false
.endif

Для любой из следующих переменных:

Значение переменной X_ABOVEVARIABLE будет дописано в ABOVEVARIABLE в соответствии с состоянием X. Следующая запись:

OPTIONS_DEFINE=	OPT1
OPT1_USES=	gmake
OPT1_CFLAGS=	-DTEST

соответствует:

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
USES+=		gmake
CFLAGS+=	-DTEST
.endif

Для любого из следующих типов зависимости:

Значение переменной X_ABOVEVARIABLE будет дописано в ABOVEVARIABLE в соответствии с состоянием X. Следующая запись:

OPTIONS_DEFINE=	OPT1
OPT1_LIB_DEPENDS=	liba.so:${PORTSDIR}/devel/a

соответствует:

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
LIB_DEPENDS+=	liba.so:${PORTSDIR}/devel/a
.endif

Эта переменная задаёт имя каталога, который создаётся при распаковке исходных файлов приложения. В нашем предыдущем примере если бы распаковка происходила в каталог с именем foo (а не foo-1.0), то вы должны написать:

WRKSRC=      ${WRKDIR}/foo

или, как вариант

WRKSRC=      ${WRKDIR}/${PORTNAME}

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

NO_WRKSUBDIR= yes

Если ваш пакет не может существовать вместе с другими (из-за конфликта файлов, несовместимости времени выполнения и так далее), перечислите имена остальных пакетов в переменной CONFLICTS_INSTALL. Здесь вы можете использовать шаблоны командного интерпретатора, такие как * и ?. Имена пакетов должны выглядеть так же, как в /var/db/pkg. Пожалуйста, убедитесь, что CONFLICTS_INSTALL не содержит пакет самого этого порта. В противном случае не будет работать установка с использованием переменной FORCE_PKG_REGISTER. Проверка CONFLICTS_INSTALL выполняется после процесса сборки и до процесса установки.

Если ваш порт не может быть собран, когда уже установлен другой, перечислите имена остальных портов в переменной CONFLICTS_BUILD. Здесь вы можете использовать шаблоны командного интерпретатора, такие как * и ?. Имена пакетов должны выглядеть так же, как в /var/db/pkg. Проверка CONFLICTS_BUILD выполняется до процесса сборки. Конфликты сборки в получаемом пакете не записываются.

Если ваш порт не может быть собран, когда уже установлен другой, а получаемый пакет не может существовать вместе с другими, перечислите имена остальных пакетов в переменной CONFLICTS. Здесь вы можете использовать шаблоны командного интерпретатора, такие как * и ?. Имена пакетов должны выглядеть так же, как в /var/db/pkg. Пожалуйста, убедитесь, что CONFLICTS не содержит пакет самого этого порта. В противном случае не будет работать установка с использованием переменной FORCE_PKG_REGISTER. Проверка CONFLICTS выполняется до процессов сборки и установки.

Используйте макросы, которые есть в файле bsd.port.mk для обеспечения правильных прав доступа и владения файлов в своих целях *-install.

В основе работы этих макросов лежит команда install со всеми соответствующими флагами. Смотрите пример их использования ниже.

Не удаляйте отладочную информацию из бинарных файлов вручную, если вы это делали. Во всех двоичных файлах отладочная информация должна быть удалена, и макрос INSTALL_PROGRAM выполнит установку и удаление отладочной информации одновременно (обратитесь к следующему разделу). Макрос INSTALL_LIB делает то же самое для динамических библиотек.

Если вам нужно удалить отладочную информацию из файла без использования макросов INSTALL_PROGRAM и INSTALL_LIB, то это можно сделать при помощи ${STRIP_CMD}. Обычно это делается внутри цели post-install. К примеру:

post-install:
	${STRIP_CMD} ${PREFIX}/bin/xdl

Для проверки того, удалена ли отладочная информация из установленного выполнимого файла, выполните команду file(1). Если утилита не выдаст строку not stripped, то файл уже обработан. Кроме того, strip(1) не будет обрабатывать программу, отладочная информация из которой уже удалена; вместо этого утилита просто завершит свою работу.

Иногда существует необходимость в установке большого количества файлов с сохранением их иерархической организации, т.е. в копировании дерева каталогов целиком из WRKSRC в целевой каталог внутри PREFIX.

Для этой ситуации существует два макроса. Преимущество от использования этих макросов вместо команды cp в том, что они гарантируют установку правильного владельца и прав на конечные файлы. Первый макрос, COPYTREE_BIN, делает все устанавливаемые файлы исполняемыми, что подходит для установки в PREFIX/bin. Второй макрос, COPYTREE_SHARE, не устанавливает на файлы права исполнения, и, таким образом, подходит для установки файлов внутри каталога PREFIX/share.

post-install:
	${MKDIR} ${EXAMPLESDIR}
	(cd ${WRKSRC}/examples && ${COPYTREE_SHARE} . ${EXAMPLESDIR})

В этом примере устанавливается содержимое каталога examples из установочных файлов производителя в надлежащее место для примеров вашего порта.

post-install:
	${MKDIR} ${DATADIR}/summer
	(cd ${WRKSRC}/temperatures && ${COPYTREE_SHARE} "June July August" ${DATADIR}/summer)

А в этом примере будут установлены данные летних месяцев в подкаталог summer каталога DATADIR.

В качестве третьего параметра в макросе COPYTREE_* можно передать дополнительные параметры find. Например, чтобы в первом примере установить все файлы кроме файлов Makefile, можно использовать следующую команду.

post-install:
	${MKDIR} ${EXAMPLESDIR}
	(cd ${WRKSRC}/examples && \
		${COPYTREE_SHARE} . ${EXAMPLESDIR} "! -name Makefile")

Обратите внимание, что эти макросы не производят добавление устанавливаемых файлов в pkg-plist. Вам все еще нужно их перечислить.

Если с вашим программным обеспечением поставляется некоторая документация, отличающаяся от стандартных страниц Справочника и файлов info, которая, как вы думаете, будет полезна пользователям, установите ее в каталог PREFIX/share/doc. Это может быть сделано, как и в предыдущем разделе, в цели post-install.

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

Сделайте установку документации зависящей от параметра DOCS для того, чтобы пользователи могли выключить это в файле /etc/make.conf, как здесь:

post-install:
.if ${PORT_OPTIONS:MDOCS}
	${MKDIR} ${DOCSDIR}
	${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${DOCSDIR}
 .endif

Вот несколько полезных переменных и то, как они преобразуются по умолчанию при использовании в Makefile:

Эти переменные экспортируются в PLIST_SUB. Их значения появятся там в виде имён путей относительно PREFIX, если это возможно. То есть share/doc/PORTNAME в списке сборки по умолчанию будет заменен на %%DOCSDIR%%, и так далее. (Дополнительную информацию о подстановке в pkg-plist можно найти здесь.)

Все условно устанавливаемые файлы и каталоги с документацией должны быть перечислены в файле pkg-plist с префиксом %%PORTDOCS%%, например:

%%PORTDOCS%%%%DOCSDIR%%/AUTHORS
%%PORTDOCS%%%%DOCSDIR%%/CONTACT
%%PORTDOCS%%@dirrm %%DOCSDIR%%

В качестве альтернативы перечислению файлов документации в файле pkg-plist, порт может указать в переменной PORTDOCS список имён файлов и глобальных шаблонов командного процессора для добавления в окончательный список сборки. Имена будут задаваться относительно DOCSDIR. Таким образом, порт, использующий PORTDOCS и нестандартное местоположение документации, должен задавать соответствующим образом и DOCSDIR. Если каталог указан в PORTDOCS или соответствует шаблону для этой переменной, то полное поддерево с входящими в него файлами и каталогами будет регистрироваться в окончательном списке сборки. Если параметр DOCS не задан, то файлы и каталоги, перечисленные в PORTDOCS, не будут установлены и добавлены в список сборки порта. Установка документации в PORTDOCS, как это показано выше, остаётся за самим портом. Типичный пример использования PORTDOCS выглядит следующим образом:

PORTDOCS=       README.* ChangeLog docs/*

Попробуйте поместить все файлы порта в правильных подкаталогах каталога PREFIX. Некоторые порты игнорируют все установки и помещают все в подкаталог с именем порта, что неправильно. Также многие порты помещают все, кроме бинарных файлов, файлов заголовков и страниц Справочника, в подкаталог каталога lib, что не очень хорошо работает с подходом BSD. Многие файлы должны быть перемещены в одно из следующих местоположений: etc (настроечные/конфигурационные файлы), libexec (выполнимые файлы, запускаемые из других программ), sbin (исполнимые файлы для администраторов/менеджеров системы), info (документация в формате info для просмотрщика info) или share (независимые от архитектуры файлы). Обратитесь к hier(7) для прояснения деталей; правила, покрывающие /usr, достаточно хорошо подходят также и к /usr/local. Исключением являются порты, имеющие дело с «новостями» USENET. Они могут использовать каталог PREFIX/news для установки своих файлов.

Эта переменная указывает, что мы не можем создавать для приложения двоичный пакет. К примеру, лицензия не позволяет бинарное распространение или она может запрещать распространение пакетов, созданных из изменённых исходников.

Однако файлы DISTFILES могут свободно зеркалироваться по FTP/HTTP. Они также могут распространяться, используя CD-ROM (или на похожих носителях), если не установлена переменная NO_CDROM.

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

Значением переменной NO_PACKAGE должна быть строка, описывающая причину, по которой пакет не должен создаваться.

Эта переменная указывает на то, что, хотя мы имеем право создавать бинарные пакеты, мы не можем помещать эти пакеты или файлы DISTFILES порта на CD-ROM (или на похожие носители) для перепродажи. Однако бинарные пакеты и файлы DISTFILES порта будут оставаться доступными посредством FTP/HTTP.

Если эта переменная устанавливается вместе с NO_PACKAGE, то только файлы порта DISTFILES будут доступны, и только посредством FTP/HTTP.

В качестве значения NO_CDROM должна указываться строка, описывающая причины, по которым порт не может распространяться на CD-ROM. К примеру, это применяется, если лицензионное соглашение приложения предполагает только его «некоммерческое» использование.

Файлы, определенные в переменной NOFETCHFILES, не будут извлекаться ни из одного из MASTER_SITES. Примером такого файла является файл, поставляемый на CD-ROM.

Инструменты, проверяющие доступность этих файлов на MASTER_SITES, должны игнорировать эти файлы и не сообщать о них.

Задайте эту переменную, если лицензия на приложение не позволяет ни зеркалировать файлы DISTFILES, ни распространять бинарный пакет через FTP/HTTP или на CD-ROM.

Ни NO_CDROM, ни NO_PACKAGE не стоит устанавливать вместе с RESTRICTED, так как последняя переменная подразумевает первые две.

В качестве значения RESTRICTED должна указываться строка, описывающая причины, по которым порт нельзя распространять. Обычно это означает, что порт использует закрытое программное обеспечение, а пользователь должен вручную сгрузить файлы DISTFILES, возможно, после заполнения регистрационной формы или подтверждения соглашения с условиями EULA.

Если заданы RESTRICTED или NO_CDROM, то значение этой переменной по умолчанию соответствует ${DISTFILES} ${PATCHFILES}, в противном случае она пуста. Если ограничены в распространении лишь некоторые из дистрибутивных файлов, то в этой переменной задаётся их список.

Обратите внимание, что при включении порта в дерево исходных текстов системы коммиттер должен добавить запись в файл /usr/ports/LEGAL для каждого из перечисленных файлов, в точности описав, что подразумевают ограничения.

Предпочтительным способом реализации утверждения "архивы исходных текстов для этого порта должны загружаться самостоятельно" является следующее:

.if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX})
IGNORE=         may not be redistributed because of licensing reasons. Please visit some-website to accept their license and download ${DISTFILES} into ${DISTDIR}
.endif

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

Обратите внимание, что данная кляуза должна предшествовать подключению файла bsd.port.pre.mk.

Инфраструктура портов FreeBSD поддерживает параллельное построение с использованием множественных подпроцессов make, что позволяет системам SMP задействовать всю доступную мощность CPU, тем самым делая построение портов более быстрым и эффективным.

Это достигается путем передачи флага -jX команде make(1). К сожалению, не все порты поддерживают параллельную сборку достаточно хорошо. Поэтому требуется включать этот механизм явным образом путем добавления строки MAKE_JOBS_SAFE=yes в Makefile где-нибудь после раздела с объявлениями зависимостей.

Другой опцией управления этим механизмом с точки зрения сопровождающего является MAKE_JOBS_UNSAFE=yes. Эта переменная используется в случае, когда известно, что порт ломается с -jX, и пользователь форсирует использование многопроцессорной компиляции для всех портов с переменной FORCE_MAKE_JOBS=yes в /etc/make.conf.

Если ваш порт использует GNU make, то установите USES= gmake.

Если ваш порт является приложением X, которое создает файлы Makefile из Imakefile, используя imake, то установите USES= imake. Это заставит стадию конфигурирования автоматически выполнить xmkmf -a. Если флаг -a представляет для вашего порта проблему, то установите XMKMF=xmkmf. Если порт использует imake, но не понимает цель install.man, то следует установить NO_INSTALL_MANPAGES=yes.

Если исходный Makefile вашего порта имеет что-нибудь помимо all в качестве основной цели построения, то задайте соответствующее значение ALL_TARGET. То же касается install и INSTALL_TARGET.

Если ваш порт использует сценарий configure для получения файлов Makefile из файлов Makefile.in, то установите GNU_CONFIGURE=yes. Если вы хотите дать дополнительные параметры сценарию configure (аргументом по умолчанию является --prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH} --mandir=${MANPREFIX}/man --build=${CONFIGURE_TARGET}), установите эти параметры в CONFIGURE_ARGS. Дополнительные переменные окружения можно передать, используя переменную CONFIGURE_ENV.

Если ваш порт использует CMake, определите USES= cmake или USES= cmake:outsource для построения во внешнем каталоге (см. ниже).

CMake поддерживает следующие профили построения: Debug, Release, RelWithDebInfo и MinSizeRel. Профили Debug и Release учитывают системные флаги *FLAGS; RelWithDebInfo и MinSizeRel соответственно определяют CFLAGS со значением -O2 -g и -Os -DNDEBUG. Значение CMAKE_BUILD_TYPE экспортируется в нижнем регистре в PLIST_SUB и должно использоваться, если порт устанавливает файлы *.cmake в зависимости от типа построения (для примера посмотрите на deskutils/strigi). Следует учитывать, что некоторые проекты могут определять собственные профили построения и/или форсировать конкретный тип построения через установку CMAKE_BUILD_TYPE в файлах CMakeLists.txt . Для того чтобы порт для такого проекта учитывал CFLAGS и WITH_DEBUG, из этих файлов должны быть удалены значения CMAKE_BUILD_TYPE.

Большинство проектов, основанных на CMake, поддерживают метод внешнего (out-of-source) построения. Для порта внешнее построение можно запросить с использованием суффикса :outsource. В этом случае CONFIGURE_WRKSRC, BUILD_WRKSRC и INSTALL_WRKSRC будут иметь значение ${WRKDIR}/.build для каталога, содержащего файлы, получаемые на этапах конфигурации и построения; при этом каталог с исходным кодом будет оставаться без изменений.

USES=			cmake:outsource
CMAKE_SOURCE_PATH=	${WRKSRC}/subproject

Если ваш порт использует SCons, определите USE_SCONS=yes.

Для того, чтобы сторонний SConstruct соответствовал всему, что передается SCons в переменной SCONS_ENV (самое главное, это CC/CXX/CFLAGS/CXXFLAGS), примените патч к SConstruct, так чтобы переменная построения Environment выглядела следующим образом:

env = Environment(**ARGUMENTS)

В дальнейшем ее можно изменить при помощи env.Append и env.Replace.

Различные инструменты GNU autotools предоставляют механизм абстракции для построения частей программного обеспечения на широком наборе операционных систем и аппаратных архитектур. Внутри Коллекции Портов отдельный порт может использовать эти инструменты при помощи простых конструкций:

USE_AUTOTOOLS= tool:version[:operation] ...

К моменту написания tool может быть одним из libtool, libltdl, autoconf, autoheader, automake или aclocal.

version указывает конкретную версию используемого инструмента (действующие версии смотрите в devel/{automake,autoconf,libtool}[0-9]+).

operation является необязательным расширением и указывает на способ использования инструмента.

Одновременно может быть указано несколько инструментов, добавляя их все на одной строке или используя конструкцию Makefile +=.

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

Динамические библиотеки, использующие инфраструктуру построения GNU, обычно используют libtool для настройки компиляции и установки динамических библиотек в соответствии с особенностями данной операционной системы. В типичной практике используется копирование встроенного в приложение libtool. Если вам нужно использовать внешнюю команду libtool, то вы можете использовать версию, поставляемую Коллекцией Портов:

USE_AUTOTOOLS= libtool:version[:env]

При отсутствии дополнительных операций, libtool:version сообщает инфраструктуре построения о применении патча к сценарию configure с установленной в системе копией libtool. Подразумевается использование The GNU_CONFIGURE Более того, некоторые переменные make и оболочки shell будут назначены для дальнейшего использования этим портом. Подробности смотрите в bsd.autotools.mk.

При использовании операции :env будет настроено только окружение.

Наконец, LIBTOOLFLAGS и LIBTOOLFILES можно установить по желанию, чтобы переопределить наиболее вероятные аргументы для libtool и файлы, предназначенные для изменения. Большинству портов это скорее всего не понадобится. Для дальнейших подробностей смотрите bsd.autotools.mk.

Некоторые порты задействуют пакет с библиотекой libltdl, которая является частью комплекта libtool. Использование этой библиотеки не вызывает автоматическое использование самой libtool, и, таким образом, обеспечивается отдельная конструкция.

USE_AUTOTOOLS= libltdl:version

Всё, что в настоящее время она делает, это добавление LIB_DEPENDS для подходящего порта libltdl, потому она предоставляется как удобная функция для помощи в устранении всяких зависимостей от портов autotools вне инфраструктуры USE_AUTOTOOLS. Для этого инструмента не существует необязательных операций.

Некоторые порты не содержат сценарий configure, но содержат шаблон autoconf в файле configure.ac. Вы можете использовать следующие присвоения, чтобы позволить autoconf создать сценарий configure, а autoheader создать заголовки шаблона для использования в сценарии configure.

USE_AUTOTOOLS=	autoconf:version[:env]

и

USE_AUTOTOOLS=	autoheader:version

которые также подразумевают использование autoconf:version.

Аналогично команде libtool, подключение необязательной операции :env всего лишь настраивает окружение для дальнейшего использования. Без этого выполняется наложение патчей и переконфигурирование порта.

Дополнительные необязательные переменные AUTOCONF_ARGS и AUTOHEADER_ARGS можно переопределить в Makefile порта, если указано явным образом. Как и с эквивалентами libtool, большинству портов это вряд ли понадобится.

Некоторые пакеты содержат только файлы Makefile.am. Они должны быть преобразованы в файлы Makefile.in с использованием automake и дальнейшей обработкой configure для получения настоящего Makefile.

Аналогично, иногда пакеты не поставляются с вложенными файлами aclocal.m4, снова требуемых для построения программного обеспечения. Этого можно достичь с aclocal, которая просматривает configure.ac или configure.in.

aclocal имеет похожую связь с automake, как у autoheader с autoconf, что описано в предыдущей главе. aclocal подразумевает использование automake, таким образом, мы имеем:

USE_AUTOTOOLS=	automake:version[:env]

и

USE_AUTOTOOLS=	aclocal:version

которые также подразумевают использование automake:version.

Также как и для libtool и autoconf, подключение необязательной операции :env всего лишь устанавливает окружение для дальнейшего пользования. Без этого выполняется реконфигурирование этого порта.

Как и в случае с autoconf и autoheader, обе automake и aclocal имеют необязательные переменные AUTOMAKE_ARGS и ACLOCAL_ARGS, соответственно, которые при необходимости можно переопределить в Makefile порта.

Если для вашего порта требуется gettext, добавьте USES= gettext, и ваш порт унаследует зависимость от devel/gettext. Раздел 15.1, «Значения USES» содержит перечень других значений для использования gettext.

Довольно распространенным случаем является использование в порте gettext и configure. Как правило, GNU configure способен находить gettext автоматически. Если он все же не сможет это сделать, то подсказки для размещения gettext можно передать через переменные окружения CPPFLAGS и LDFLAGS:

USES=	gettext
CPPFLAGS+=      -I${LOCALBASE}/include
LDFLAGS+=       -L${LOCALBASE}/lib

GNU_CONFIGURE=  yes

Конечно же, этот код можно записать в более компактном виде, если передавать флаги в configure не требуется:

USES=	gettext
GNU_CONFIGURE=  yes

Некоторые программные продукты позволяют отключать NLS, к примеру через передачу параметра --disable-nls сценарию configure. В этом случае ваш порт должен использовать gettext, в зависимости от значения NLS. Для портов небольшой или средней сложности вы можете полагаться на следующую идиому:

GNU_CONFIGURE=          yes

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MNLS}
USES+=			gettext
PLIST_SUB+=             NLS=""
.else
CONFIGURE_ARGS+=        --disable-nls
PLIST_SUB+=             NLS="@comment "
.endif

.include <bsd.port.mk>

Следующий пункт в вашем списке дел разобраться, чтобы файлы каталога сообщения включались в список упаковки по условию. Часть, входящая в Makefile, уже обеспечена этой идиомой. Остальное объясняется в главе продвинутые практики pkg-plist. Вкратце, каждое вхождение %%NLS%% в pkg-plist будет заменено на «@comment », если NLS выключен, или пустой строкой, если включен. В результате строки, предваряемые %%NLS%%, станут комментариями в итоговом листе упаковки, если NLS выключен; иначе, префикс будет просто удален. Всё, что вам нужно, это вставить %%NLS%% перед каждым путем к файлу каталога сообщений в pkg-plist. Например:

%%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo
%%NLS%%share/locale/no/LC_MESSAGES/foobar.mo

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

Существует момент, который следует учитывать при установке файлов каталогов сообщений. Целевые каталоги для размещения, расположенные под LOCALBASE/share/locale, редко когда должны создаваться и удаляться портом. Для наиболее популярных языков имеются собственные каталоги, перечисленные в PORTSDIR/Templates/BSD.local.dist. Каталоги для множества других языков управляются с помощью порта devel/gettext. Обратите внимание на его pkg-plist и посмотрите, куда данный порт собирается установить файлы каталогов сообщений для единственного в своем роде языка.

X.Org является реализацией X11, доступной в Коллекции Портов. Если ваше приложение зависит от компонентов X, установите в переменную USE_XORG в перечень требуемых компонентов. К настоящему времени доступными компонентами являются:

bigreqsproto compositeproto damageproto dmx dmxproto dri2proto evieproto fixesproto fontcacheproto fontenc fontsproto fontutil glproto ice inputproto kbproto libfs oldx pciaccess pixman printproto randrproto recordproto renderproto resourceproto scrnsaverproto sm trapproto videoproto x11 xau xaw xaw6 xaw7 xbitmaps xcmiscproto xcomposite xcursor xdamage xdmcp xevie xext xextproto xf86bigfontproto xf86dgaproto xf86driproto xf86miscproto xf86rushproto xf86vidmodeproto xfixes xfont xfontcache xft xi xinerama xineramaproto xkbfile xkbui xmu xmuu xorg-server xp xpm xprintapputil xprintutil xproto xproxymngproto xrandr xrender xres xscrnsaver xt xtrans xtrap xtst xv xvmc xxf86dga xxf86misc xxf86vm.

Всегда актуальный перечень можно найти в /usr/ports/Mk/bsd.xorg.mk.

Проект Mesa является попыткой обеспечить свободную реализацию OpenGL. Вы можете указать зависимость от различных компонентов этого проекта при помощи переменной USE_GL. Действительные опции: glut, glu, glw, glew, gl и linux. Для обратной совместимости значение yes соответствует glu.

USE_XORG=   xrender xft xkbfile xt xaw
USE_GL=     glu

# Использовать некоторые библиотеки X11
USE_XORG=      x11 xpm

Если вашему порту требуется Motif, задайте переменную USES= motif в файле Makefile. Реализация Motif, используемая по умолчанию, находится в x11-toolkits/open-motif. Пользователи вместо этого могут выбрать x11-toolkits/lesstif через установку переменной WANT_LESSTIF.

Переменная MOTIFLIB будет установлена в bsd.port.mk, чтобы ссылаться на соответствующую библиотеку Motif. Пожалуйста, измените исходные тексты вашего порта на использование ${MOTIFLIB} везде, где упоминается библиотека Motif, в первоначальном Makefile или Imakefile.

Существует два общих случая:

Заметьте, что переменная MOTIFLIB (как правило) раскрывается в -L/usr/local/lib -lXm или /usr/local/lib/libXm.a, так что нет нужды впереди добавлять -L или -l.

Если ваш порт устанавливает шрифты для X Window System, поместите их в каталог LOCALBASE/lib/X11/fonts/local.

Некоторые приложения для успешной компиляции требуют наличие работающего дисплея X11. Это создает проблему для машин, которые работают в режиме headless. При использовании следующего канонического хака инфраструктура построения запустит сервер X в виртуальном фреймбуфере. Затем переменная работающего DISPLAY передается при построении.

USES=	display

Элементы рабочего стола (стандарта Freedesktop) предоставляют способ автоматической настройки функций рабочего стола при установке новой программы, не требуя вмешательства пользователя. Например, новые программы автоматически отображаются в меню приложений совместимых окружений рабочего стола. Элементы рабочего стола изначально появились в окружении рабочего стола GNOME, но в настоящее время являются стандартом и также работают с KDE и Xfce. Такая небольшая автоматизация предоставляет реальное удобство для пользователя, и посему элементы рабочего стола приветствуются в приложениях, которые можно использовать в окружении рабочего стола.

DESKTOP_ENTRIES=  "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify

DESKTOP_ENTRIES=  "ToME" "Roguelike game based on JRR Tolkien's work" \
                  "${DATADIR}/xtra/graf/tome-128.png" \
                  "tome -v -g" "Application;Game;RolePlaying;" \
                  false

Когда переменная USE_QT_VER определена со значением 3, сценарию configure можно передавать некоторые полезные настройки:

CONFIGURE_ARGS+= --with-qt-includes=${QT_PREFIX}/include \
                 --with-qt-libraries=${QT_PREFIX}/lib \
                 --with-extra-libs=${LOCALBASE}/lib \
                 --with-extra-includes=${LOCALBASE}/include
CONFIGURE_ENV+=  MOC="${MOC}" LIBS="${QTCFGLIBS}" \
                 QTDIR="${QT_PREFIX}" KDEDIR="${KDE_PREFIX}"
CPPFLAGS+=       ${QTCPPFLAGS}

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

CONFIGURE_ARGS+=	--with-qt-includes=${QT_INCDIR} \
			--with-qt-libraries=${QT_LIBDIR} \
			--with-extra-libs=${LOCALBASE}/lib \
			--with-extra-includes=${LOCALBASE}/include
CONFIGURE_ENV+=	MOC="${MOC}" UIC="${UIC}" LIBS="${QTCFGLIBS}" \
		QMAKE="${QMAKE}" QMAKESPEC="${QMAKESPEC}" QTDIR="${QT_PREFIX}"
MAKE_ENV+=	QMAKESPEC="${QMAKESPEC}"

PLIST_SUB+=	QT_INCDIR_REL=${QT_INCDIR_REL} \
		QT_LIBDIR_REL=${QT_LIBDIR_REL} \
		QT_PLUGINDIR_REL=${QT_PLUGINDIR_REL}

В переменной USE_QT4 должны указываться зависимости от отдельных инструментов и библиотек Qt 4. К каждому компоненту можно добавить суффикс, _build или _run, отражающий, когда должна быть применена зависимость, во время сборки или выполнения, соответственно. Если суффикс отсутствует, зависимость от компонента будет и для времени сборки, и для времени выполнения. Обычно, компоненты библиотек должны указываться без суффиксов, компоненты инструментов - с суффиксом _build, а компоненты плагинов - с суффиксом _run. Наиболее общие используемые компоненты перечислены ниже (все доступные компоненты перечислены в _USE_QT4_ALL в файле /usr/ports/Mk/bsd.qt.mk):

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

USE_QT4=	gui moc_build qmake_build rcc_build uic_build

Если вместе с приложением вместо configure поставляется файл .pro, вы можете использовать следующее:

HAS_CONFIGURE=	yes

do-configure:
        @cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} \
                ${QMAKE} ${QMAKEFLAGS} PREFIX=${PREFIX} texmaker.pro

Обратите внимание на сходство со строкой qmake из прилагаемого сценария BUILD.sh. Передача CONFIGURE_ENV обеспечивает видимость переменной QMAKESPEC для qmake, без которой команда не может работать. qmake порождает стандартные Makefile, и, таким образом, отпадает необходимость в написании своих собственных целей build.

Приложения Qt часто пишутся в кроссплатформенной манере, и X11/Unix часто не является для них платформой разработки, что в свою очередь часто приводит к соответствующим упущенным моментам:

Если ваше приложение зависит от KDE 4.x, присвойте USE_KDE4 список требуемых компонентов. Для переопределения типа зависимости компонента могут быть использованы суффиксы _build и _run (например, baseapps_run). Если суффикс не задан, будет использован тип зависимости по умолчанию. Если вы хотите использовать оба типа, добавьте компонент дважды с обоими суффиксами (например, automoc4_build automoc4_run). Основные наиболее используемые компоненты перечислены ниже (актуальные компоненты задокументированы в начале файла /usr/ports/Mk/bsd.kde4.mk):

Порты KDE 4.x устанавливаются в KDE4_PREFIX, что в настоящее время соответствует /usr/local/kde4. Это достигается путем указания компонента kdeprefix, который определяет значение по умолчанию для PREFIX. Тем не менее, порты учитывают любые PREFIX, установленные через переменную окружения MAKEFLAGS и/или параметры make.

USES=		cmake:outsource
USE_KDE4=	kdelibs kdeprefix automoc4
USE_QT4=	moc_build qmake_build rcc_build uic_build

Если вашему порту необходимо наличие Java™ Development Kit (JDK™) для построения, работы или даже распаковки дистрибутивного файла, то в нём должна быть задана переменная USE_JAVA.

В Коллекции Портов присутствуют несколько JDK различных разработчиков и разных версий. Если ваш порт должен использовать одну из этих версий, то вы должны указать, какую именно. Самой последней версией и версией по умолчанию является java/openjdk6.

Ниже перечисляются все значения, которые принимают переменные после задания переменной USE_JAVA:

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

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

Соответствующие записи определяются в обоих переменных PLIST_SUB (описана в Раздел 7.1, «Изменение содержимого pkg-plist в зависимости от make-переменных») и SUB_LIST.

Если построение порта производится с использованием Apache Ant, то необходимо определить USE_ANT. Таким образом Ant становится подкомандой make. Если в порте не определена цель do-build, то будет установлена цель по умолчанию, которая просто запускает Ant в соответствии со значением MAKE_ENV, MAKE_ARGS и ALL_TARGET. Это похоже на механизм USES= gmake, который описан в Раздел 6.3, «Механизмы построения».

При портировании Java-библиотеки ваш порт должен устанавливать JAR-файл(ы) в каталог ${JAVAJARDIR}, а все остальные данные в каталог ${JAVASHAREDIR}/${PORTNAME} (за исключением документации, о которой пойдёт речь ниже). Для уменьшения размера упакованного файла вы можете сослаться на JAR-файл(ы) непосредственно в файле Makefile. Просто воспользуйтесь следующей директивой (в которой myport.jar является именем JAR-файла, устанавливаемого как часть порта):

PLIST_FILES+= %%JAVAJARDIR%%/myport.jar

При портировании Java-приложения порт обычно устанавливает всё в один каталог (в том числе все свои JAR-зависимости). В этом отношении настоятельно рекомендуется использование ${JAVASHAREDIR}/${PORTNAME}. На усмотрение создателя порта остаётся решение вопроса о том, устанавливать ли дополнительные JAR-зависимости в этот каталог или напрямую использовать уже установленные (из каталога ${JAVAJARDIR}).

Вне зависимости от типа вашего порта (библиотека это или приложение), дополнительная документация должна быть устанавливаться в тоже самое место, что и для других портов. Известно, что в зависимости от используемой версии JDK утилита JavaDoc генерирует различные наборы файлов. Для портов, которые не привязаны к использованию определённой версии JDK, таким образом становится проблематичным определить список файлов для упаковки (pkg-plist). Это одна из причин, по которой создателям портов настоятельно рекомендуется использовать макрос PORTDOCS. Более того, даже если вы сможете угадать набор файлов, который будет сгенерирован утилитой javadoc, размер получающегося файла pkg-plist голосует за использование PORTDOCS.

Значением по умолчанию для переменной DATADIR является ${PREFIX}/share/${PORTNAME}. Хорошей идеей является переопределение для Java-портов значения DATADIR как ${JAVASHAREDIR}/${PORTNAME}. На самом деле DATADIR автоматически добавляется к PLIST_SUB (это описано в Раздел 7.1, «Изменение содержимого pkg-plist в зависимости от make-переменных»), так что вы сможете использовать %%DATADIR%% непосредственно в pkg-plist.

Что касается выбора между построением портов Java из исходных текстов или их прямой установкой из бинарных дистрибутивов, то на момент создания этого текста определённой политики на этот счёт не существует. Однако участники Проекта FreeBSD Java рекомендуют создателям портов строить их из исходных текстов, если эта задача является несложной.

Все возможности, которые были описаны в этом разделе, реализованы в файле bsd.java.mk. Если вы предположите, что вашему порту требуется менее тривиальная поддержка Java, пожалуйста, взгляните сначала на журнал изменений bsd.java.mk в SVN, так как для документирования последних изменений требуется какое-то время. Затем, если вы думаете, что не хватающая вам поддержка окажется полезной для многих других портов Java, обсудите ваш вопрос в Список рассылки, посвящённый поддержке Java во FreeBSD.

Хотя в базе сообщений об ошибках для соответствующих PR имеется категория java, она относится к работе над портированием JDK, которые проводит Проект FreeBSD Java. Таким образом, вы должны относить свой Java-порт, как и любой другой, к категории ports, если решаемый вами вопрос не относится ни к реализации JDK, ни к bsd.java.mk.

Похожим образом определена политика по отношению к CATEGORIES порта Java, которая подробно описана в Раздел 5.3, «Разделение по категориям».

Веб-приложения следует устанавливать в PREFIX/www/appname. Для вашего удобства этот путь одинаково доступен в Makefile и pkg-plist как переменная WWWDIR, а путь относительно PREFIX доступен в Makefile как WWWDIR_REL.

Пользователь и группа процесса веб-сервера доступны как WWWOWN и WWWGRP, в случае если вам нужно изменить владельца для некоторых файлов. Значением по умолчанию и для владельца, и для группы является www. Если вы хотите использовать в вашем порте другие значения, воспользуйтесь для этого нотацией WWWOWN?= myuser, чтобы позволить пользователю легко переопределить их.

Не добавляйте зависимость от Apache, если веб-приложение явным образом не нуждается в Apache. Учитывайте, что пользователи могут пожелать запустить ваше веб-приложение на другом веб-сервере помимо Apache.

Портирование модулей PEAR является очень простым процессом.

Используйте переменные FILES, TESTS, DATA, SQLS, SCRIPTFILES, DOCS and EXAMPLES для перечисления файлов, которые вы хотите установить. Все перечисленные файлы будут автоматически установлены в подходящие места и добавлены в pkg-plist.

Подключите ${PORTSDIR}/devel/pear/bsd.pear.mk на последней строке Makefile.

PORTNAME=       Date
PORTVERSION=    1.4.3
CATEGORIES=     devel www pear

MAINTAINER=     example@domain.com
COMMENT=        PEAR Date and Time Zone Classes

BUILD_DEPENDS=  ${PEARDIR}/PEAR.php:${PORTSDIR}/devel/pear-PEAR
RUN_DEPENDS:=   ${BUILD_DEPENDS}

FILES=          Date.php Date/Calc.php Date/Human.php Date/Span.php     \
                Date/TimeZone.php
TESTS=          test_calc.php test_date_methods_span.php testunit.php   \
                testunit_date.php testunit_date_span.php wknotest.txt   \
                bug674.php bug727_1.php bug727_2.php bug727_3.php       \
                bug727_4.php bug967.php weeksinmonth_4_monday.txt       \
                weeksinmonth_4_sunday.txt weeksinmonth_rdm_monday.txt   \
                weeksinmonth_rdm_sunday.txt
DOCS=           TODO
_DOCSDIR=       .

.include <bsd.port.pre.mk>
.include "${PORTSDIR}/devel/pear/bsd.pear.mk"
.include <bsd.port.post.mk>

Существует множество версий библиотек wxWidgets, конфликтующих между собой (устанавливают файлы под тем же именем). В дереве портов эта проблема решена путем установки каждой версии под собственным названием с использованием номера версии в качестве суффикса.

Очевидным недостатком этого является необходимость изменения каждого приложения для нахождения искомой версии. К счастью, большинство приложений для определения нужного компилятора и флагов компоновки вызывают сценарий wx-config. Для каждой доступной версии этот сценарий имеет своё имя. Большинство приложений учитывают переменную окружения или принимают аргумент configure для указания, какой сценарий wx-config следует вызывать. На все остальные приходится накладывать патч.

Для того, чтобы заставить ваш порт использовать конкретную версию wxWidgets, существует две доступные для определения переменные (если определена только одна, то вторая примет значение по умолчанию):

Перечень доступных версий wxWidgets и соответствующих им портов в дереве:

Переменные в Таблица 6.23, «Переменные для выбора версии wxWidgets» можно установить в одну или более следующих комбинаций, разделенных пробелами:

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

Существуют другие приложения, которые, хотя и не являются библиотеками wxWidgets, но в тоже время относятся к ним. Эти приложения можно указать в переменной WX_COMPS. Доступны следующие компоненты:

Тип добавляемой зависимости при выборе каждого компонента может быть указан вручную путем добавления суффикса, отделенного точкой с запятой. Если таковой отсутствует, но будет использовано значение по умолчанию (смотрите Таблица 6.29, «Типы зависимости wxWidgets, используемые по умолчанию»). Доступные типы зависимости:

Значения по умолчанию для компонентов подробно рассматриваются в следующей таблице:

USE_WX=       2.4
WX_COMPS=     wx contrib

Библиотека wxWidgets поддерживает Unicode начиная с версии 2.5. В дереве портов доступны обе версии и могут быть выбраны с использованием следующих переменных:

Для обнаружения установленной версии вам необходимо задать переменную WANT_WX. Если вы не присвоите ей определенную версию, то компоненты получат суффикс версии. Переменная HAVE_WX будет заполнена после обнаружения.

WANT_WX=        yes

.include <bsd.port.pre.mk>

.if defined(WITH_WX) || !empty(PORT_OPTIONS:MWX) || !empty(HAVE_WX:Mwx-2.4)
USE_WX=         2.4
CONFIGURE_ARGS+=--enable-wx
.endif

USE_WX=         2.6
WX_COMPS=       wx
WANT_WX=        2.6

.include <bsd.port.pre.mk>

.if defined(WITH_WXPYTHON) || !empty(PORT_OPTIONS:MWXPYTHON) || !empty(HAVE_WX:Mpython)
WX_COMPS+=      python
CONFIGURE_ARGS+=--enable-wxpython
.endif

Следующие переменные доступны в порту (после определения одной из переменных из Таблица 6.23, «Переменные для выбора версии wxWidgets»).

Если вам нужно использовать переменные для запуска команд сразу после подключения bsd.port.pre.mk, то вам нужно определить WX_PREMK.

USE_WX=         2.4
WX_PREMK=       yes

.include <bsd.port.pre.mk>

.if exists(${WX_CONFIG})
VER_STR!=       ${WX_CONFIG} --release

PLIST_SUB+=     VERSION="${VER_STR}"
.endif

Некоторые сценарии GNU configure не могут найти wxWidgets только с установленной переменной окружения WX_CONFIG, требуя дополнительные параметры. Для их передачи можно использовать переменную WX_CONF_ARGS.

Существует множество версий библиотек Lua и соответствующих интерпретаторов, конфликтующих между собой (устанавливают файлы под тем же именем). В дереве портов эта проблема решена путем установки каждой версии в собственное место с использованием номера версии в качестве суффикса.

Очевидным недостатком этого является необходимость изменения каждого приложения для нахождения искомой версии. Но это решается добавлением некоторых дополнительных флагов для компилятора и компоновщика.

Для того, чтобы заставить ваш порт использовать конкретную версию Lua, существует две доступные для определения переменные (если определена только одна, то вторая примет значение по умолчанию):

Перечень доступных версий Lua и соответствующих портов в дереве:

Переменные из Таблица 6.33, «Переменные для выбора версии Lua» могут иметь комбинации из одного или нескольких значений, разделенных пробелом:

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

USE_LUA=      5.0-5.1
WANT_LUA_VER= 5.0

Существуют другие приложения, которые хотя и не являются библиотеками Lua, но относятся к ним. Эти приложения можно указать в переменной LUA_COMPS. Доступны следующие компоненты:

Тип зависимости можно выбрать для каждого компонента через добавление суффикса, отделенного точкой с запятой. В случае отсутствия будет использован тип по умолчанию (смотрите Таблица 6.39, «Типы зависимости Lua, используемые по умолчанию»). Доступные следующие типы:

Значения по умолчанию для компонентов подробно рассматриваются в следующей таблице:

USE_LUA=      4.0
LUA_COMPS=    lua ruby

Для обнаружения установленной версии вам необходимо задать переменную WANT_LUA. Если вы не присвоите ей определенную версию, то компоненты получат суффикс версии. Переменная HAVE_LUA будет заполнена после обнаружения.

WANT_LUA=       yes

.include <bsd.port.pre.mk>

.if defined(WITH_LUA5) || !empty(PORT_OPTIONS:MLUA5) || !empty(HAVE_LUA:Mlua-5.[01])
USE_LUA=        5.0-5.1
CONFIGURE_ARGS+=--enable-lua5
.endif

USE_LUA=        4.0
LUA_COMPS=      lua
WANT_LUA=       4.0

.include <bsd.port.pre.mk>

.if defined(WITH_TOLUA) || !empty(PORT_OPTIONS:MTOLUA) || !empty(HAVE_LUA:Mtolua)
LUA_COMPS+=     tolua
CONFIGURE_ARGS+=--enable-tolua
.endif

Следующие переменные доступны в порту (после определения одной из переменных из Таблица 6.33, «Переменные для выбора версии Lua»).

USE_LUA=        4.0
GNU_CONFIGURE=  yes
CONFIGURE_ENV=  CPPFLAGS="-I${LUA_INCDIR}" LDFLAGS="-L${LUA_LIBDIR}"

Если вам нужно использовать переменные для запуска команд сразу после подключения bsd.port.pre.mk, для этого вам нужно определить переменную LUA_PREMK.

USE_LUA=        5.0
LUA_PREMK=      yes

.include <bsd.port.pre.mk>

.if exists(${LUA_CMD})
VER_STR!=       ${LUA_CMD} -v

CFLAGS+=        -DLUA_VERSION_STRING="${VER_STR}"
.endif