Глава 6. Особые соглашения

Этот перевод может быть устаревшим. Для того, чтобы помочь с переводом, пожалуйста, обратитесь к Сервер переводов FreeBSD.

Содержание

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

6.1. Staging

bsd.port.mk ожидает от портов работу с "каталогом сборки". Это означает, что порт должен устанавливать файлы не напрямую в назначенные каталоги (то есть, например, под PREFIX), а в отдельный каталог, из которого затем собирается пакет. Во многих случаях привилегии root для этого не требуются, что делает возможным сборку пакетов из-под непривилегированного пользователя. В режиме staging порт собирается и устанавливается в каталог сборки STAGEDIR. Пакет создается из каталога сборки и затем устанавливается в систему. В инструментарии automake такая концепция именуется DESTDIR; в прочем, в FreeBSD DESTDIR имеет собственное значение (смотрите PREFIX и DESTDIR).

Если для порта всё ещё требуются системные привилегии при выполнении цели package, то в Makefile должна быть добавлена следующая строка:

NEED_ROOT=	yes

Метапорты, то есть порты, которые не устанавливают файлы непосредственно, а только зависят от других портов, должны по возможности избегать распаковки mtree(8) в каталог сборки. Это основная иерархия каталогов пакета, и эти пустые каталоги будут выглядеть лишними. Для предотвращения распаковки mtree(8) добавьте эту строку:

NO_MTREE=	yes

Staging задействуется посредством добавления переменной STAGEDIR слева от путей, которые используются в целях pre-install, do-install и post-install (смотрите примеры в книге). Обычно сюда относятся PREFIX, ETCDIR, DATADIR, EXAMPLESDIR, MANPREFIX, DOCSDIR и так далее. Каталоги должны создаваться при выполнении цели post-install. Избегайте использования абсолютных путей, когда это возможно.

При создании символический ссылки STAGEDIR должен ставиться только для пути назначения. Например:

${LN} -sf libfoo.so.42 ${STAGEDIR}${PREFIX}/lib/libfoo.so

Первоначальный путь ${PREFIX}/lib/libfoo.so.42 выглядит нормально, но по факту может быть неправильным. Абсолютные пути могут указывать на неподходящее место, например, когда удалённая файловая система смонтирована по NFS как непривилегированная точка монтирования. Относительные пути реже подвержены проблемам и часто намного короче.

Порты, устанавливающие модули ядра, должны предварять путь установки (по умолчанию /boot/modules) переменной STAGEDIR.

6.2. Динамические библиотеки

Если ваш порт устанавливает одну или несколько динамических библиотек, определите переменную USE_LDCONFIG, которая приведёт к запуску из bsd.port.mk команды ${LDCONFIG} -m относительно каталога, в который устанавливается новая библиотека (как правило, это PREFIX/lib), во время выполнения цели post-install для её регистрации в кэше динамических библиотек. Эта переменная, если она определена, также приведёт к добавлению соответствующей пары команд @exec /sbin/ldconfig -m и @unexec /sbin/ldconfig -R в ваш файл pkg-plist, так что пользователь, устанавливающий пакет, сможет сразу же использовать динамическую библиотеку, а удаление пакета не приведёт к тому, что система будет предполагать, что библиотека всё ещё имеется в наличии.

USE_LDCONFIG=	yes

Если нужно, вы можете переопределить каталог по умолчанию, задав значение USE_LDCONFIG, в котором должны быть перечислены каталоги, в которые устанавливаются динамические библиотеки. Например, если ваш порт устанавливает динамические библиотеки в каталоги PREFIX/lib/foo и PREFIX/lib/bar, то вы можете в файле Makefile указать следующее:

USE_LDCONFIG=	${PREFIX}/lib/foo ${PREFIX}/lib/bar

Будьте добры перепроверить, т.к. часто это вовсе не является необходимым и может быть решено иначе с помощью -rpath или установки LD_RUN_PATH во время компоновки (для примера смотрите lang/moscow_ml), или с помощью сценария-обёртки, который выставляет LD_LIBRARY_PATH перед запуском исполняемого файла как это делает www/seamonkey.

При установке 32-разрядных библиотек на 64-разрядной системе используйте вместо этого USE_LDCONFIG32.

Постарайтесь сохранять номера версий динамических библиотек в формате libfoo.so.0. Наш компоновщик позаботится только о старшем (первом) номере.

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

6.3. Порты с ограничениями на распространение или с правовым обременением

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

На вас, как на человека, портирующего приложение, ложится обязанность прочесть лицензионные соглашения на программное обеспечение и удостовериться, что проект FreeBSD не будет являться их нарушителем, если будет заниматься распространением исходного кода или в бинарном виде по FTP/HTTP или на CD-ROM. Если у вас возникли сомнения, то, пожалуйста, обратитесь в Список рассылки, посвящённый Портам FreeBSD.

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

6.3.1. `NO_PACKAGE`

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

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

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

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

6.3.2. `NO_CDROM`

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

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

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

6.3.3. `NOFETCHFILES`

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

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

6.3.4. `RESTRICTED`

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

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

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

6.3.5. `RESTRICTED_FILES`

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

6.3.6. `LEGAL_TEXT`

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

6.3.7. /usr/ports/LEGAL и `LEGAL`

Порт, содержащий любую из перечисленных выше переменных, также должен быть добавлен в /usr/ports/LEGAL. Первый столбец содержит шаблон совпадения с дистрибутивными файлами, имеющими ограничения на распространение. Второй столбец содержит корень порта. Третий столбец содержит вывод make -VLEGAL.

6.3.8. Примеры использования

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

.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.

6.4. Механизмы построения

6.4.1. Параллельное построение портов

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

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

6.4.2. `make`, `gmake` и `imake`

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

Таблица 1. Переменные для портов, использующих gmake
Переменная	Значение
`USES= gmake`	Для сборки порта требуется `gmake`.
`GMAKE`	Полный путь к команде `gmake`, если отсутствует в `PATH`.

Если ваш порт является приложением 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.

6.4.3. Сценарий `configure`

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

Таблица 2. Переменные для портов, использующих `configure`
Переменная	Значение
`GNU_CONFIGURE`	Порт использует сценарий `configure` для подготовки построения.
`HAS_CONFIGURE`	То же, что и `GNU_CONFIGURE`, кроме того, что цель configure по умолчанию не добавляется в `CONFIGURE_ARGS`.
`CONFIGURE_ARGS`	Дополнительные параметры, передаваемые сценарию `configure`.
`CONFIGURE_ENV`	Дополнительные переменные окружения, задаваемые для запуска сценария `configure`.
`CONFIGURE_TARGET`	Переопределить цель configure по умолчанию. Значением по умолчанию является `${MACHINE_ARCH}-portbld-freebsd${OSREL}`.

6.4.4. Использование `cmake`

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

Таблица 3. Переменные для портов, использующих `cmake`
Переменная	Значение
`CMAKE_ARGS`	Специфичные для порта флаги CMake, передаваемые `cmake`.
`CMAKE_BUILD_TYPE`	Тип построения (предопределённые профили построения CMake). По умолчанию `Release`, `Debug` при использовании `WITH_DEBUG`.
`CMAKE_ENV`	Переменные окружения для передачи `cmake`. По умолчанию `${CONFIGURE_ENV}`.
`CMAKE_SOURCE_PATH`	Путь к каталогу с исходным кодом. По умолчанию `${WRKSRC}`.

Таблица 4. Переменные построения `cmake`, устанавливаемые пользователем
Переменная	Значение
`CMAKE_VERBOSE`	Разрешает подробный вывод сообщений при построении. Значение по умолчанию не задано, если не заданы `BATCH` или `PACKAGE_BUILDING`.
`CMAKE_NOCOLOR`	Запрещает цветной вывод сообщений при построении. Значение по умолчанию не задано, если не заданы `BATCH` или `PACKAGE_BUILDING`.

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 для каталога, содержащего файлы, получаемые на этапах конфигурации и построения; при этом каталог с исходным кодом будет оставаться без изменений.

Пример 1. Пример для USES= cmake

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

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

6.4.5. Использование `scons`

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

Таблица 5. Переменные для портов, использующих `scons`
Переменная	Значение
`SCONS_ARGS`	Специфичные для порта флаги SCons, передаваемые окружению SCons.
`SCONS_BUILDENV`	Переменные для установки в системном окружении.
`SCONS_ENV`	Переменные для установки в окружении SCons.
`SCONS_TARGET`	Последний параметр для передачи SCons, похожий на `MAKE_TARGET`.

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

env = Environment(**ARGUMENTS)

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

6.5. Использование GNU Autotools

6.5.1. Введение

Различные инструменты 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.

6.5.2. `libtool`

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

USE_AUTOTOOLS=	libtool:version[:env]

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

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

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

6.5.3. `libltdl`

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

USE_AUTOTOOLS=	libltdl:version

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

6.5.4. `autoconf` и `autoheader`

Вместо сценария 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, большинству портов это вряд ли понадобится.

6.5.5. `automake` и `aclocal`

Некоторые пакеты содержат только файлы 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 порта.

6.6. Использование GNU `gettext`

6.6.1. Простой вариант использования

Если для вашего порта требуется gettext, добавьте USES= gettext, и ваш порт унаследует зависимость от devel/gettext. 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

6.6.2. Оптимальное использование

Некоторые программные продукты позволяют отключать 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

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

6.6.3. Управление каталогами сообщений

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

6.7. Использование Perl

Если MASTER_SITES установлена в значение MASTER_SITE_PERL_CPAN, то предпочтительным значением MASTER_SITE_SUBDIR является имя иерархии верхнего уровня. Например, рекомендуемым значением для p5-Module-Name является Module. Иерархию верхнего уровня можно посмотреть на сайте cpan.org. Это поддерживает порт в рабочем состоянии при изменении модуля автором.

Исключением этого правила является отсутствие соответствующего каталога или файла с дистрибутивом в этом каталоге. В качестве MASTER_SITE_SUBDIR в этом случае разрешается использовать id автора.

В качестве значения все из настраиваемых knobs ниже принимают YES или строку с версией вида 5.8.0+. YES означает, что данный порт можно использовать с любой из поддерживаемых версий Perl. Если порт работает только с некоторыми версиями Perl, то это можно обозначить при помощи строки с версией, указывающей на минимальную версию (пример: 5.7.3+), максимальную версию (пример: 5.8.0-) или точную версию (пример: 5.8.3).

Таблица 6. Переменные для портов, использующих Perl
Переменная	Значение
`USE_PERL5`	Perl 5 используется для построения и работы.
`USE_PERL5_BUILD`	Perl 5 используется для построения.
`USE_PERL5_RUN`	Perl 5 используется во время работы.
`PERL`	Полный путь к интерпретатору Perl 5, либо в системе, либо установленному из портов, но без номера версии. Используйте это, если вам нужно заменить строки “#!” в скриптах.
`PERL_CONFIGURE`	Конфигурация при помощи MakeMaker языка Perl. Влечёт `USE_PERL5`.
`PERL_MODBUILD`	Конфигурация, построение и установка с использованием Module::Build. Влечёт `PERL_CONFIGURE`.

Порты для модулей Perl, которые не имеют официального вебсайта, должны указывать cpan.org в строке WWW в файле pkg-descr. Предпочтительная форма URL http://search.cpan.org/dist/Module-Name/ (включая завершающий слэш).

Не используйте ${SITE_PERL} в объявлении зависимостей. Использование этой конструкции подразумевает наличие подключенного bsd.perl.mk, что не всегда так. Порты, зависимые от этого порта, получат неправильные зависимости, если файлы этого порта будут перемещены при последующем обновлении. Правильный способ объявления зависимостей для модулей Perl показан в примере ниже.

Пример 2. Пример зависимости Perl

p5-IO-Tee>=0.64:${PORTSDIR}/devel/p5-IO-Tee

Для портов Perl, которые устанавливают страницы справочника, в pkg-plist можно использовать макрос PERL5_MANx (где x принимает значение от 1 до 9). Например,

lib/perl5/5.14/man/man3/AnyEvent::I3.3.gz

можно заменить на

%%PERL5_MAN3%%/AnyEvent::I3.3.gz

6.8. Использование X11

6.8.1. Компоненты X.Org

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.

Пример 3. Пример для USE_XORG

USE_XORG=	xrender xft xkbfile xt xaw
USE_GL=		glu

Таблица 7. Переменные для портов, использующих X
`USES= imake`	Используется `imake`.
`XMKMF`	Задаёт маршрут до `xmkmf`, если он отсутствует в `PATH`. По умолчанию это `xmkmf -a`.

Пример 4. Использование переменных X11 в порте

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

6.8.2. Порты, которым требуется Motif

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

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

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

Если порт обращается к библиотеке Motif как -lXm в своих файлах Makefile или Imakefile, просто подставьте вместо этих обращений ${MOTIFLIB}.
Если порт использует XmClientLibs в своем файле Imakefile, измените это обращение на ${MOTIFLIB} ${XTOOLLIB} ${XLIB}.

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

6.8.3. Шрифты для X11

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

6.8.4. Получение поддельного `DISPLAY`, используя Xvfb

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

USES=	display

6.8.5. Элементы рабочего стола

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

6.8.5.1. Использование предопределенных файлов .desktop

Порты, включающие предопределенные файлы *.desktop, должны включать эти файлы в pkg-plist и устанавливать их в каталог $LOCALBASE/shared/applications. Для установки этих файлов используется макрос INSTALL_DATA.

6.8.5.2. Обновление базы данных рабочего стола

Если в файле порта portname.desktop имеется запись MimeType, то база данных рабочего стола олжна быть обновлена после установки и удаления. Для этого укажите USES= desktop-file-utils.

6.8.5.3. Создание элементов рабочего стола с использованием `DESKTOP_ENTRIES`

Элементы рабочего стола можно легко создавать для приложений, используя переменную DESKTOP_ENTRIES. Будет автоматически создан, установлен и добавлен в pkg-plist файл с названием name.desktop. Синтаксис:

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

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

Пример:

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

6.9. Использование GNOME

Для задания того, какие компоненты GNOME использует конкретный порт, проект FreeBSD/GNOME использует собственный набор переменных. На странице проекта FreeBSD/GNOME размещён исчерпывающий список этих переменных.

6.10. Использование Qt

6.10.1. Порты, для которых требуется Qt

Таблица 8. Переменные для портов, использующих Qt
`USE_QT4`	Указывает инструменты и библиотеки в качестве зависимостей для портов, которые используют Qt 4. Для получения подробностей смотрите выбор компонентов Qt 4.
`QT_PREFIX`	Устанавливается в значение, содержащее путь к установленному Qt (переменная только для чтения).
`MOC`	Устанавливается в значение, содержащее путь к `moc` (переменная только для чтения). По умолчанию устанавливается в соответствии со значением `USE_QT_VER`.
`QTCPPFLAGS`	Дополнительные флаги компилятора для инструментального пакета Qt, передаваемые через переменную `CONFIGURE_ENV`. По умолчанию устанавливается в соответствии со значением `USE_QT_VER`.
`QTCFGLIBS`	Дополнительные флаги компоновки для инструментального пакета Qt, передаваемые через переменную `CONFIGURE_ENV`. По умолчанию устанавливается в соответствии со значением `USE_QT_VER`.
`QTNONSTANDARD`	Подавляет изменение `CONFIGURE_ENV`, `CONFIGURE_ARGS`, `CPPFLAGS` и `MAKE_ENV`.

Таблица 9. Дополнительные переменные для портов, использующих Qt 4.x
`UIC`	Устанавливает путь к `uic` (переменная только для чтения).
`QMAKE`	Устанавливает путь к `qmake` (переменная только для чтения).
`QMAKESPEC`	Устанавливает путь к конфигурационному файлу для `qmake` (переменная только для чтения).
`QMAKEFLAGS`	Дополнительные флаги для `qmake`.
`QT_INCDIR`	Устанавливает каталоги для заголовков Qt 4 (переменная только для чтения).
`QT_LIBDIR`	Устанавливает путь к библиотекам Qt 4 (переменная только для чтения).
`QT_PLUGINDIRC`	Устанавливает путь к плагинам Qt 4 (переменная только для чтения).

При заданной переменной 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}

6.10.2. Выбор компонентов

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

Таблица 10. Доступные библиотечные компоненты Qt 4
Название	Описание
`corelib`	основная библиотека (можно опустить, если порт не использует ничего, кроме `corelib`)
`gui`	библиотека графического пользовательского интерфейса
`network`	сетевая библиотека
`opengl`	библиотека OpenGL
`qt3support`	библиотека совместимости с Qt 3
`qtestlib`	библиотека модульного тестирования
`script`	библиотека сценариев
`sql`	библиотека SQL
`xml`	библиотека XML

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

Таблица 11. Доступные компоненты инструментов Qt 4
Название	Описание
`moc`	мета-объектный компилятор (нужен при построении почти для каждого приложения Qt)
`qmake`	генератор Makefile / утилита построения
`rcc`	компилятор ресурсов (нужен, если приложение идет вместе с файлами .rc или .qrc)
`uic`	компилятор пользовательского интерфейса (нужен, если приложение идет вместе с файлами *.ui, созданными при помощи Qt Designer, - на практике каждое приложение Qt с GUI)

Таблица 12. Доступные компоненты плагинов Qt 4
Название	Описание
`iconengines`	плагин для движка иконок SVG (если приложение поставляется с иконками SVG)
`imageformats`	плагины для графических форматов GIF, JPEG, MNG и SVG (если приложение поставляется с графическими файлами)

Пример 5. Выбор компонентов Qt 4

В этом примере портированное приложение использует библиотеку графического пользовательского интерфейса Qt 4, основную библиотеку Qt 4, все инструменты генерации кода Qt 4 и генератор Makefile Qt 4. Поскольку библиотека gui подразумевает зависимость от основной библиотеки, указывать corelib нет необходимости. Инструменты генерации кода Qt 4 moc, uic и rcc, а также генератор Makefile qmake нужны только для времени построения, поэтому они указаны с суффиксом _build:

USE_QT4=	gui moc_build qmake_build rcc_build uic_build

6.10.3. Использование `qmake`

Таблица 13. Переменные для портов, использующих `qmake`
Название	Описание
`QMAKE_ARGS`	Спефицичные для порта флаги QMake для передачи программе `qmake`.
`QMAKE_ENV`	Переменные окружения, устанавливаемые для программы `qmake`. По умолчанию соответствует значению `${CONFIGURE_ENV}`.
`QMAKE_PRO`	Название файла проекта .pro. По умолчанию имеет пустое значение (с использованием автоопределения).

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

USES=	qmake
USE_QT4=	qmake_build

USES=qmake указывает порту на использование qmake в процессе конфигурации. Обратите внимание, что USES=qmake не подразумевает зависимость от Qt 4 qmake. Для этого в значении USE_QT4 должен присутствовать компонент qmake_build.

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

Отсутствующие дополнительные пути для заголовочных файлов. Многие приложения идут с поддержкой иконки в системном трее, но пренебрегают смотреть на наличие заголовочных файлов и/или библиотеками в каталогах X11. Вы можете сообщить qmake, чтобы она добавила каталоги в пути поиска заголовочных файлов и библиотек через командную строку. К примеру:
```
QMAKE_ARGS+= INCLUDEPATH+=${LOCALBASE}/include \
	LIBS+=-L${LOCALBASE}/lib
```
Фиктивные пути установки. Иногда данные, такие как иконки и файлы .desktop, устанавливаются по умолчанию в каталоги, которые не просматриваются XDG-совместимыми приложениями. Примером является editors/texmaker - взгляните на patch-texmaker.pro из каталога files этого порта, который можно взять в качестве шаблона исправления этого непосредственно в файле проекта qmake.

6.11. Использование KDE

6.11.1. Задание переменных KDE 4

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

Таблица 14. Доступные компоненты KDE 4
Название	Описание
`kdehier`	Иерархия основных каталогов KDE
`kdelibs`	KDE Developer Platform
`kdeprefix`	Если установлено, то порт будет установлен в `${KDE4_PREFIX}` вместо `${LOCALBASE}`
`sharedmime`	База данных MIME типов для портов KDE
`automoc4`	automoc для пакетов Qt 4
`akonadi`	Сервер хранения KDE-Pim
`soprano`	Фреймворк Qt 4 RDF
`strigi`	Поисковые даемон рабочего стола
`libkcddb`	Библиотека KDE CDDB
`libkcompactdisc`	Библиотека KDE для взаимодействия с аудио-CD
`libkdeedu`	Библиотеки, используемые для образовательных приложений
`libkdcraw`	Библиотека KDE LibRaw
`libkexiv2`	Библиотека KDE Exiv2
`libkipi`	KDE Image Plugin Interface
`libkonq`	Основная библиотека Konqueror
`libksane`	Библиотека KDE SANE ("Scanner Access Now Easy")
`pimlibs`	Библиотеки KDE-Pim
`kate`	Тектовый редактор
`marble`	Виртуальный глобус
`okular`	Универсальный просмотрщик документов
`korundum`	Привязка Ruby к KDE
`perlkde`	Привязка Perl к KDE
`pykde4`	Привязка Python к KDE
`pykdeuic4`	Компилятор пользовательского интерфейса PyKDE
`smokekde`	Библиотеки KDE SMOKE

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

Пример 6. Пример USE_KDE4

Это простой пример для порта KDE 4. USES= cmake:outsource указывает порту использовать CMake, конфигурационный инструмент, широко применяемый в проектах KDE 4 (подробное описание даёт Использование cmake). USE_KDE4 добавляет зависимость от библиотек KDE и заставляет порты использовать automoc4 во время сборки. Требуемые компоненты KDE и другие зависимости можно определить в журнале configure. USE_KDE4 не подразумевает USE_QT4. Если порт требует какой-либо из компонентов Qt 4, их следует указать в USE_QT4.

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

6.12. Использование Java

6.12.1. Задание переменных

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

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

Таблица 15. Переменные, которые которые могут задаваться портами, использующими Java
Переменная	Значение
`USE_JAVA`	Должна быть определена для того, что последующие переменные вступили в действие.
`JAVA_VERSION`	Список версий Java, перечисленных через пробел, подходящих для порта. Опциональный знак ""` позволяет вам указать диапазон версий (возможные значения: `1.5[] 1.6[] 1.7[]).
`JAVA_OS`	Список операционных систем, перечисленных через пробел, порты JDK для которых подходят для порта (возможные значения: `native linux`).
`JAVA_VENDOR`	Список разработчиков портов JDK, перечисленных через пробел, которые подходят для порта (возможные значения: `freebsd bsdjava sun openjdk`).
`JAVA_BUILD`	Если задана, то означает, что выбранный порт JDK должен быть добавлен к зависимостям порта для его построения.
`JAVA_RUN`	Если задана, то означает, что выбранный порт JDK должен быть добавлен в зависимостям порта для его работы.
`JAVA_EXTRACT`	Если задана, то означает, что выбранный порт JDK должен быть добавлен в зависимостям порта для распаковки его дистрибутивных файлов.

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

Таблица 16. Переменные, доступные в портах, использующих Java
Переменная	Значение
`JAVA_PORT`	Название порта JDK (к примеру, `'java/openjdk6'`).
`JAVA_PORT_VERSION`	Полное наименовании версии порта JDK (к примеру, `'1.6.0'`). Если вам нужны только первые две цифры номера версии, используйте `${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/}`.
`JAVA_PORT_OS`	Операционная система, используемая портом JDK (к примеру, `'native'`).
`JAVA_PORT_VENDOR`	Разработчик порта JDK (к примеру, `'openjdk'`).
`JAVA_PORT_OS_DESCRIPTION`	Описание операционной системы, используемой портом JDK (к примеру, `'Native'`).
`JAVA_PORT_VENDOR_DESCRIPTION`	Описание разработчика порта JDK (к примеру, `'OpenJDK BSD Porting Team'`).
`JAVA_HOME`	Маршрут к установочному каталогу JDK (к примеру, '/usr/local/openjdk6').
`JAVAC`	Маршрут к используемому компилятору Java (к примеру, '/usr/local/openjdk6/bin/javac'.
`JAR`	Маршрут к используемой утилите `jar` (к примеру, '/usr/local/openjdk6/bin/jar' или '/usr/local/bin/fastjar').
`APPLETVIEWER`	Маршрут к утилите `appletviewer` (к примеру, '/usr/local/openjdk6/bin/appletviewer').
`JAVA`	Маршрут к выполняемому файлу `java`. Используйте его для запуска Java-программ (к примеру, '/usr/local/openjdk6/bin/java').
`JAVADOC`	Маршрут к вспомогательной программе `javadoc`.
`JAVAH`	Маршрут к программе `javah`.
`JAVAP`	Маршрут к программе `javap`.
`JAVA_KEYTOOL`	Маршрут к вспомогательной программе `keytool`.
`JAVA_N2A`	Маршрут к утилите `native2ascii`.
`JAVA_POLICYTOOL`	Маршрут к программе `policytool`.
`JAVA_SERIALVER`	Маршрут к вспомогательной программе `serialver`.
`RMIC`	Маршрут к генератору каркаса программ RMI, утилите `rmic`.
`RMIREGISTRY`	Маршрут к программе регистрации RMI, `rmiregistry`.
`RMID`	Маршрут к программе-даемону RMI `rmid`.
`JAVA_CLASSES`	Маршрут к архиву, который содержит файлы классов JDK, ${JAVA_HOME}/jre/lib/rt.jar.

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

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

Таблица 17. Константы, определённые для портов, использующих Java
Константа	Значение
`JAVASHAREDIR`	Корневой каталог для всего, что связано с Java. По умолчанию: ${PREFIX}/shared/java.
`JAVAJARDIR`	Каталог, в который должны устанавливаться JAR-файлы. По умолчанию: ${JAVASHAREDIR}/classes.
`JAVALIBDIR`	Каталог, в который устанавливаются JAR-файлы из других портов. По умолчанию: ${LOCALBASE}/shared/java/classes.

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

6.12.2. Построение с Ant

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

6.12.3. Практические рекомендации

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

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

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

При портировании приложения Java™, для запуска сервиса которого требуется сервер приложений, такой как www/tomcat7, для производителя в порядке вещей является распространение файла .war. Файл .war - это Веб-приложение АРхивированное и оно распаковывается при вызове данным приложением. Избегайте добавлять файлы .war в pkg-plist. Это не является наилучшим решением. Сервер приложений производит расширение архива war без должной его очистки при удалении порта. Более подходящим способом работы с этим файлом будет распаковать архив, установить файлы и добавить их в pkg-plist.

TOMCATDIR=	${LOCALBASE}/apache-tomcat-7.0
WEBAPPDIR=	myapplication

post-extract:
	@${MKDIR} ${WRKDIR}/${PORTDIRNAME}
	@${TAR} xf ${WRKDIR}/myapplication.war -C ${WRKDIR}/${PORTDIRNAME}

do-install:
	cd ${WRKDIR} && \
	${INSTALL} -d -o ${WWWOWN} -g ${WWWGRP} ${TOMCATDIR}/webapps/${PORTDIRNAME}
	@cd ${WRKDIR}/${PORTDIRNAME} && ${COPYTREE_SHARE} \* ${WEBAPPDIR}/${PORTDIRNAME}

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

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

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

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

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

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

6.13. Веб-приложения, Apache и PHP

6.13.1. Apache

Таблица 18. Переменные для портов, использующих Apache
`USE_APACHE`	Порт требует Apache. Возможные значения: `yes` (берёт любую версию), `22`, `24`, `22-24`, `22+` и так далее. Версия по умолчанию `22`. Более подробная информация содержится в файле ports/Mk/bsd.apache.mk и на странице wiki.freebsd.org/Apache/.
`APXS`	Полный путь к исполняемому файлу `apxs`. Может быть переопределен в вашем порту.
`HTTPD`	Полный путь к исполняемому файлу `httpd`. Может быть переопределен в вашем порту.
`APACHE_VERSION`	Версия установленного Apache (переменная только для чтения). Эта переменная доступна только после подключения bsd.port.pre.mk. Возможные значения: `22`, `24`.
`APACHEMODDIR`	Каталог для модулей Apache. Значение переменной автоматически подставляется в pkg-plist.
`APACHEINCLUDEDIR`	Каталог для заголовков Apache. Значение переменной автоматически подставляется в pkg-plist.
`APACHEETCDIR`	Каталог для конфигурационных файлов Apache. Значение переменной автоматически подставляется в pkg-plist.

Таблица 19. Используемые переменные при портировании модулей Apache
`MODULENAME`	Название модуля. Значением по умолчанию является `PORTNAME`. Пример: `mod_hello`
`SHORTMODNAME`	Краткое название модуля. Наследуется автоматически от `MODULENAME`, но может быть переопределено. Пример: `hello`
`AP_FAST_BUILD`	Использовать `apxs` для компиляции и установки модуля.
`AP_GENPLIST`	Также автоматически создает pkg-plist.
`AP_INC`	Добавляет каталог к пути поиска заголовков во время компиляции.
`AP_LIB`	Добавляет каталог к пути поиска библиотек во время компиляции.
`AP_EXTRAS`	Дополнительные флаги, передаваемые `apxs`.

6.13.2. Веб-приложения

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

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

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

6.13.3. PHP

Таблица 20. Переменные для портов, использующих PHP
`USE_PHP`	Порт требует PHP. Значение `yes` добавляет зависимость от PHP. Вместо этого может быть указан перечень требуемых расширений PHP. Пример: `pcre xml gettext`
`DEFAULT_PHP_VER`	Выбирает старший номер версии, с которым будет установлен PHP как зависимость в случае, когда PHP еще не установлен. По умолчанию `5`. Возможные значения: `4`, `5`
`IGNORE_WITH_PHP`	Порт не работает с PHP данной версии. Возможные значения: `4`, `5`
`USE_PHPIZE`	Порт будет построен как расширение PHP.
`USE_PHPEXT`	Порт будет считаться расширением PHP, включая установку и регистрацию в реестре расширений.
`USE_PHP_BUILD`	Установить PHP как зависимость времени построения.
`WANT_PHP_CLI`	Хочет CLI (командная строка) версию PHP.
`WANT_PHP_CGI`	Хочет CGI версию PHP.
`WANT_PHP_MOD`	Хочет PHP как модуль Apache.
`WANT_PHP_SCR`	Хочет CLI или CGI версию PHP.
`WANT_PHP_WEB`	Хочет модуль Apache или CGI версию PHP.

6.13.4. Модули PEAR

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

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

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

Пример 7. Пример Makefile для классов PEAR

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>

6.14. Использование Python

Коллекция Портов поддерживает параллельную установку множества версий Python. Следует убедиться, что в портах используется правильный интерпретатор python в соответствии с переменной PYTHON_VERSION, установленной пользователем. По большей части это означает замену пути к исполняемому файлу python в сценариях на значение переменной PYTHON_CMD.

Порты, устанавливающие файлы под каталог PYTHON_SITELIBDIR, должны использовать префикс вида pyXY-, таким образом названия пакетов будут включать в себя версию Python, с которой они установлены.

PKGNAMEPREFIX=	${PYTHON_PKGNAMEPREFIX}

Таблица 21. Переменные для портов, которые используют Python
`USE_PYTHON`	Для этого порта нужен Python. Минимальная требуемая версия может быть указана с таким значением как `2.6+`. Также можно указан диапазон версий с разделением двух версий через -, например: `2.6-2.7`
`USE_PYDISTUTILS`	Использовать дистрибутивные утилиты (distutils) Python для конфигурации, компиляции и установки. Необходимо, если порт использует setup.py. Переопределяет цели `do-build` и `do-install` и также может переопределять `do-configure`, если не определена `GNU_CONFIGURE`.
`PYTHON_PKGNAMEPREFIX`	Используется как `PKGNAMEPREFIX` для отличия пакетов, использующих разные версии Python. Пример: `py24-`
`PYTHON_SITELIBDIR`	Местонахождение дерева site-packages, которое содержит путь установки Python (обычно, `LOCALBASE`). Переменная `PYTHON_SITELIBDIR` может быть очень полезной при установке модулей Python.
`PYTHONPREFIX_SITELIBDIR`	Вариант PYTHON_SITELIBDIR без PREFIX. По возможности всегда используйте `%%PYTHON_SITELIBDIR%%` в pkg-plist. Значением по умолчанию для `%%PYTHON_SITELIBDIR%%` является `lib/python%%PYTHON_VERSION%%/site-packages`.
`PYTHON_CMD`	Командная строка интерпретатора Python, включая номер версии.
`PYNUMERIC`	Строка зависимости для расширения numeric.
`PYNUMPY`	Строка зависимости для нового расширения numeric, numpy (PYNUMERIC объявлен устаревшим вышестоящим производителем).
`PYXML`	Строка зависимости для расширения XML (не нужно для Python 2.0 и выше, т.к. включено в основной дистрибутив).

Полный перечень доступных переменных можно найти в /usr/ports/Mk/bsd.python.mk.

Некоторые приложения на Python заявляют о поддержке DESTDIR (требуется для staging), которая не работает (в частности, у Mailman до версии 2.1.16). Ограничение можно обойти путём перекомпиляции сценариев. Например, это можно выполнить в цели post-build. С учётом того, что после установки предполагаемое место размещения сценариев Python будет находиться в PYTHONPREFIX_SITELIBDIR, можно применить следующее решение:

(cd ${STAGEDIR}${PREFIX} \
  && ${PYTHON_CMD} ${PYTHON_LIBDIR}/compileall.py \
   -d ${PREFIX} -f ${PYTHONPREFIX_SITELIBDIR:S;${PREFIX}/;;})

Эта команда перекомпилирует исходный текст с заменой путей на относительные к каталогу сборки, а также дописывает значение PREFIX перед именем файла, записанного в выходном файле с промежуточным представлением, с использованием -d. -f требуется для безусловной перекомпиляции, :S;${PREFIX}/;; удаляет префиксы из значения переменной PYTHONPREFIX_SITELIBDIR, чтобы сделать его относительным к PREFIX.

Для этого требуется Python 2.7 или выше. Это не работает с Python 2.6.

6.15. Использование Tcl/Tk

В Коллекции Портов поддерживается одновременная установка множественных версий Tcl/Tk. Порты должны пытаться поддерживать по крайней мере версию Tcl/Tk, используемую по умолчанию, и выше с помощью переменных USE_TCL и USE_TK. Желаемую версию tcl можно указать в переменной WITH_TCL_VER.

Таблица 22. Наиболее востребованные переменные для портов, которые используют Tcl/Tk
`USE_TCL`	Порт зависит от библиотеки Tcl (не оболочки). Минимальную требуемую версию можно указать с использованием таких значений, как 84+. Отдельные неподдерживаемые версии указываются в переменной `INVALID_TCL_VER`.
`USE_TCL_BUILD`	Tcl нужен для порта только на время сборки.
`USE_TCL_WRAPPER`	Эту новую переменную следует использовать для портов, для которых требуется оболочка Tcl и не требуется конкретная версия `tclsh`. Обертка `tclsh` устанавливается в систему. Пользователь может указать желаемую оболочку `tcl` для использования.
`WITH_TCL_VER`	Определяемые пользователем переменные, которые устанавливают желаемую версию Tcl.
`UNIQUENAME_WITH_TCL_VER`	Подобно `WITH_TCL_VER`, но для каждого порта.
`USE_TCL_THREADS`	Требует многопоточную сборку Tcl/Tk.
`USE_TK`	Порт зависит от библиотеки Tk (не от предпочитаемой оболочки). Подразумевает `USE_TCL` с тем же значением. Для большей информации смотрите описание переменной `USE_TCL`.
`USE_TK_BUILD`	Аналогично `USE_TCL_BUILD`.
`USE_TK_WRAPPER`	Аналогично `USE_TCL_WRAPPER`.
`WITH_TK_VER`	Аналогично `WITH_TCL_VER`, подразумевает `WITH_TCL_VER` той же версии.

Полный перечень доступных переменных находится в /usr/ports/Mk/bsd.tcl.mk.

6.16. Использование Emacs

Этот раздел ещё предстоит написать.

6.17. Использование Ruby

Таблица 23. Полезные переменные для портов, использующих Ruby
Переменная	Описание
`USE_RUBY`	Порт требует Ruby.
`USE_RUBY_EXTCONF`	Порт использует для конфигурации extconf.rb.
`USE_RUBY_SETUP`	Порт использует для конфигурации setup.rb.
`RUBY_SETUP`	Устанавливает альтернативное имя для setup.rb. Распространенным значением является install.rb.

Следующая таблица отражает некоторые переменные, доступные авторам портов через инфраструктуру портов. Эти переменные должны использоваться для установки файлов в правильное месторасположение. Используйте их в pkg-plist как можно больше. Эти переменные не должны переопределяться в самом порте.

Таблица 24. Отобранные переменные только для чтения для портов, использующих Ruby
Переменная	Описание	Примерное значение
`RUBY_PKGNAMEPREFIX`	Используется как `PKGNAMEPREFIX` для различия пакетов от разных версий Ruby.	`ruby18-`
`RUBY_VERSION`	Полная версия Ruby в форме `x.y.z`.	`1.8.2`
`RUBY_SITELIBDIR`	Путь для установки архитектуронезависимых библиотек.	`/usr/local/lib/ruby/site_ruby/1.8`
`RUBY_SITEARCHLIBDIR`	Путь для установки архитектурозависимых библиотек.	`/usr/local/lib/ruby/site_ruby/1.8/amd64-freebsd6`
`RUBY_MODDOCDIR`	Путь для установки документации модуля.	`/usr/local/shared/doc/ruby18/patsy`
`RUBY_MODEXAMPLESDIR`	Путь для установки примеров модуля.	`/usr/local/shared/examples/ruby18/patsy`

Полный перечень доступных переменных находится в /usr/ports/Mk/bsd.ruby.mk.

6.18. Использование SDL

Переменная USE_SDL используется для автоматической настройки зависимостей для портов, использующих библиотеки на основе SDL, такие как devel/sdl12 или graphics/sdl_image.

Для версии 1.2 на данный момент распознаются следующие SDL-библиотеки:

Для версии 2.0 на данный момент распознаются следующие SDL-библиотеки:

Таким образом, если порт имеет зависимость от net/sdl_net и audio/sdl_mixer, то строка будет следующей:

USE_SDL=	net mixer

Зависимость от порта devel/sdl12, который требуется для net/sdl_net и audio/sdl_mixer, будет также автоматически добавлен.

Если вы используете USE_SDL с элементами SDL 1.2, то он автоматически:

Добавляет зависимость от sdl12-config к BUILD_DEPENDS
Добавляет переменную SDL_CONFIG к CONFIGURE_ENV
Добавляет зависимости от указанных библиотек к LIB_DEPENDS

Если вы используете USE_SDL с элементами SDL 2.0, то он автоматически:

Добавляет зависимость от sdl2-config к BUILD_DEPENDS
Добавляет переменную SDL2_CONFIG к CONFIGURE_ENV
Добавляет зависимости от указанных библиотек к LIB_DEPENDS

Для проверки наличия библиотеки SDL вы можете делать это при помощи переменной WANT_SDL:

WANT_SDL=	yes

.include <bsd.port.pre.mk>

.if ${HAVE_SDL:Mmixer}!=""
USE_SDL+=	mixer
.endif

.include <bsd.port.post.mk>

6.19. Использование wxWidgets

Эта глава описывает статус библиотек wxWidgets в дереве портов и их интеграцию с системой портов.

6.19.1. Введение

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

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

6.19.2. Выбор версии

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

Таблица 25. Переменные для выбора версии wxWidgets
Переменная	Описание	Значение по умолчанию
`USE_WX`	Перечень версий, которые порт может использовать	Все доступные версии
`USE_WX_NOT`	Перечень версий, которые порт не может использовать	Нет

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

Таблица 26. Доступные версии wxWidgets
Версия	Порт
`2.4`	x11-toolkits/wxgtk24
`2.6`	x11-toolkits/wxgtk26
`2.8`	x11-toolkits/wxgtk28

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

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

Таблица 27. Определение версии для wxWidgets
Описание	Пример
Единичная версия	`2.4`
Восходящий диапазон	`2.4+`
Нисходящий диапазон	`2.6-`
Полный диапазон (обязан быть восходящим)	`2.4-2.6`

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

Таблица 28. Переменные для выбора предпочитаемых версий wxWidgets
Название	Предназначение
`WANT_WX_VER`	порт
`WITH_WX_VER`	пользователь

6.19.3. Выбор компонентов

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

Таблица 29. Доступные компоненты wxWidgets
Название	Описание	Ограничение версии
`wx`	основная библиотека	нет
`contrib`	сторонние библиотеки	`нет`
`python`	wxPython (привязки к Python)	`2.4-2.6`
`mozilla`	wxMozilla	`2.4`
`svg`	wxSVG	`2.6`

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

Таблица 30. Доступные типы зависимости wxWidgets
Название	Описание
`build`	Компонент требуется для построения, эквивалентен `BUILD_DEPENDS`
`run`	Компонент требуется для запуска, эквивалентен `RUN_DEPENDS`
`lib`	Компонент требуется для построения и запуска, эквивалентен `LIB_DEPENDS`

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

Таблица 31. Типы зависимости wxWidgets, используемые по умолчанию
Компонент	Тип зависимости
`wx`	`lib`
`contrib`	`lib`
`python`	`run`
`mozilla`	`lib`
`svg`	`lib`

Пример 8. Выбор компонентов wxWidgets

Следующий фрагмент относится к порту, в котором используется wxWidgets версии 2.4 с его сторонними библиотеками.

USE_WX=		2.4
WX_COMPS=	wx contrib

6.19.4. Unicode

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

Таблица 32. Переменные для выбора версии wxWidgets с Unicode
Переменная	Описание	Предназначение
`WX_UNICODE`	Порт работает только с версией Unicode	порт
`WANT_UNICODE`	Порт работает с обеими версиями, но предпочитает версию с Unicode	порт
`WITH_UNICODE`	Порт будет использовать версию Unicode	пользователь
`WITHOUT_UNICODE`	Порт будет использовать обычную версию, если это поддерживается (когда `WX_UNICODE` не определена)	пользователь

Не используйте WX_UNICODE для портов, которые могут использовать обе версии. Если вы хотите, чтобы порт по умолчанию использовал Unicode, определите вместо этого WANT_UNICODE.

6.19.5. Обнаружение установленных версий

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

Пример 9. Обнаружение установленных версий и компонентов wxWidgets

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

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

Следующий фрагмент может быть использован в порту, который задействует поддержку wxPython, в случае если он установлен или выбран соответствующий параметр, в дополнение к wxWidgets, обе версии 2.6.

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.19.6. Переменные для определения

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

Таблица 33. Переменные, определенные для портов, использующих wxWidgets
Название	Описание
`WX_CONFIG`	Путь к сценарию wxWidgets `wx-config` (с другим именем)
`WXRC_CMD`	Путь к программе wxWidgets `wxrc` (с другим именем)
`WX_VERSION`	Версия wxWidgets, которая будет использоваться (например, `2.6`)
`WX_UNICODE`	Если не определена, но Unicode будет использоваться, то она будет определена

6.19.7. Обработка в bsd.port.pre.mk

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

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

Пример 10. Использование переменных wxWidgets в командах

Следующий фрагмент иллюстрирует использование переменной WX_PREMK посредством запуска сценария wx-config для получения строки с полной версией с присвоением ее переменной и передачей в программу.

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

Переменные wxWidgets можно безопасно использовать в командах внутри целей без необходимости в использовании WX_PREMK.

6.19.8. Дополнительные параметры `configure`

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

Таблица 34. Допустимые значения `WX_CONF_ARGS`
Возможное значение	Получаемый параметр
`absolute`	`--with-wx-config=${WX_CONFIG}`
`relative`	`--with-wx=${LOCALBASE} --with-wx-config=${WX_CONFIG:T}`

6.20. Использование Lua

Эта глава описывает статус библиотек Lua в дереве портов и их интеграцию в систему портов.

6.20.1. Введение

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

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

6.20.2. Выбор версии

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

Таблица 35. Переменные для выбора версии Lua
Переменная	Описание	Значение по умолчанию
`USE_LUA`	Перечень версий, которые порт может использовать	Все доступные версии
`USE_LUA_NOT`	Перечень версий, которые порт не может использовать	Пусто

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

Таблица 36. Доступные версии Lua
Версия	Порт
`4.0`	lang/lua4
`5.0`	lang/lua50
`5.1`	lang/lua

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

Таблица 37. Определение версии Lua
Описание	Пример
Единичная версия	`4.0`
Восходящий диапазон	`5.0+`
Нисходящий диапазон	`5.0-`
Полный диапазон (обязан быть восходящим)	`5.0-5.1`

Таблица 38. Переменные для выбора предпочитаемых версий Lua
Название	Предназначение
`WANT_LUA_VER`	порт
`WITH_LUA_VER`	пользователь

Пример 11. Выбор версии Lua

Следующий фрагмент взят из порта, который использует Lua версий 5.0 или 5.1, по умолчанию 5.0. Значение может быть переопределено пользователем с использованием переменной WITH_LUA_VER.

USE_LUA=	5.0-5.1
WANT_LUA_VER=	5.0

6.20.3. Выбор компонентов

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

Таблица 39. Доступные компоненты Lua
Название	Описание	Ограничение версии
`lua`	Основная библиотека	нет
`tolua`	Библиотека доступа к коду C/C++	4.0-5.0
`ruby`	Привязка к Ruby	4.0-5.0

Есть и другие компоненты, но они относятся к модулям для интерпретатора и не используются приложениями (только другими модулями).

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

Таблица 40. Доступные типы зависимости Lua
Название	Описание
`build`	Компонент требуется для построения, эквивалентен `BUILD_DEPENDS`
`run`	Компонент требуется для запуска, эквивалентен `RUN_DEPENDS`
`lib`	Компонент требуется для построения и запуска, эквивалентен `LIB_DEPENDS`

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

Таблица 41. Типы зависимости Lua, используемые по умолчанию
Компонент	Тип зависимости
`lua`	`lib` для `4.0-5.0` (динамическая) и `build` для `5.1` (статическая)
`tolua`	`build` (статическая)
`ruby`	`lib` (динамическая)

Пример 12. Выбор компонентов Lua

Следующий фрагмент соответствует порту, использующему Lua версии 4.0 и привязку к Ruby.

USE_LUA=	4.0
LUA_COMPS=	lua ruby

6.20.4. Обнаружение установленных версий

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

Пример 13. Обнаружение установленных версий и компонентов Lua

Следующий фрагмент можно использовать для порта, использующего 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

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

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.20.5. Переменные для определения

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

Таблица 42. Переменные, определенные для портов, использующих Lua
Название	Описание
`LUA_VER`	Версия Lua, которая будет использоваться (например, `5.1`)
`LUA_VER_SH`	Старший номер версии динамической библиотеки Lua (например, `1`)
`LUA_VER_STR`	Версия Lua без точки (например, `51`)
`LUA_PREFIX`	Префикс, в который установлена Lua (и компоненты)
`LUA_SUBDIR`	Каталог под ${PREFIX}/bin, ${PREFIX}/share и ${PREFIX}/lib, в который установлена Lua
`LUA_INCDIR`	Каталог, в который установлены заголовочные файлы Lua и tolua
`LUA_LIBDIR`	Каталог, в который установлены библиотеки Lua и tolua
`LUA_MODLIBDIR`	Каталог, в который установлены модули библиотеки Lua (.so)
`LUA_MODSHAREDIR`	Каталог, в который установлены модули Lua (.lua)
`LUA_PKGNAMEPREFIX`	Префикс с именем пакета, используемый модулями Lua
`LUA_CMD`	Путь к интерпретатору Lua
`LUAC_CMD`	Путь к компилятору Lua
`TOLUA_CMD`	Путь к программе tolua

Пример 14. Указание для порта, где искать Lua

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

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

6.20.6. Обработка в bsd.port.pre.mk

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

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

Пример 15. Использование переменных Lua в командах

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

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

Переменные Lua можно безопасно использовать в командах внутри целей без необходимости в использовании LUA_PREMK.

6.21. Использование `iconv`

После 10-08-2013 (r254273) в составе FreeBSD 10-CURRENT и более новых версий имеется собственный iconv. В более ранних версиях дополнительной зависимостью выступал converters/libiconv.

Для программного обеспечения, которому нужен iconv, определите USES=iconv. Версии FreeBSD до 10-CURRENT от 13-08-2013 (r254273) не имеют собственного iconv. На этих более ранных версиях будет автоматически добавлена зависимость от converters/libiconv.

Когда порт задаёт USES=iconv, становятся доступными следующие переменные:

Имя переменной Назначение Значение до FreeBSD 10-CURRENT 254273 (13-08-2013) Значение после FreeBSD 10-CURRENT 254273 (13-08-2013)

ICONV_CMD

Каталог размещения двоичного файла iconv

${LOCALBASE}/bin/iconv

/usr/bin/iconv

ICONV_LIB

Аргумент ld для компоновки с libiconv (если нужно)

-liconv

(пусто)

ICONV_PREFIX

Каталог размещения реализации iconv (используется для сценариев конфигурации)

${LOCALBASE}

/usr

ICONV_CONFIGURE_ARG

Параметр предварительно собранной конфигурации для сценариев конфигурации

--with-libiconv-prefix=${LOCALBASE}

(пусто)

ICONV_CONFIGURE_BASE

Параметр предварительно собранной конфигурации для сценариев конфигурации

--with-libiconv=${LOCALBASE}

(пусто)

В следующих двух примерах демонстрируется автоматическое присвоение переменным правильных значений для систем, использующих converters/libiconv или собственный iconv.

Пример 16. Простое использование iconv

USES=		iconv
LDFLAGS+=	-L${LOCALBASE}/lib ${ICONV_LIB}

Пример 17. Использование iconv с configure

USES=		iconv
CONFIGURE_ARGS+=${ICONV_CONFIGURE_ARG}

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

Иногда в программе параметр ld или путь поиска жёстко заданы в Makefile или сценарии конфигурации. Для решения этой проблемы можно использовать следующий подход:

Пример 18. Исправление жёстко заданного -liconv

USES=		iconv

post-patch:
	@${REINPLACE_CMD} -e 's/-liconv/${ICONV_LIB}/' ${WRKSRC}/Makefile

В некоторых случаях необходимо установить альтернативные значения или выполнить операции в случае использования собственного iconv. Перед проверкой значения ICONV_LIB обязан быть подключён bsd.port.pre.mk:

Пример 19. Проверка доступности собственного iconv

USES=		iconv

.include <bsd.port.pre.mk>

post-patch:
.if empty(ICONV_LIB)
	# обнаружен собственный iconv
	@${REINPLACE_CMD} -e 's|iconv||' ${WRKSRC}/Config.sh
.endif

.include <bsd.port.post.mk>

6.22. Использование Xfce

Переменная USE_XFCE используется для автоматической конфигурации зависимостей для портов, использующих библиотеки или приложения на основе Xfce, такие как x11-toolkits/libxfce4gui и x11-wm/xfce4-panel.

В настоящее время распознаются следующие библиотеки и приложения Xfce:

Распознаются следующие дополнительные параметры:

configenv: Используйте, если ваш порт требует специально измененного значения CONFIGURE_ENV для поиска требуемых для порта библиотек.
```
-I${LOCALBASE}/include -L${LOCALBASE}/lib
```
добавляется в CPPFLAGS к CONFIGURE_ENV.

Следовательно, если у порта имеется зависимость от sysutils/xfce4-mcs-manager, и порт требует специальных CPPFLAGS в своем окружении configure, то синтаксис будет следующим:

USE_XFCE=	mcsmanager configenv

6.23. Использование Mozilla

Таблица 43. Переменные для портов, использующих Mozilla
`USE_GECKO`	Один из бэкэндов Gecko, с которым может работать порт. Возможные значения: `libxul` (libxul.so), `seamonkey` (libgtkembedmoz.so, устаревший, больше не должен использоваться).
`USE_FIREFOX`	Для запуска порта требуется Firefox. Возможные значения: `yes` (версия по умолчанию), `40`, `36`, `35`. По умолчанию устанавливает зависимость от версии `40`.
`USE_FIREFOX_BUILD`	Для построения порта требуется Firefox. Возможные значения: смотрите USE_FIREFOX. Автоматически устанавливает USE_FIREFOX с присвоением того же значения.
`USE_SEAMONKEY`	Для запуска порта требуется SeaMonkey. Возможные значения: `yes` (версия по умолчанию), `20`, `11` (устарело, больше не должно использоваться). По умолчанию устанавливает зависимость от версии `20`.
`USE_SEAMONKEY_BUILD`	Для построения порта требуется SeaMonkey. Возможные значения: смотрите USE_SEAMONKEY. Автоматически устанавливает USE_SEAMONKEY с присвоением того же значения.
`USE_THUNDERBIRD`	Для запуска порта требуется Thunderbird. Возможные значения: `yes` (версия по умолчанию), `31`, `30` (устарело, больше не должно использоваться). По умолчанию устанавливает зависимость от версии `31`.
`USE_THUNDERBIRD_BUILD`	Для построения порта требуется Thunderbird. Возможные значения: смотрите USE_THUNDERBIRD. Автоматически устанавливает USE_THUNDERBIRD с присвоением того же значения.

Полный перечень доступных переменных можно получить в файле /usr/ports/Mk/bsd.gecko.mk.

6.24. Использование баз данных

Таблица 44. Переменные для портов, использующих базы данных
Переменная	Значение
`USE_BDB`	Если переменная установлена в `yes`, добавляет зависимость от порта databases/db41. Также переменной можно присвоить значения: 2, 3, 40, 41, 42, 43, 44, 46, 47, 48 или 51. Вы можете объявить диапазон принимаемых значений, `USE_BDB`=42+ будет искать установленную версию с наибольшим номером, и, если ничего не установлено, вернется к 42.
`USE_MYSQL`	Если переменная установлена в `yes`, добавляет зависимость от порта databases/mysql55-client. Как связанная переменная, `WANT_MYSQL_VER` может быть установлена в значение 323, 40, 41, 50, 51, 52, 55 или 60.
`USE_PGSQL`	Если установлена в `yes`, добавляет зависимость от порта databases/postgresql90-client. Как связанная переменная, `WANT_PGSQL_VER` может быть установлена в значение 83, 84, 90, 91 или 92. Вы можете указать максимальное и минимальное значения; `WANT_PGSQL_VER=90+` сделает порт зависимым от минимальной версии 9.0.
`USE_SQLITE`	Если переменная имеет значение `yes`, добавляет зависимость от порта databases/sqlite3. Переменная может принимать значения: 3, 2.

Подробнее смотрите в bsd.database.mk.

6.25. Запуск и остановка служб (сценарии `rc`)

Сценарии rc.d используются для запуска служб при запуске системы и дают администратору стандартный способ остановки, запуска и перезапуска службы. Порты интегрируются в системную инфраструктуру rc.d. Подробности по её использованию можно найти в главе rc.d Руководства. Подробное объяснение доступных команд находится в rc(8) и rc.subr(8). Наконец, есть статьяо практических аспектах написания сценариев rc.d.

Установить можно один или более сценариев rc.d:

USE_RC_SUBR=	doormand

Сценарии обязаны размещаться в подкаталоге files с обязательным добавлением суффикса .in к имени файла. Для этого файла будут использоваться стандартные расширения SUB_LIST. Также особенно приветствуется использование расширений %%PREFIX%% и %%LOCALBASE%%. Подробнее о SUB_LIST в соответствующей главе.

Начиная с FreeBSD 6.1-RELEASE локальные сценарии rc.d (включая установленные из портов) включены в общий rcorder(8) основной системы.

Пример простого сценария rc.d:

#!/bin/sh

# $FreeBSD$
#
# PROVIDE: doormand
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# doormand_enable (bool):	Set to NO by default.
#				Set it to YES to enable doorman.
# doormand_config (path):	Set to %%PREFIX%%/etc/doormand/doormand.cf
#				by default.

. /etc/rc.subr

name=doormand
rcvar=doormand_enable

load_rc_config $name

: ${doormand_enable:="NO"}
: ${doormand_config="%%PREFIX%%/etc/doormand/doormand.cf"}

command=%%PREFIX%%/sbin/${name}
pidfile=/var/run/${name}.pid

command_args="-p $pidfile -f $doormand_config"

run_rc_command "$1"

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

REQUIRE: LOGIN

Если служба работает под определенным пользователем (отличным от root), то это делается принудительно. В сценарий выше включена конструкция

KEYWORD: shutdown

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

Для необязательных элементов конфигурации присвоение переменной по умолчанию в стиле "=" является более предпочтительным по сравнению со стилем ":=", используемым здесь, поскольку первый устанавливает значение по умолчанию только если переменная не установлена, а последний устанавливает её, если переменная не установлена или обнулена. Пользователь вполне может написать в своем файле rc.conf.local что-нибудь типа

doormand_flags=""

и тогда произойдет неуместная подстановка переменной с использованием ":=", что переопределит намерения пользователя. Переменная _enable является обязательной; значением по умолчанию должно быть ":".

6.25.1. Контрольный список перед внесением изменений

Перед тем, как отсылать порт со сценарием rc.d, и тем более перед его коммитом, сверьтесь со следующим контрольным списком, чтобы убедиться, что порт для этого готов.

Большинство из этих проверок умеет выполнять порт devel/rclint, но это не является заменой надлежащему просмотру.

Если это новый файл, заканчивается ли он на .sh? Если это так, то имя файла должно быть изменено на file.in, поскольку файлы rc.d не могут оканчиваться на такое расширение.
Присутствует ли в файле тег $FreeBSD$ ?
Соответствуют ли друг другу имя файла (без .in), строка PROVIDE и $name? Имя файла, совпадающее с PROVIDE, упрощает отладку, особенно для проблем, связанных с rcorder(8). Соответствие имени файла и $name также упрощает понимание, какие переменные имеют отношение к сценарию в rc.conf[.local]. Последнее также является тем, что вы могли бы назвать "политикой" для всех новых сценариев, включая те, что входят в базовую систему.
Содержит ли строка REQUIRE значение LOGIN? Это условие обязательно для сценариев, работающих не из-под суперпользователя. Если сценарий запускается из-под суперпользователя, то стоит ли его запускать до LOGIN? Если нет, то его следует запускать после, так чтобы мы могли свободно сгруппировать локальные сценарии в той точке rcorder(8), когда почти все сценарии в базовой системе уже стартовали.
Запускает ли сценарий постоянную службу? Если да, то он должен иметь KEYWORD: shutdown.
Убедитесь в том, что в сценарии отсутствует KEYWORD: FreeBSD. Это перестало быть нужным и нежелательно уже много лет. Это также служит индикатором того, что новый сценарий был скопирован со старого, поэтому особое внимание должно быть уделено при проверке.
Если сценарий использует интерпретируемый язык, такой как perl, python или ruby, то убедитесь, что значение command_interpreter установлено должным образом. В противном случае
```
# service name stop
```
возможно будет работать неправильно. Смотрите service(8) для дополнительной информации.
Все ли вхождения /usr/local были заменены на %%PREFIX%%?
Идет ли присвоение переменным значений по умолчанию после load_rc_config?
Используются ли пустые строки при присвоении значений по умолчанию? Такие присвоения должны быть удалены, но перепроверьте, что эти параметры задокументированы в комментариях в начале файла.
Действительно ли в сценариях используются значения, присвоенные переменным?
Являются ли параметры по умолчанию, перечисленные в name_flags, обязательными? Если это так, то их следует поместить в command_args. Параметр -d здесь - это как красный флаг (прошу прощения за каламбур), поскольку обычно он применяется для "демонизации" процесса и поэтому на самом деле обязательный.
Никогда не включайте переменную name_flags в command_args (и наоборот; в прочем, такая ошибка встречается реже).
Запускает ли сценарий какой-либо код безусловно? Это нехорошо. Обычно такие вещи могут/должны помещаться в start_precmd.
Все логические условия должны использовать функцию checkyesno. Не пишите самописных проверок для [Yy][Ee][Ss], и так далее.
Если в сценарии выполняется цикл (например, ожидание чего-либо перед стартом), используется ли счетчик для завершения цикла? Мы не хотим бесконечного ожидания загрузки в случае возникновения ошибки.
Создает ли сценарий файлы или каталоги, которым нужны особые права доступа? Например, файл pid, который должен принадлежать пользователю, из-под которого запускается процесс. Вместо традиционных команд touch(1)/chown(8)/chmod(1) подумайте об использовании install(1) с подходящими аргументами командной строки, для того чтобы выполнить всю процедуру за один шаг.

6.26. Добавление пользователей и групп

Некоторые порты требуют в установленной системе наличие определенного пользователя. Выберите свободный UID в диапазоне от 50 до 999 и зарегистрируйте его в ports/UIDs (для пользователей) и/или в ports/GIDs (для групп). Удостоверьтесь, что не используете UID, уже используемый системой или другими портами.

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

Затем вы сможете использовать в вашем Makefile переменные USERS и GROUPS, и пользователь автоматически создастся при установке порта.

USERS=	pulse
GROUPS=	pulse pulse-access pulse-rt

Текущий перечень зарезервированных UID и GID находится в ports/UIDs и ports/GIDs.

6.27. Порты, требующие наличия исходных текстов ядра

Некоторым портам (таким как загружаемые модули ядра) для компиляции нужны файлы с исходными текстами ядра. Ниже указан корректный способ определения, установлены ли они пользователем:

USES=	kmod

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

Изменено: 9 марта 2024 г. by Danilo G. Baio

Главная

Глава 6. Особые соглашения

Содержание

6.1. Staging

6.2. Динамические библиотеки

6.3. Порты с ограничениями на распространение или с правовым обременением

6.3.1. NO_PACKAGE

6.3.2. NO_CDROM

6.3.3. NOFETCHFILES

6.3.4. RESTRICTED

6.3.5. RESTRICTED_FILES

6.3.6. LEGAL_TEXT

6.3.7. /usr/ports/LEGAL и LEGAL

6.3.8. Примеры использования

6.4. Механизмы построения

6.4.1. Параллельное построение портов

6.4.2. make, gmake и imake

6.4.3. Сценарий configure

6.4.4. Использование cmake

6.4.5. Использование scons

6.5. Использование GNU Autotools

6.5.1. Введение

6.5.2. libtool

6.5.3. libltdl

6.5.4. autoconf и autoheader

6.5.5. automake и aclocal

6.6. Использование GNU gettext

6.6.1. Простой вариант использования

6.6.2. Оптимальное использование

6.6.3. Управление каталогами сообщений

6.7. Использование Perl

6.8. Использование X11

6.8.1. Компоненты X.Org

6.8.2. Порты, которым требуется Motif

6.8.3. Шрифты для X11

6.8.4. Получение поддельного DISPLAY, используя Xvfb

6.8.5. Элементы рабочего стола

6.8.5.1. Использование предопределенных файлов .desktop

6.8.5.2. Обновление базы данных рабочего стола

6.8.5.3. Создание элементов рабочего стола с использованием DESKTOP_ENTRIES

6.9. Использование GNOME

6.10. Использование Qt

6.10.1. Порты, для которых требуется Qt

6.10.2. Выбор компонентов

6.10.3. Использование qmake

6.11. Использование KDE

6.11.1. Задание переменных KDE 4

6.12. Использование Java

6.12.1. Задание переменных

6.12.2. Построение с Ant

6.12.3. Практические рекомендации

6.13. Веб-приложения, Apache и PHP

6.13.1. Apache

6.13.2. Веб-приложения

6.13.3. PHP

6.13.4. Модули PEAR

6.14. Использование Python

6.15. Использование Tcl/Tk

6.16. Использование Emacs

6.17. Использование Ruby

6.18. Использование SDL

6.19. Использование wxWidgets

6.19.1. Введение

6.19.2. Выбор версии

6.19.3. Выбор компонентов

6.19.4. Unicode

6.19.5. Обнаружение установленных версий

6.19.6. Переменные для определения

6.19.7. Обработка в bsd.port.pre.mk

6.19.8. Дополнительные параметры configure

6.20. Использование Lua

6.20.1. Введение

6.20.2. Выбор версии

6.20.3. Выбор компонентов

6.20.4. Обнаружение установленных версий

6.20.5. Переменные для определения

6.20.6. Обработка в bsd.port.pre.mk

6.21. Использование iconv

6.22. Использование Xfce

6.23. Использование Mozilla

6.24. Использование баз данных

6.3.1. `NO_PACKAGE`

6.3.2. `NO_CDROM`

6.3.3. `NOFETCHFILES`

6.3.4. `RESTRICTED`

6.3.5. `RESTRICTED_FILES`

6.3.6. `LEGAL_TEXT`

6.3.7. /usr/ports/LEGAL и `LEGAL`

6.4.2. `make`, `gmake` и `imake`

6.4.3. Сценарий `configure`

6.4.4. Использование `cmake`

6.4.5. Использование `scons`

6.5.2. `libtool`

6.5.3. `libltdl`

6.5.4. `autoconf` и `autoheader`

6.5.5. `automake` и `aclocal`

6.6. Использование GNU `gettext`

6.8.4. Получение поддельного `DISPLAY`, используя Xvfb

6.8.5.3. Создание элементов рабочего стола с использованием `DESKTOP_ENTRIES`

6.10.3. Использование `qmake`

6.19.8. Дополнительные параметры `configure`

6.21. Использование `iconv`

6.25. Запуск и остановка служб (сценарии `rc`)