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

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

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

  1. Если это новый файл, заканчивается ли он на .sh? Если это так, то имя файла должно быть изменено на file.in, поскольку файлы rc.d не могут оканчиваться на такое расширение.

  2. Присутствует ли в файле тег $FreeBSD$?

  3. Соответствуют ли друг другу имя файла (без .in), строка PROVIDE и $name? Имя файла, совпадающее с PROVIDE, упрощает отладку, особенно для проблем, связанных с rcorder(8). Соответствие имени файла и $name также упрощает понимание, какие переменные имеют отношение к сценарию в rc.conf[.local]. Последнее также является тем, что вы могли бы назвать "политикой" для всех новых сценариев, включая те, что входят в базовую систему.

  4. Содержит ли строка REQUIRE значение LOGIN? Это условие обязательно для сценариев, работающих не из-под суперпользователя. Если сценарий запускается из-под суперпользователя, то стоит ли его запускать до LOGIN? Если нет, то его следует запускать после, так чтобы мы могли свободно сгруппировать локальные сценарии в той точке rcorder(8), когда почти все сценарии в базовой системе уже стартовали.

  5. Запускает ли сценарий постоянную службу? Если да, то он должен иметь KEYWORD: shutdown.

  6. Убедитесь в том, что в сценарии отсутствует KEYWORD: FreeBSD. Это перестало быть нужным и нежелательно уже много лет. Это также служит индикатором того, что новый сценарий был скопирован со старого, поэтому особое внимание должно быть уделено при проверке.

  7. Если сценарий использует интерпретируемый язык, такой как perl, python или ruby, то убедитесь, что значение command_interpreter установлено должным образом. В противном случае

    # service name stop

    возможно будет работать неправильно. Смотрите service(8) для дополнительной информации.

  8. Все ли вхождения /usr/local были заменены на %%PREFIX%%?

  9. Идет ли присвоение переменным значений по умолчанию после load_rc_config?

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

  11. Действительно ли в сценариях используются значения, присвоенные переменным?

  12. Являются ли параметры по умолчанию, перечисленные в name_flags, обязательными? Если это так, то их следует поместить в command_args. Параметр -d здесь - это как красный флаг (прошу прощения за каламбур), поскольку обычно он применяется для "демонизации" процесса и поэтому на самом деле обязательный.

  13. Никогда не включайте переменную name_flags в command_args (и наоборот; в прочем, такая ошибка встречается реже).

  14. Запускает ли сценарий какой-либо код безусловно? Это нехорошо. Обычно такие вещи могут/должны помещаться в start_precmd.

  15. Все логические условия должны использовать функцию checkyesno. Не пишите самописных проверок для [Yy][Ee][Ss], и так далее.

  16. Если в сценарии выполняется цикл (например, ожидание чего-либо перед стартом), используется ли счетчик для завершения цикла? Мы не хотим бесконечного ожидания загрузки в случае возникновения ошибки.

  17. Создает ли сценарий файлы или каталоги, которым нужны особые права доступа? Например, файл 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