Глава 17. Использование макроса USES | FreeBSD Documentation Portal
Description: Макросы USES упрощают объявление требований и настроек для порта FreeBSD
Keywords: uses,macros,introduction,guide

# Глава 17. Использование макроса USES

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

## 17.1. Введение в `USES`

Макросы `USES` упрощают объявление требований и настроек для порта. Они могут добавлять зависимости, изменять поведение при сборке, добавлять метаданные в пакеты и так далее, просто выбирая предустановленные значения.

Каждый раздел в этой главе описывает возможное значение для `USES`, а также его возможные аргументы. Аргументы добавляются к значению после двоеточия (`:`). Несколько аргументов разделяются запятыми (`,`).

Пример 1. Использование нескольких значений

    USES=	bison perl

Пример 2. Добавление аргумента

    USES=	tar:xz

Пример 3. Добавление нескольких аргументов

    USES=	drupal:7,theme

Пример 4. Смешивая всё вместе

    USES=	pgsql:9.3+ cpe python:2.7,build

## 17.2. `7z`

Возможные аргументы: (нет), `p7zip`, `partial`

Извлечение с использованием 7z(1) вместо bsdtar(1) и устанавливает `EXTRACT_SUFX=.7z`. Опция `p7zip` добавляет зависимость от `7z` из archivers/p7zip, если версия из базовой системы не может извлечь файлы. `EXTRACT_SUFX` не изменяется, если используется опция `partial`, это может быть полезно, если основной дистрибутивный файл не имеет расширения .7z.

## 17.3. `ada`

Возможные аргументы: (нет), `6`, `12`, `(запуск)`

Зависит от компилятора с поддержкой Ada и устанавливает `CC` соответствующим образом. По умолчанию используется `gcc6-aux` из портов.

## 17.4. `angr`

Возможные аргументы: `binaries`, `nose`

Обеспечить поддержку портов, требующих платформу бинарного анализа angr.

Если присутствует аргумент `binaries`, для тестирования порта требуются специальные бинарные файлы `angr`.

Если присутствует аргумент `nose`, порт использует `nosetests` для цели тестирования. Этот аргумент подразумевает `USES=python:test`.

Фреймворк предоставляет следующие переменные, которые могут быть установлены портом:

`ANGR_VERSION`

  Версия программ проекта `angr`.

`ANGR_BINARIES_TAGNAME`

  Имя тега для бинарных файлов `angr`.

`ANGR_NOSETESTS`

  Путь к программе `nosetests`.

## 17.5. `ansible`

Возможные аргументы: `env`, `module`, `plugin`

Обеспечивает поддержку портов, зависящих от пакета sysutils/ansible.

Если присутствует аргумент `env`, порт не зависит от sysutils/ansible, но требует установки некоторых переменных Ansible.

Если присутствует аргумент `module`, то порт является модулем Ansible.

Если присутствует аргумент `plugin`, то порт является плагином Ansible.

Фреймворк предоставляет следующие переменные порту:

`ANSIBLE_CMD`

  Путь к программе ansible.

`ANSIBLE_DOC_CMD`

  Путь к программе ansible-doc.

`ANSIBLE_RUN_DEPENDS`

  RUN_DEPENDS с портом Ansible.

`ANSIBLE_DATADIR`

  Путь к корню структуры каталогов, где хранятся все модули и плагины Ansible.

`ANSIBLE_ETCDIR`

  Путь к каталогу etc Ansible.

`ANSIBLE_PLUGINS_PREFIX`

  Путь к каталогу "plugins" в `${ANSIBLE_DATADIR}`.

`ANSIBLE_MODULESDIR`

  Путь к каталогу для локальных модулей Ansible.

`ANSIBLE_PLUGINSDIR`

  Путь к каталогу для локальных плагинов Ansible.

`ANSIBLE_PLUGIN_TYPE`

  Тип плагина Ansible (например, "connection", "inventory" или "vars").

## 17.6. `apache`

Возможные аргументы: (нет), `2.4`, `build`, `run`, `server`

Обеспечивает поддержку портов, зависящих от веб-сервера Apache.

Аргумент `version` можно использовать для указания конкретной версии Apache httpd. Можно задать определённую версию (`USES=apache:2.4`), минимальную версию (`USES=apache:2.4+`) или максимальную версию (`USES=apache:-2.4`).

Если указан аргумент `build`, к порту добавляется зависимость для сборки.

Если указан аргумент `run`, к порту добавляется зависимость времени выполнения.

Если указан аргумент `server`, это означает, что порт является серверным.

Фреймворк предоставляет следующие переменные, которые могут быть установлены портом:

`AP_FAST_BUILD`

  Автоматическая сборка модуля

`AP_GENPLIST`

  Автоматическое создание `PLIST` плюс добавление модуля в отключенном состоянии в httpd.conf (только если нет файла `pkg-plist`)

`MODULENAME`

  Имя модуля Apache. По умолчанию: `${PORTNAME}`

`SHORTMODNAME`

  Краткое название модуля Apache. По умолчанию: `${MODULENAME:S/mod_//}`

`SRC_FILE`

  Исходный файл модуля APACHE. По умолчанию: `${MODULENAME}.c`

Следующие переменные могут быть доступны для порта:

`APACHE_VERSION`

  Основная-вспомогательная версия выбранного сервера Apache, например 2.4

`APACHEETCDIR`

  Расположение каталога конфигурации Apache. По умолчанию: ${LOCALBASE}/etc/apache24

`APACHEINCLUDEDIR`

  Расположение include-файлов Apache. По умолчанию: ${LOCALBASE}/include/apache24

`APACHEMODDIR`

  Расположение модулей Apache. По умолчанию: ${LOCALBASE}/libxexec/apache24

`APACHE_DEFAULT`::Версия Apache по умолчанию

## 17.7. `autoreconf`

Возможные аргументы: (нет), `build`

Выполняет `autoreconf`. Эта команда объединяет функциональность `aclocal`, `autoconf`, `autoheader`, `automake`, `autopoint` и `libtoolize`. Каждая из этих команд применяется к ${AUTORECONF_WRKSRC}/configure.ac или его старому названию ${AUTORECONF_WRKSRC}/configure.in. Если configure.ac определяет подкаталоги с их собственными configure.ac с использованием `AC_CONFIG_SUBDIRS`, `autoreconf` также рекурсивно обновит их. Аргумент `:build` только добавляет зависимости времени сборки на эти инструменты, но не запускает `autoreconf`. Порт может установить `AUTORECONF_WRKSRC`, если `WRKSRC` не содержит путь к configure.ac.

## 17.8. `azurepy`

Возможные аргументы: (отсутствуют)

Обеспечить поддержку портов `py-azure*`. Удаляет пространства имён `azure` и очищает общие файлы.

## 17.9. `blaslapack`

Возможные аргументы: (нет), `atlas`, `netlib` (по умолчанию), `gotoblas`, `openblas`

Добавляет зависимости от библиотек Blas / Lapack.

## 17.10. `bdb`

Возможные аргументы: (отсутствуют), `5` (по умолчанию), `18`

Добавить зависимость от библиотеки Berkeley DB. По умолчанию используется databases/db5. Также может зависеть от databases/db18 при использовании аргумента `:18`. Можно объявить диапазон допустимых значений: `:5+` находит самую высокую установленную версию и возвращается к 5, если ничего другого не установлено. `INVALID_BDB_VER` можно использовать для указания версий, которые не работают с этим портом. Фреймворк предоставляет порту следующие переменные:

`BDB_LIB_NAME`

  Имя библиотеки Berkeley DB. Например, при использовании databases/db5 она содержит `db-5.3`.

`BDB_LIB_CXX_NAME`

  Название библиотеки Berkeley DBC++. Например, при использовании databases/db5 она содержит `db_cxx-5.3`.

`BDB_INCLUDE_DIR`

  Расположение каталога с заголовочными файлами Berkeley DB. Например, при использовании пакета databases/db5, он будет содержать `${LOCALBASE}/include/db5`.

`BDB_LIB_DIR`

  Расположение каталога библиотеки Berkeley DB. Например, при использовании databases/db5, он содержит `${LOCALBASE}/lib`.

`BDB_VER`

  Обнаруженная версия Berkeley DB. Например, при использовании `USES=bdb:5+` и установленной Berkeley DB 18, будет содержать `18`.

| databases/db48 устарел и не поддерживается. Он не должен использоваться ни одним портом.

## 17.11. `bison`

Возможные аргументы: (нет), `build`, `run`, `both`

Использует пакет devel/bison По умолчанию, без аргументов или с аргументом `build`, подразумевается, что `bison` является зависимостью на этапе сборки, `run` — зависимостью на этапе выполнения, а `both` — зависимостью как на этапе сборки, так и на этапе выполнения.

## 17.12. `budgie`

Возможные аргументы: (отсутствуют)

Предоставить поддержку окружения рабочего стола Budgie. Используйте `USE_BUDGIE` для выбора необходимых компонентов порта. Дополнительную информацию см. в разделе Использование Budgie.

## 17.13. `cabal`

| Порты не следует создавать для библиотек Haskell, подробнее см. в Библиотеки Haskell.

Возможные аргументы: (отсутствуют), `hpack`, `nodefault`

Устанавливает значения и цели по умолчанию, используемые для сборки программного обеспечения на Haskell с помощью Cabal. Добавляется зависимость для сборки на порт компилятора Haskell (lang/ghc). Если в переменной `BUILD_DEPENDS` уже указана другая версия GHC (например, lang/ghc810), она будет использована вместо версии по умолчанию. Если указан аргумент `hpack`, добавляется зависимость для сборки на devel/hs-hpack, и `hpack` вызывается на этапе конфигурации для генерации файла .cabal. Если указан аргумент `nodefault`, фреймворк не будет пытаться загрузить основной дистрибутивный файл из Hackage. Этот аргумент добавляется неявно, если присутствует `USE_GITHUB` или `USE_GITLAB`.

Фреймворк предоставляет следующие переменные:

`CABAL_REVISION`

  Пакеты Haskell, размещённые на Hackage, могут иметь ревизии. Установите этот параметр в целочисленное значение, чтобы использовать исправленное описание пакета.

`USE_CABAL`

  Если программное обеспечение использует зависимости на Haskell, перечислите их в этой переменной. Каждый элемент должен присутствовать на Hackage и быть указан в формате `имяпакета-0.1.2`. Зависимости также могут иметь ревизии, которые указываются после символа `_`. Поддерживается автоматическое формирование списка зависимостей, см. Сборка приложений на Haskell с помощью `cabal`.

`CABAL_FLAGS`

  Список флагов, передаваемых `cabal-install` на этапах настройки и сборки. Флаги передаются в исходном виде. Эта переменная обычно используется для включения или отключения флагов, объявленных в файле .cabal. Передайте `foo`, чтобы включить флаг `foo`, и `-foo`, чтобы отключить его.

`CABAL_EXECUTABLES`

  Список исполняемых файлов, устанавливаемых портом. Значение по умолчанию: `${PORTNAME}`. Для получения списка возможных значений этой переменной обратитесь к файлу .cabal портируемого проекта. Каждое значение соответствует разделу `executable` в файле .cabal. Элементы из этого списка автоматически добавляются в pkg-plist.

`SKIP_CABAL_PLIST`

  Если определено, не добавлять элементы из `${CABAL_EXECUTABLES}` в pkg-plist.

`opt_USE_CABAL`

  Добавляет элементы в `${USE_CABAL}` в зависимости от опции `opt`.

`opt_CABAL_EXECUTABLES`

  Добавляет элементы в `${CABAL_EXECUTABLES}` в зависимости от опции `opt`.

`opt_CABAL_FLAGS`

  Если `opt` включён, добавить значение к `${CABAL_FLAGS}`. В противном случае добавить `-value`, чтобы отключить флаг. Обратите внимание, что это поведение немного отличается от простого `CABAL_FLAGS`, так как оно не принимает значения, начинающиеся с `-`.

`CABAL_WRAPPER_SCRIPTS`

  Подмножество `${CABAL_EXECUTABLES}`, содержащее программы на Haskell, которые будут обёрнуты в shell-скрипт, устанавливающий переменные окружения `*_datadir` перед запуском программы. Это также приводит к тому, что фактический бинарный файл Haskell устанавливается в каталог `libexec/cabal/`. Данная настройка необходима для программ на Haskell, которые устанавливают свои файлы данных в каталог `share/`.

`FOO_DATADIR_VARS`

  Список дополнительных пакетов Haskell, чьи файлы данных должны быть доступны исполняемому файлу с именем `FOO`. Исполняемый файл должен быть частью `${CABAL_WRAPPER_SCRIPTS}`. Указанные пакеты Haskell не должны иметь суффикса версии.

`CABAL_PROJECT`

  Некоторые проекты на Haskell могут уже иметь файл `cabal.project`, который также создаётся фреймворком портов. Если это так, используйте эту переменную, чтобы указать, что делать с оригинальным файлом `cabal.project`. Установка этой переменной в значение `remove` приведёт к удалению оригинального файла. Установка этой переменной в значение `append` приведёт к следующему:

  1. Исходный файл переместится в `cabal.project.${PORTNAME}` на этапе `extract`.

  2. Исходный файл `cabal.project.${PORTNAME}` и сгенерированный `cabal.project` объединятся в один файл после этапа `patch`. Использование `append` позволяет выполнить патчинг исходного файла перед его объединением.

## 17.14. `cargo`

Возможные аргументы: (отсутствуют)

Использует Cargo для настройки, сборки и тестирования. Может применяться для портирования приложений на Rust, использующих систему сборки Cargo. Дополнительную информацию смотрите в Сборка приложений на Rust с помощью `cargo`.

## 17.15. `charsetfix`

Возможные аргументы: (отсутствуют)

Предотвращает установку файла charset.alias портом. Этот файл должен устанавливаться только пакетом converters/libiconv. Переменная `CHARSETFIX_MAKEFILEIN` может быть установлена в путь относительно `WRKSRC`, если charset.alias не устанавливается через ${WRKSRC}/Makefile.in.

## 17.16. `cl`

Возможные аргументы: (отсутствуют)

Предоставляет поддержку портов Common Lisp.

Фреймворк предоставляет следующие переменные, которые могут быть установлены портами:

`ASDF_MODULES`

  Список модулей `ASDF` для сборки, когда установлен `FASL_TARGET` (по умолчанию `PORTNAME`)

`FASL_TARGET`

  Собрать fasl вариант порта (один из `ccl`, `clisp` или `sbcl`)

`USE_ASDF`

  Зависит от пакета devel/cl-asdf

`USE_ASDF_FASL`

  Зависит от `devel/cl-asdf-<FASL_TARGET>`

`USE_CCL`

  Зависит от пакета lang/ccl; подразумевается при `FASL_TARGET=ccl`

`USE_CLISP`

  Зависит от пакета lang/clisp; подразумевается при `FASL_TARGET=clisp`

`USE_SBCL`

  Зависит от пакета lang/sbcl; подразумевается, если `FASL_TARGET=SBCL`

Фреймворк предоставляет следующие переменные, которые могут быть прочитаны портами:

`ASDF_PATHNAME`

  Путь к исходному коду CL

`ASDF_REGISTRY`

  Путь к реестру CL, содержащему файлы asd

`CCL`

  Путь к компилятору Clozure Common Lisp

`CLISP`

  Путь к компилятору GNU Common Lisp

`CL_LIBDIR_REL`

  Каталог библиотек CL относительно `LOCALBASE` или `PREFIX`

`FASL_DIR_REL`

  Относительный путь к скомпилированным fasl-файлам; зависит от `FASL_TARGET`

`FASL_PATHNAME`

  Путь к CL fasl

`LISP_EXTRA_ARG`

  Дополнительные аргументы, используемые при сборке fasl

`SBCL`

  Путь к компилятору Steel Bank Common Lisp

## 17.17. `cmake`

Возможные аргументы: (отсутствуют), `insource`, `noninja`, `run`, `testing`

Используйте CMake для настройки порта и генерации системы сборки.

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

По умолчанию для сборки используется Ninja (devel/ninja). В некоторых случаях это может работать некорректно. С аргументом `noninja` сборка будет использовать обычный `make`. Этот аргумент следует применять только если сборка на основе Ninja не работает.

С аргументом `run` регистрируется зависимость во время выполнения в дополнение к зависимости при сборке.

С аргументом `testing`, добавляется цель тестирования, использующая CTest. При запуске тестов порт будет переконфигурирован для тестирования и пересобран.

Для получения дополнительной информации см. Использование `cmake`.

## 17.18. `compiler`

Возможные аргументы: (нет), `env` (по умолчанию, подразумевается), `C++17-lang`, `C++14-lang`, `C++11-lang`, `gcc-C++11-lib`, `C++11-lib`, `C++0x`, `c11`, `nestedfct`, `features`

Определяет, какой компилятор использовать, исходя из заданных предпочтений. Используйте `C++17-lang`, если порту требуется компилятор с поддержкой C++17, `C++14-lang`, если порту требуется компилятор с поддержкой C++14, `C++11-lang`, если порту требуется компилятор с поддержкой C++11, `gcc-C++11-lib`, если порту требуется компилятор `g++` с библиотекой C++11, или `C++11-lib`, если порту требуется стандартная библиотека с поддержкой C++11. Если порту требуется компилятор, понимающий C++0X, C11 или вложенные функции, следует использовать соответствующие параметры.

Используйте `features` для запроса списка возможностей, поддерживаемых компилятором по умолчанию. После включения bsd.port.pre.mk порт может проверить результаты с помощью следующих переменных:

- `COMPILER_TYPE`: компилятор по умолчанию в системе, gcc или clang

- `ALT_COMPILER_TYPE`: альтернативный компилятор в системе, gcc или clang. Устанавливается только при наличии двух компиляторов в базовой системе.

- `COMPILER_VERSION`: первые две цифры версии компилятора по умолчанию.

- `ALT_COMPILER_VERSION`: первые две цифры версии альтернативного компилятора, если он присутствует.

- `CHOSEN_COMPILER_TYPE`: выбранный компилятор, gcc или clang

- `COMPILER_FEATURES`: возможности, поддерживаемые компилятором по умолчанию. В настоящее время указана библиотека C++.

## 17.19. `cpe`

Возможные аргументы: (отсутствуют)

Включает информацию о Common Platform Enumeration (CPE) в манифест пакета в виде строки формата CPE 2.3. Подробности см. в спецификации CPE. Чтобы добавить информацию CPE в порт, выполните следующие шаги:

1. Поищите официальную запись CPE для программного продукта, используя либо поисковую систему CPE от NVD, либо официальный словарь CPE (предупреждение: очень большой XML-файл). Никогда не создавайте данные CPE самостоятельно.

2. Добавьте `cpe` в `USES` и сравните результат выполнения `make -V CPE_STR` с записью в словаре CPE. Продолжайте шаг за шагом, пока результат `make -V CPE_STR` не станет корректным.

3. Если название продукта (второе поле, по умолчанию `PORTNAME`) указано неверно, определите `CPE_PRODUCT`.

4. Если название производителя (первое поле, по умолчанию `CPE_PRODUCT`) указано неверно, определите `CPE_VENDOR`.

5. Если поле версии (третье поле, по умолчанию `PORTVERSION`) указано неверно, определите `CPE_VERSION`.

6. Если поле обновления (четвертое поле, по умолчанию пустое) указано неверно, определите `CPE_UPDATE`.

7. Если это всё ещё неверно, проверьте файл Mk/Uses/cpe.mk для получения дополнительной информации или свяжитесь с Команды информационной безопасности портов <ports-secteam@FreeBSD.org>.

8. Извлекайте как можно больше информации для имени CPE из существующих переменных, таких как `PORTNAME` и `PORTVERSION`. Используйте модификаторы переменных для извлечения соответствующих частей из этих переменных, вместо того чтобы жёстко прописывать имя.

9. Всегда выполняйте `make -V CPE_STR` и проверяйте вывод перед коммитом любых изменений, затрагивающих `PORTNAME`, `PORTVERSION` или любые другие переменные, используемые для формирования `CPE_STR`.

## 17.20. `cran`

Возможные аргументы: (нет), `auto-plist`, `compiles`

Использует Comprehensive R Archive Network. Укажите `auto-plist` для автоматического создания pkg-plist. Укажите `compiles`, если порт содержит код, который необходимо компилировать.

## 17.21. `desktop-file-utils`

Возможные аргументы: (отсутствуют)

Использует update-desktop-database из пакета devel/desktop-file-utils. Дополнительный шаг post-install будет выполнен без вмешательства в уже существующие шаги post-install в Makefile порта. Строка с `@desktop-file-utils` будет добавлена в plist. Используйте этот макрос только если порт предоставляет файл `.desktop`, содержащий запись `MimeType`.

## 17.22. `desthack`

Возможные аргументы: (отсутствуют)

Изменяет поведение GNU configure для корректной поддержки `DESTDIR` в случае, если исходное программное обеспечение этого не делает.

## 17.23. `display`

Возможные аргументы: (отсутствуют), ARGS

Настраивает виртуальное окружение для отображения. Если переменная окружения `DISPLAY` не установлена, то Xvfb добавляется как зависимость при сборке, а `CONFIGURE_ENV` расширяется с указанием номера порта текущего запущенного экземпляра Xvfb. Параметр ARGS по умолчанию имеет значение `install` и управляет фазой, вокруг которой запускается и останавливается виртуальный дисплей.

## 17.24. `dos2unix`

Возможные аргументы: (отсутствуют)

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

- `DOS2UNIX_REGEX`: сопоставлять имена файлов на основе регулярного выражения.

- `DOS2UNIX_FILES`: соответствуют точным именам файлов.

- `DOS2UNIX_GLOB`: сопоставлять имена файлов на основе шаблона файлов оболочки.

- `DOS2UNIX_WRKSRC`: каталог, с которого начинать преобразования. По умолчанию `${WRKSRC}`.

## 17.25. `drupal`

Возможные аргументы: `7`, `module`, `theme`

Автоматизирует установку порта, который является темой или модулем Drupal. Использовать с версией Drupal, которую ожидает порт. Например, `USES=drupal:7,module` означает, что этот порт создает модуль Drupal 7. Тему Drupal 7 можно указать с помощью `USES=drupal:7,theme`.

## 17.26. `ebur128`

Возможные аргументы: (нет), `build`, `lib`, `run`, `test`

Добавляет зависимость от пакета audio/ebur128. Позволяет прозрачно зависеть от вариантов `rust` или `legacy`, используя `DEFAULT_VERSIONS` в make.conf. Например, для использования устаревшей версии укажите `DEFAULT_VERSIONS+=ebur128=legacy`

Без аргументов поведение аналогично случаю с предоставлением аргумента `lib`. Остальные аргументы указывают соответствующую категорию зависимости.

## 17.27. `eigen`

Возможные аргументы: 2, 3, build (по умолчанию), run

Добавить зависимость от пакета math/eigen.

## 17.28. `electronfix`

Возможные аргументы: `37`, `38`, `39`

Предоставить поддержку для простого портирования Electron-приложений, распространяемых в бинарной форме. Добавляет зависимость на этапах сборки и выполнения от devel/electron37, devel/electron38 или devel/electron39 в зависимости от используемого аргумента.

Фреймворк предоставляет следующие переменные, которые могут быть установлены портами:

`ELECTRONFIX_SYMLINK_FILES`

  Список файлов для создания символьных ссылок из дистрибутива Electron.

`ELECTRONFIX_MAIN_EXECUTABLE`

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

## 17.29. `elfctl`

Возможные аргументы: (отсутствуют), `build` (по умолчанию), `stage`

Установите управляющие заметки функций ELF-бинарных файлов, задав `ELF_FEATURES`.

Когда не указан аргумент или указан аргумент `build`, операции выполняются над бинарными файлами в `BUILD_WRKSRC`, а файлы, перечисленные в `ELF_FEATURES`, указываются относительно `BUILD_WRKSRC`. Когда указан аргумент `stage`, операции выполняются над бинарными файлами в `STAGEDIR`, а файлы, перечисленные в `ELF_FEATURES`, указываются относительно `STAGEDIR`.

Пример 5. Uses=elfctl

    ELF_FEATURES=	featurelist:path/to/file1 \
    		featurelist:path/to/file2

Формат `featurelist` описан в elfctl(1).

## 17.30. `elixir`

Возможные аргументы: (отсутствуют)

Предоставить поддержку для портов, использующих lang/elixir. Добавляет зависимость во время сборки и выполнения на lang/elixir.

Предоставляемые фреймворком переменные:

`ELIXIR_APP_NAME`

  Название приложения Elixir, как оно установлено в каталоге lib Elixir

`ELIXIR_LIB_ROOT`

  Путь к библиотекам Elixir по умолчанию

`ELIXIR_APP_ROOT`

  Корневой каталог для этого приложения Elixir

`ELIXIR_HIDDEN`

  Приложения, которые необходимо скрыть из пути выполнения кода; обычно `${PORTNAME}`

`ELIXIR_LOCALE`

  Локаль UTF-8, которая будет использоваться Elixir во время сборки (подойдет любая локаль UTF-8)

`MIX_CMD`

  Команда `mix`

`MIX_COMPILE`

  Команда `mix`, используемая для компиляции приложения на Elixir

`MIX_REWRITE`

  Автоматически заменять зависимости Mix на пути к коду

`MIX_BUILD_DEPS`

  Список `BUILD_DEPENDS` в формате категория/имя_порта (часто упоминаемый как "deps" в Erlang и Elixir)

`MIX_RUN_DEPS`

  Список `RUN_DEPENDS` в формате категория/имя порта

`MIX_DOC_DIRS`

  Дополнительные каталоги документации для установки в `DOCSDIR`

`MIX_DOC_FILES`

  Дополнительные файлы документации для установки в `DOCSDIR` (обычно README.md)

`MIX_ENV`

  Окружение для сборки Mix (в том же формате, что и `MAKE_ENV`)

`MIX_ENV_NAME`

  Имя среды сборки Mix, обычно "prod"

`MIX_BUILD_NAME`

  Имя выходного файла сборки в _build/, обычно `${MIX_ENV_NAME}`

`MIX_TARGET`

  Имя цели Mix, обычно "compile"

`MIX_EXTRA_APPS`

  Список подприложений для сборки, если имеются

`MIX_EXTRA_DIRS`

  Список дополнительных каталогов для установки в `ELIXIR_APP_ROOT`

`MIX_EXTRA_FILES`

  Список дополнительных файлов для установки в `ELIXIR_APP_ROOT`

## 17.31. `emacs`

Возможные аргументы: (нет) (по умолчанию), `build`, `run`, `noflavors`

Предоставляет поддержку для портов, требующих Emacs. Аргумент `build` создает зависимость сборки от Emacs. Аргумент `run` создает зависимость выполнения от Emacs. Если оба аргумента `build` и `run` отсутствуют, создаются зависимости сборки и выполнения от Emacs. Аргумент `noflavors` запрещает флейворы и подразумевается, если нет зависимости выполнения от Emacs.

Стандартный вариант Emacs для портов с `USES=emacs` можно определить в make.conf. Например, для варианта `nox` используйте `DEFAULT_VERSIONS+= emacs=nox`. Допустимые флейворы: `full`, `canna`, `nox`, `wayland`, `devel_full`, `devel_nox`.

Переменные, которые могут быть установлены портами:

`EMACS_FLAVORS_EXCLUDE`

  НЕ собирать эти флейворы Emacs. Если `EMACS_FLAVORS_EXCLUDE` не определена и:

  - существует зависимость во время выполнения от Emacs

  - аргумент noflavors не указан

  то предполагаются все допустимые флейворы Emacs.

`EMACS_NO_DEPENDS`

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

Переменные, которые могут быть прочитаны портами:

`EMACS_CMD`

  Команда Emacs с полным путём (например, /usr/local/bin/emacs-30.1)

`EMACS_FLAVOR`

  Используется для зависимостей (например, `BUILD_DEPENDS= dash.el${EMACS_PKGNAMESUFFIX}>0:devel/dash@${EMACS_FLAVOR}`)

`EMACS_LIBDIR`

  Каталог библиотек Emacs без `${PREFIX}` (например, share/emacs)

`EMACS_LIBDIR_WITH_VER`

  Каталог библиотеки без `${PREFIX}`, включая версию (например, share/emacs/30.1)

`EMACS_MAJOR_VER`

  Основная версия Emacs (например, 30)

`EMACS_PKGNAMESUFFIX`

  `PKGNAMESUFFIX` для различия вариантов Emacs

`EMACS_SITE_LISPDIR`

  Каталог site-lisp Emacs без `${PREFIX}` (например, share/emacs/site-lisp)

`EMACS_VER`

  Версия Emacs (например, 30.1)

`EMACS_VERSION_SITE_LISPDIR`

  Каталог site-lisp Emacs, включая номер версии (например, share/emacs/30.1/site-lisp)

## 17.32. `erlang`

Возможные аргументы: (нет), `enc`, `rebar`, `rebar3`

Добавляет зависимость на время сборки и выполнения от lang/erlang. В зависимости от аргумента, добавляет дополнительные зависимости для сборки. `enc` добавляет зависимость от devel/erlang-native-compiler, `rebar` добавляет зависимость от devel/rebar, а `rebar3` добавляет зависимость от devel/rebar3.

В дополнение, следующие переменные доступны для порта:

- `ERL_APP_NAME`: Имя приложения Erlang, как оно установлено в каталоге lib Erlang (без указания версии)

- `ERL_APP_ROOT`: Корневой каталог для этого приложения Erlang

- `REBAR_CMD`: Путь к команде "rebar"

- `REBAR3_CMD`: Путь к команде "rebar3"

- `REBAR_PROFILE`: Профиль Rebar

- `REBAR_TARGETS`: Список целей Rebar (обычно compile, возможно escriptize)

- `ERL_BUILD_NAME`: Имя сборки для rebar3

- `ERL_BUILD_DEPS`: Список BUILD_DEPENDS в формате категория/имя_порта

- `ERL_RUN_DEPS`: Список RUN_DEPENDS в формате категория/имя_порта

- `ERL_DOCS`: Список файлов и каталогов документации

## 17.33. `fakeroot`

Возможные аргументы: (отсутствуют)

Изменяет некоторые стандартные поведения систем сборки для разрешения установки от имени пользователя. Дополнительную информацию о `fakeroot` можно найти на https://wiki.debian.org/FakeRoot.

## 17.34. `firebird`

Возможные аргументы: (отсутствуют), `25`

Добавить зависимость от клиентской библиотеке базы данных Firebird.

## 17.35. `fonts`

Возможные аргументы: (отсутствуют), `fc`, `fontsdir` (по умолчанию), `none`

Добавляет зависимость во время выполнения на инструменты, необходимые для регистрации шрифтов. В зависимости от аргумента добавляет строку `@fc ${FONTSDIR}`, строку `@fontsdir ${FONTSDIR}` или не добавляет строку, если аргумент `none`, в plist. `FONTSDIR` по умолчанию имеет значение ${PREFIX}/share/fonts/${FONTNAME}, а `FONTNAME` — `${PORTNAME}`. Добавляет `FONTSDIR` в `PLIST_SUB` и `SUB_LIST`

## 17.36. `fortran`

Возможные аргументы: `gcc` (по умолчанию)

Использует компилятор GNU Fortran.

## 17.37. `fpc`

Возможные аргументы: (нет), `run`

Обеспечить поддержку портов на основе Free Pascal. Установит компилятор Free Pascal и модули.

Добавляет зависимость сборки от lang/fpc.

Если указан аргумент `run`, также добавляется зависимость запуска.

## 17.38. `fuse`

Возможные аргументы: `2` (по умолчанию), `3`

Порт будет зависеть от библиотеки FUSE и обрабатывать зависимость от модуля ядра в зависимости от версии FreeBSD.

## 17.39. `gem`

Возможные аргументы: (отсутствуют), `noautoplist`

Обработка сборки с RubyGems. Если используется `noautoplist`, список упаковки не генерируется автоматически.

Это подразумевает `USES=ruby`.

## 17.40. `gettext`

Возможные аргументы: (отсутствуют)

Устарело. Будет включать как `gettext-runtime`, так и `gettext-tools`.

## 17.41. `gettext-runtime`

Возможные аргументы: (отсутствуют), `lib` (по умолчанию), `build`, `run`

Использует пакет devel/gettext-runtime. По умолчанию, без аргументов или с аргументом `lib`, подразумевает зависимость от библиотеки libintl.so. Аргументы `build` и `run` подразумевают, соответственно, зависимость во время сборки и во время выполнения от gettext.

## 17.42. `gettext-tools`

Возможные аргументы: (отсутствуют), `build` (по умолчанию), `run`

Использует пакет devel/gettext-tools. По умолчанию, без аргумента или с аргументом `build`, регистрируется зависимость во время сборки от msgfmt. С аргументом `run` регистрируется зависимость во время выполнения.

## 17.43. `ghostscript`

Возможные аргументы: X, `build`, `run`, `nox11`

Можно указать конкретную версию X. Доступные версии: `7`, `8`, `9` и `agpl` (по умолчанию). `nox11` указывает, что требуется версия порта `-nox11`. `build` и `run` добавляют зависимости на Ghostscript во время сборки и выполнения соответственно. По умолчанию добавляются зависимости как на сборку, так и на выполнение.

## 17.44. `gl`

Возможные аргументы: (отсутствуют)

Предоставляет простой способ зависеть от компонентов GL. Компоненты должны быть перечислены в `USE_GL`. Доступные компоненты:

`egl`

  добавить зависимость от библиотеки libEGL.so из пакета graphics/libglvnd

`gbm`

  Добавить зависимость от библиотеки libgbm.so из пакета graphics/mesa-libs

`gl`

  Добавить зависимость от библиотеки libGL.so из пакета graphics/libglvnd

`glesv2`

  Добавить зависимость от библиотеки libGLESv2.so из пакета graphics/libglvnd

`glew`

  Добавить зависимость от библиотеки libGLEW.so из пакета graphics/glew

`glu`

  Добавить зависимость от библиотеки libGLU.so из graphics/libGLU

`glut`

  Добавить зависимость от библиотеки libglut.so из graphics/freeglut

`opengl`

  Добавить зависимость от библиотеки libOpenGL.so из graphics/libglvnd

## 17.45. `gmake`

Возможные аргументы: (отсутствуют)

Использует пакет devel/gmake как зависимость во время сборки и настраивает окружение для использования `gmake` в качестве стандартного `make` при сборке.

## 17.46. `gnome`

Возможные аргументы: (отсутствуют)

Предоставляет простой способ зависеть от компонентов GNOME. Компоненты должны быть перечислены в `USE_GNOME`. Доступные компоненты:

- `atk`

- `atkmm`

- `cairo`

- `cairomm`

- `dconf`

- `esound`

- `evolutiondataserver3`

- `gconf2`

- `gconfmm26`

- `gdkpixbuf`

- `gdkpixbuf2`

- `glib12`

- `glib20`

- `glibmm`

- `gnomecontrolcenter3`

- `gnomedesktop3`

- `gnomedesktop4`

- `gnomedocutils`

- `gnomemenus3`

- `gnomemimedata`

- `gnomeprefix`

- `gnomesharp20`

- `gnomevfs2`

- `gsound`

- `gtk-update-icon-cache`

- `gtk12`

- `gtk20`

- `gtk30`

- `gtkhtml3`

- `gtkhtml4`

- `gtkmm20`

- `gtkmm24`

- `gtkmm30`

- `gtksharp20`

- `gtksourceview`

- `gtksourceview2`

- `gtksourceview3`

- `gtksourceviewmm3`

- `gvfs`

- `intlhack`

- `intltool`

- `introspection`

- `libartlgpl2`

- `libbonobo`

- `libbonoboui`

- `libgda5`

- `libgda5-ui`

- `libgdamm5`

- `libglade2`

- `libgnome`

- `libgnomecanvas`

- `libgnomekbd`

- `libgnomeprint`

- `libgnomeprintui`

- `libgnomeui`

- `libgsf`

- `libgtkhtml`

- `libgtksourceviewmm`

- `libidl`

- `librsvg2`

- `libsigc++12`

- `libsigc++20`

- `libwnck`

- `libwnck3`

- `libxml++26`

- `libxml2`

- `libxslt`

- `metacity`

- `nautilus3`

- `orbit2`

- `pango`

- `pangomm`

- `pangox-compat`

- `py3gobject3`

- `pygnome2`

- `pygobject`

- `pygobject3`

- `pygtk2`

- `pygtksourceview`

- `referencehack`

- `vte`

- `vte3`

Зависимость по умолчанию — на время сборки и выполнения, её можно изменить с помощью `:build` или `:run`. Например:

    USES=		gnome
    USE_GNOME=	gnomemenus3:build intlhack

См. Использование GNOME для получения дополнительной информации.

## 17.47. `go`

| Порты не следует создавать для библиотек Go, дополнительную информацию см. в Библиотеки Go.

Возможные аргументы: (нет), `N.NN`, `N.NN+`, `N.NN-devel`, `modules`, `no_targets`, `run`

Устанавливает значения и цели по умолчанию, используемые для сборки ПО на Go. Добавляется зависимость сборки от порта компилятора Go, сопровождающие порта могут установить требуемую версию. Если используется формат `X.Y+`, то будет применяться Go версии `X.Y`, за исключением случаев, когда стандартная версия Go выше, чем `X.Y` — в таком случае будет использоваться стандартная версия. По умолчанию сборка выполняется в режиме GOPATH. Если ПО на Go использует модули, режим с поддержкой модулей можно включить с помощью аргумента `modules`. `no_targets` настроит окружение сборки, как `GO_ENV`, `GO_BUILDFLAGS`, но пропустит создание целей извлечения (extract) и сборки (build). `run` также добавит зависимость выполнения от порта компилятора Go.

Процесс сборки контролируется несколькими переменными:

`GO_MODULE`

  Имя модуля приложения, указанное директивой `module` в `go.mod`. В большинстве случаев это единственная необходимая переменная для портов, использующих модули Go.

`GO_PKGNAME`

  Имя пакета Go при сборке в режиме GOPATH. Это каталог, который будет создан в `${GOPATH}/src`. Если не задано явно и присутствует `GH_SUBDIR` или `GL_SUBDIR`, то `GO_PKGNAME` будет выведено из них. Не требуется при сборке в режиме с поддержкой модулей.

`GO_TARGET`

  Пакеты для сборки. Значение по умолчанию — `${GO_PKGNAME}`. `GO_TARGET` также может быть кортежем в формате `package:path`, где path может быть либо простым именем файла, либо полным путём, начинающимся с `${PREFIX}`.

`GO_TESTTARGET`

  Пакеты для тестирования. Значение по умолчанию — `./…​` (текущий пакет и все подпакеты).

`CGO_CFLAGS`

  Дополнительные значения `CFLAGS`, передаваемые компилятору C с помощью `go`.

`CGO_LDFLAGS`

  Дополнительные значения `LDFLAGS`, передаваемые компилятору C через `go`.

`GO_BUILDFLAGS`

  Дополнительные аргументы сборки, передаваемые в `go build`.

`GO_TESTFLAGS`

  Дополнительные аргументы сборки, передаваемые в `go test`.

См. Сборка приложений на Go для примеров использования.

## 17.48. `gperf`

Возможные аргументы: (отсутствуют)

Добавить зависимость во время сборки на devel/gperf, если `gperf` отсутствует в базовой системе.

## 17.49. `grantlee`

Возможные аргументы: `5`, `selfbuild`

Обработать зависимость от Grantlee. Указать `5` для зависимости от версии на основе Qt5, devel/grantlee5. `selfbuild` используется внутри devel/grantlee5 для получения номеров их версий.

## 17.50. `groff`

Возможные аргументы: `build`, `run`, `both`

Регистрирует зависимость от textproc/groff, если пакет отсутствует в базовой системе.

## 17.51. `gssapi`

Возможные аргументы: (отсутствуют), `base` (по умолчанию), `heimdal`, `mit`, `mit-devel`, `flags`, `bootstrap`

Обрабатывает зависимости, необходимые для использования GSS-API. Доступны только библиотеки, предоставляющие механизм Kerberos. По умолчанию (или при значении `base`) используется библиотека GSS-API из базовой системы. Также можно установить значение `heimdal` для использования security/heimdal, `mit-devel` для использования security/krb5 или `mit` для использования security/krb5-devel.

Если локальная установка Kerberos не находится в `LOCALBASE`, установите `HEIMDAL_HOME` (для `heimdal`) или `KRB5_HOME` (для `krb5`) на каталог установки Kerberos.

Эти переменные экспортируются для использования портами:

- `GSSAPIBASEDIR`

- `GSSAPICPPFLAGS`

- `GSSAPIINCDIR`

- `GSSAPILDFLAGS`

- `GSSAPILIBDIR`

- `GSSAPILIBS`

- `GSSAPI_CONFIGURE_ARGS`

Опция `flags` может быть указана вместе с `base`, `heimdal`, `mit` или `mit-devel` для автоматического добавления `GSSAPICPPFLAGS`, `GSSAPILDFLAGS` и `GSSAPILIBS` в `CFLAGS`, `LDFLAGS` и `LDADD` соответственно. Например, используйте `base,flags`.

Опция `bootstrap` — это специальный префикс, предназначенный только для использования в security/krb5 и security/heimdal. Например, используйте `bootstrap,mit`.

Пример 6. Типичное использование

    OPTIONS_SINGLE=	GSSAPI
    OPTIONS_SINGLE_GSSAPI=	GSSAPI_BASE GSSAPI_HEIMDAL GSSAPI_MIT GSSAPI_NONE

    GSSAPI_BASE_USES=	gssapi
    GSSAPI_BASE_CONFIGURE_ON=	--with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS}
    GSSAPI_HEIMDAL_USES=	gssapi:heimdal
    GSSAPI_HEIMDAL_CONFIGURE_ON=	--with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS}
    GSSAPI_MIT_USES=	gssapi:mit
    GSSAPI_MIT_CONFIGURE_ON=	--with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS}
    GSSAPI_NONE_CONFIGURE_ON=	--without-gssapi

## 17.52. `gstreamer`

Возможные аргументы: (отсутствуют)

Предоставляет простой способ зависимости от компонентов GStreamer. Компоненты должны быть перечислены в `USE_GSTREAMER`. Доступные компоненты:

- `a52dec`

- `aalib`

- `amrnb`

- `amrwbdec`

- `aom`

- `assrender`

- `bad`

- `bs2b`

- `cairo`

- `cdio`

- `cdparanoia`

- `chromaprint`

- `curl`

- `dash`

- `dtls`

- `dts`

- `dv`

- `dvd`

- `dvdread`

- `editing-services`

- `faac`

- `faad`

- `flac`

- `flite`

- `gdkpixbuf`

- `gl`

- `gme`

- `gnonlin`

- `good`

- `gsm`

- `gtk4`

- `gtk`

- `hal`

- `hls`

- `jack`

- `jpeg`

- `kate`

- `kms`

- `ladspa`

- `lame`

- `libav`

- `libcaca`

- `libde265`

- `libmms`

- `libvisual`

- `lv2`

- `mm`

- `modplug`

- `mpeg2dec`

- `mpeg2enc`

- `mpg123`

- `mplex`

- `musepack`

- `neon`

- `ogg`

- `opencv`

- `openexr`

- `openh264`

- `openjpeg`

- `openmpt`

- `opus`

- `pango`

- `png`

- `pulse`

- `qt`

- `resindvd`

- `rsvg`

- `rtmp`

- `shout2`

- `sidplay`

- `smoothstreaming`

- `sndfile`

- `sndio`

- `soundtouch`

- `soup`

- `spandsp`

- `speex`

- `srtp`

- `taglib`

- `theora`

- `ttml`

- `twolame`

- `ugly`

- `v4l2`

- `vorbis`

- `vpx`

- `vulkan`

- `wavpack`

- `webp`

- `webrtcdsp`

- `x264`

- `x265`

- `x`

- `ximagesrc`

- `zbar`

## 17.53. `guile`

Возможные аргументы: (нет), `X.Y`, `flavors`, `build`, `run`, `alias`, `conflicts`

Добавляет зависимость от Guile. По умолчанию это зависимость от соответствующей библиотеки `libguile*.so`, если не переопределено опциями `build` и/или `run`. Опция `alias` настраивает `BINARY_ALIAS` соответствующим образом (см. Использование `BINARY_ALIAS`).

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

Приложения, использующие Guile, обычно собираются только для одной версии Guile. Однако модули расширений или библиотек должны использовать опцию `flavors` для сборки с несколькими флейворами.

Для получения дополнительной информации см. Использование Guile.

## 17.54. `horde`

Возможные аргументы: (отсутствуют)

Добавить зависимости времени сборки и выполнения для devel/pear-channel-horde. Другие зависимости Horde можно добавить с помощью `USE_HORDE_BUILD` и `USE_HORDE_RUN`. Дополнительную информацию см. в разделе Модули Horde.

## 17.55. `iconv`

Возможные аргументы: (нет), `lib`, `build`, `patch`, `translit`, `wchar_t`

Использует функции `iconv`, либо из порта converters/libiconv как зависимость на этапе сборки и выполнения, либо из базовой системы. По умолчанию, без аргументов или с аргументом `lib`, подразумевает `iconv` с зависимостями на этапе сборки и выполнения. `build` подразумевает зависимость на этапе сборки, а `patch` — на этапе патчинга. Если порт использует расширения `WCHAR_T` или `//TRANSLIT` для `iconv`, добавьте соответствующие аргументы, чтобы использовалась правильная версия `iconv`. Для получения дополнительной информации см. Использование `iconv`.

## 17.56. `imake`

Возможные аргументы: (нет), `env`, `notall`, `noman`

Добавить devel/imake как зависимость на этапе сборки и выполнить `xmkmf -a` на этапе `configure`. Если указан аргумент `env`, цель `configure` не устанавливается. Если флаг `-a` вызывает проблемы для порта, добавьте аргумент `notall`. Если `xmkmf` не генерирует цель `install.man`, добавьте аргумент `noman`.

## 17.57. `java`

Возможные аргументы: (нет), `ant`, `build`, `extract`, `run`

По умолчанию используется `USES=java:build,run`, если аргументы не предоставлены и `NO_BUILD` не определен. Если `NO_BUILD` определен, используется `USES=java:run`. Если указан аргумент `ant`, порт использует Apache Ant. Если указан аргумент `build`, порт JDK добавляется в зависимости сборки. Если указан аргумент `extract`, порт JDK добавляется в зависимости извлечения. Если указан аргумент `run`, порт JDK добавляется в зависимости выполнения.

Фреймворк предоставляет следующие переменные, которые могут быть установлены портом:

`JAVA_VERSION`

  Список подходящих версий Java для порта, разделенных пробелами. Необязательный символ `+` позволяет указать диапазон версий. (допустимые значения `8[+]`, `11[+]`, `17[+]`, `18[+]`, `19[+]`, `20[+]`, `21[+]`, `22[+]`, `22[+]`)

`JAVA_OS`

  Список поддерживаемых операционных систем для порта JDK, разделённых пробелами. (допустимые значения: `native`, `linux`)

`JAVA_VENDOR`

  Список подходящих поставщиков портов JDK для порта, разделенных пробелами. (допустимые значения: `openjdk`, `oracle`)

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

`JAVA_PORT`

  Имя порта JDK. (например, 'java/openjdk8')

`JAVA_PORT_VERSION`

  Версия порта JDK. (например, '8')

`JAVA_PORT_OS`

  Используемая операционная система для порта JDK. (например, 'linux')

`JAVA_PORT_VENDOR`

  Поставщик порта JDK. (например, 'openjdk')

`JAVA_PORT_OS_DESCRIPTION`

  Описание операционной системы, используемой портом JDK. (например, 'Linux')

`JAVA_PORT_VENDOR_DESCRIPTION`

  Описание поставщика порта JDK. (например, 'OpenJDK BSD Porting Team')

`JAVA_HOME`

  Путь к каталогу установки JDK. (например, /usr/local/openjdk8)

`JAVAC`

  Путь к используемому компилятору Java. (например, /usr/local/openjdk8/bin/javac или /usr/local/bin/javac)

`JAR`

  Путь к используемому инструменту JAR. (например, /usr/local/openjdk8/bin/jar или /usr/local/bin/fastjar)

`APPLETVIEWER`

  Путь к утилите appletviewer. (например, /usr/local/linux-jdk1.8.0/bin/appletviewer)

`JAVA`

  Путь к исполняемому файлу `java`. Используется для запуска программ на Java. (например, /usr/local/openjdk8/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.

`JAVA_CLASSES`

  Путь к архиву, содержащему файлы классов JDK. В большинстве JDK это ${JAVA_HOME}/jre/lib/rt.jar.

`JAVASHAREDIR`

  Базовый каталог для всех общих ресурсов Java.

`JAVAJARDIR`

  Каталог, в котором порт должен устанавливать JAR-файлы.

`JAVALIBDIR`

  Каталог, в котором находятся JAR-файлы, установленные другими портами.

## 17.58. `jpeg`

Возможные аргументы: `lib` (по умолчанию, подразумевается), `build`, `run`

Помощь в обработке зависимостей от `jpeg`.

Если указан аргумент `lib` или аргументы не предоставлены, то в порт добавляется зависимость от библиотеки.

Если указан аргумент `build`, то в порт добавляется зависимость сборки.

Если указан аргумент `run`, то к порту добавляется зависимость времени выполнения.

Если указан аргумент `both`, то к порту добавляется зависимость для сборки и зависимость для выполнения.

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

`JPEG_PORT`

  Указывает реализацию JPEG для использования. Возможные значения:

  - graphics/jpeg-turbo (по умолчанию)

  - graphics/mozjpeg

## 17.59. `kde`

Возможные аргументы: `5`

Добавить зависимость от компонентов KDE. Подробнее см. в Использование KDE.

## 17.60. `kmod`

Возможные аргументы: (отсутствуют), `debug`

Заполняет шаблон для портов модулей ядра, в настоящее время:

- Добавьте `kld` в `CATEGORIES`.

- Установите `SSP_UNSAFE`.

- Установите `IGNORE`, если исходные коды ядра не найдены в `SRC_BASE`.

- Определить `KMODDIR` по умолчанию как /boot/modules, добавить его в `PLIST_SUB` и `MAKE_ENV`, а также создать его при установке. Если `KMODDIR` установлен в /boot/kernel, он будет перезаписан в /boot/modules. Это предотвращает повреждение пакетов при обновлении ядра из-за переименования /boot/kernel в /boot/kernel.old в процессе.

- Обрабатывать перекрестные ссылки на модули ядра при установке и удалении, используя `@kld`.

- Если указан аргумент `debug`, порт может установить отладочную версию модуля в KERN_DEBUGDIR/KMODDIR. По умолчанию `KERN_DEBUGDIR` копируется из `DEBUGDIR` и устанавливается в /usr/lib/debug. Фреймворк позаботится о создании и удалении необходимых каталогов.

## 17.61. `kodi`

Возможные аргументы: (отсутствуют), `noautoplist`

Обеспечить поддержку дополнений для multimedia/kodi. Если указан аргумент `noautoplist`, автоматическое создание `plist` не выполняется.

## 17.62. `lazarus`

Возможные аргументы: (отсутствуют), `gtk2` (по умолчанию), `qt5`, `qt6`, `flavors`

Обеспечить поддержку портов на основе editors/lazarus.

Если аргументы не предоставлены или указан `gtk2`, приложение lazarus-app будет собрано с интерфейсом `gtk2`, и порт editors/lazarus будет собран с интерфейсом `gtk2`.

Если указан аргумент `qt5`, приложение lazarus-app собирается с интерфейсом `qt5`.

Если указан аргумент `qt6`, приложение lazarus-app собирается с интерфейсом `qt6`.

Если указан аргумент `flavors`, приложение `lazarus-app` собирается с поддержкой функций флейворов.

Если порт не требует автоматической компиляции файлов проекта lazarus, можно определить следующую переменную:

`NO_LAZBUILD`= `yes`

Доступны следующие переменные для портов:

`LAZARUS_PROJECT_FILES`

  Список lpi-файлов. Он не должен быть пустым. По умолчанию: пусто

`LAZARUS_DIR`

  Путь к каталогу установки lazarus. По умолчанию: ${LOCALBASE}/share/lazarus-${LAZARUS_VER}

`LAZBUILD_ARGS`

  Дополнительные аргументы lazbuild. В большинстве случаев это может быть `-d`. Подробнее см. lazbuild(1). По умолчанию: пусто

`LAZARUS_NO_FLAVORS`

  Не собирать эти флейворы lazarus. Если `LAZARUS_NO_FLAVORS` не определена, то предполагаются все допустимые флейворы lazarus.

`WANT_LAZARUS_DEVEL`

  Если установлено значение `yes`, то используйте lazarus/devel как зависимость сборки.

## 17.63. `ldap`

Возможные аргументы: (нет), <версия>, клиент, сервер

Регистрирует зависимость от пакета net/openldap. Использует конкретную `<версию>` (без точечной нотации), если она указана. В противном случае пытается найти установленную версию. При необходимости возвращается к версии по умолчанию, указанной в `bsd.default-versions.mk`. `client` указывает на зависимость во время выполнения от клиентской библиотеки. Это также значение по умолчанию. `server` указывает на зависимость во время выполнения от сервера.

Следующие переменные могут быть доступны для порта:

`IGNORE_WITH_OPENLDAP`

  Эта переменная может быть определена, если порты не поддерживают одну или несколько версий OpenLDAP.

`WITH_OPENLDAP_VER`

  Пользовательская переменная для установки версии OpenLDAP.

`OPENLDAP_VER`

  Обнаруженная версия OpenLDAP.

## 17.64. `lha`

Возможные аргументы: (отсутствуют)

Установите `EXTRACT_SUFX` в `.lzh`

## 17.65. `libarchive`

Возможные аргументы: (отсутствуют)

Регистрирует зависимость от archivers/libarchive. Любые порты, зависящие от libarchive, должны включать `USES=libarchive`.

## 17.66. `libedit`

Возможные аргументы: (отсутствуют)

Регистрирует зависимость от devel/libedit. Все порты, зависящие от libedit, должны включать `USES=libedit`.

## 17.67. `libtool`

Возможные аргументы: (нет), `keepla`, `build`

Исправляет скрипты `libtool`. Это должно быть добавлено во все порты, использующие `libtool`. Аргумент `keepla` может быть использован для сохранения файлов .la. Некоторые порты не поставляются с собственной копией libtool и требуют зависимость во время сборки от devel/libtool, используйте аргумент `:build` для добавления такой зависимости.

## 17.68. `linux`

Возможные аргументы: `c6`, `c7`

Порт фреймворка совместимости с Linux. Укажите `c6` для зависимостей от пакетов CentOS 6. Укажите `c7` для зависимостей от пакетов CentOS 7. Доступные пакеты:

- `allegro`

- `alsa-plugins-oss`

- `alsa-plugins-pulseaudio`

- `alsalib`

- `atk`

- `avahi-libs`

- `base`

- `cairo`

- `cups-libs`

- `curl`

- `cyrus-sasl2`

- `dbusglib`

- `dbuslibs`

- `devtools`

- `dri`

- `expat`

- `flac`

- `fontconfig`

- `gdkpixbuf2`

- `gnutls`

- `graphite2`

- `gtk2`

- `harfbuzz`

- `jasper`

- `jbigkit`

- `jpeg`

- `libasyncns`

- `libaudiofile`

- `libelf`

- `libgcrypt`

- `libgfortran`

- `libgpg-error`

- `libmng`

- `libogg`

- `libpciaccess`

- `libsndfile`

- `libsoup`

- `libssh2`

- `libtasn1`

- `libthai`

- `libtheora`

- `libv4l`

- `libvorbis`

- `libxml2`

- `mikmod`

- `naslibs`

- `ncurses-base`

- `nspr`

- `nss`

- `openal`

- `openal-soft`

- `openldap`

- `openmotif`

- `openssl`

- `pango`

- `pixman`

- `png`

- `pulseaudio-libs`

- `qt`

- `qt-x11`

- `qtwebkit`

- `scimlibs`

- `sdl12`

- `sdlimage`

- `sdlmixer`

- `sqlite3`

- `tcl85`

- `tcp_wrappers-libs`

- `tiff`

- `tk85`

- `ucl`

- `xorglibs`

## 17.69. `llvm`

Возможные аргументы: (нет), `XY`, min=`XY`, max=`XY`, build, run, lib

Добавляет зависимость от LLVM. По умолчанию это зависимость для сборки, если не переопределено опциями `run` или `lib`. Версия по умолчанию задаётся в `LLVM_DEFAULT`. Также можно указать конкретную версию. Минимальную и максимальную версии можно указать с помощью параметров `min` и `max` соответственно. Фреймворк портов экспортирует следующие переменные в порт:

`LLVM_VERSION`

  Версия, выбранная из аргументов к llvm.mk

`LLVM_PORT`

  Выбранный порт llvm

`LLVM_CONFIG`

  `llvm-config` выбранного порта

`LLVM_LIBLLVM`

  `libLLVM.so` выбранного порта

`LLVM_PREFIX`

  Префикс инсталляции выбранного порта

## 17.70. `localbase`

Возможные аргументы: (отсутствуют), `ldflags`

Гарантирует использование библиотек из зависимостей в `LOCALBASE` вместо библиотек из базовой системы. Указывает `ldflags` для добавления `-L${LOCALBASE}/lib` в `LDFLAGS` вместо `LIBS`. Порты, зависящие от библиотек, которые также присутствуют в базовой системе, должны использовать эту опцию. Она также используется внутри несколькими другими `USES`.

## 17.71. `lua`

Возможные аргументы: (нет), `XY`, `XY+`, `-XY`, `XY-ZA`, `module`, `flavors`, `build`, `run`, `env`

Добавляет зависимость от Lua. По умолчанию это зависимость от библиотеки, если не переопределено опциями `build` и/или `run`. Опция `env` предотвращает добавление любой зависимости, при этом все обычные переменные остаются определёнными.

Версия по умолчанию устанавливается с помощью обычного механизма `DEFAULT_VERSIONS`, если только версия или диапазон версий не указаны в качестве аргумента, например, `51` или `51-54`.

Приложения, использующие Lua, обычно собираются только для одной версии Lua. Однако модули библиотек, предназначенные для загрузки кодом Lua, должны использовать опцию `module` для сборки с несколькими вариантами.

Для получения дополнительной информации см. Использование Lua.

## 17.72. `luajit`

Возможные аргументы: (нет), `X`

Добавляет зависимость от среды выполнения luajit. Можно указать конкретную версию X. Доступные версии: `luajit`, `luajit-devel`, `luajit-openresty`

После включения bsd.port.options.mk или bsd.port.pre.mk порт может проверять эти переменные:

`LUAJIT_VER`

  Выбранная версия luajit

`LUAJIT_INCDIR`

  Путь к заголовочным файлам luajit

`LUAJIT_LUAVER`

  Какой версии спецификации luajit выбрана (2.0 для luajit, иначе 2.1)

Для получения дополнительной информации см. Использование Lua.

## 17.73. `lxqt`

Возможные аргументы: (отсутствуют)

Обработка зависимостей для рабочей среды LXQt. Используйте `USE_LXQT` для выбора необходимых компонентов для порта. Дополнительную информацию см. в разделе Использование LXQt.

## 17.74. `magick`

Возможные аргументы: (нет), `X`, `build`, `nox11`, `run`, `test`

Добавить зависимость библиотеки от `ImageMagick`. Можно указать конкретную версию X. Доступные версии: `6` и `7` (по умолчанию). `nox11` означает, что требуется версия порта `-nox11`. `build`, `run` и `test` добавляют зависимости на сборку, выполнение и тестирование для ImageMagick.

## 17.75. `makeinfo`

Возможные аргументы: (отсутствуют)

Добавить зависимость во время сборки на `makeinfo`, если его нет в базовой системе.

## 17.76. `makeself`

Возможные аргументы: (отсутствуют)

Указывает, что файлы дистрибутива являются архивами makeself и устанавливает соответствующие зависимости.

## 17.77. `mate`

Возможные аргументы: (отсутствуют)

Предоставляет простой способ зависимостей от компонентов MATE. Компоненты должны быть перечислены в `USE_MATE`. Доступные компоненты:

- `autogen`

- `caja`

- `common`

- `controlcenter`

- `desktop`

- `dialogs`

- `docutils`

- `icontheme`

- `intlhack`

- `intltool`

- `libmatekbd`

- `libmateweather`

- `marco`

- `menus`

- `notificationdaemon`

- `panel`

- `pluma`

- `polkit`

- `session`

- `settingsdaemon`

Зависимость по умолчанию — на время сборки и выполнения, её можно изменить с помощью `:build` или `:run`. Например:

    USES=		mate
    USE_MATE=	menus:build intlhack

## 17.78. `meson`

Возможные аргументы: (нет), `muon `

Предоставить поддержку для проектов на основе Meson. Дополнительную информацию смотрите в Использование `meson`.

Если указан аргумент `muon`, в порт добавляется зависимость от devel/muon.

## 17.79. `metaport`

Возможные аргументы: (отсутствуют)

Устанавливает следующие переменные для упрощения создания метапорта: `MASTER_SITES`, `DISTFILES`, `EXTRACT_ONLY`, `NO_BUILD`, `NO_INSTALL`, `NO_MTREE`, `NO_ARCH`.

## 17.80. `minizip`

Возможные аргументы: (отсутствуют), `ng`

Добавляет зависимость библиотеки от archivers/minizip или archivers/minizip-ng соответственно.

## 17.81. `mlt`

Возможные аргументы: `7`, `nodepend`

Обеспечить поддержку портов, зависящих от multimedia/mlt7.

Если указан аргумент `nodepend`, зависимости от библиотек не создаются. Этот аргумент имеет смысл только для портов multimedia/mlt7*.

## 17.82. `mysql`

Возможные аргументы: (отсутствуют), `версия`, `client` (по умолчанию), `server`, `embedded`

Предоставить поддержку MySQL. Если версия не указана, попытаться определить установленную версию. В случае неудачи использовать версию по умолчанию, MySQL-5.6. Возможные версии: `55`, `55m`, `55p`, `56`, `56p`, `56w`, `57`, `57p`, `80`, `100m`, `101m` и `102m`. Суффиксы `m` и `p` обозначают флейворы MariaDB и Percona для MySQL. Параметры `server` и `embedded` добавляют зависимости во время сборки и выполнения на сервер MySQL. При использовании `server` или `embedded` добавьте `client`, чтобы также включить зависимость от libmysqlclient.so. Порт может установить `IGNORE_WITH_MYSQL`, если некоторые версии не поддерживаются.

Фреймворк устанавливает `MYSQL_VER` в обнаруженную версию MySQL.

## 17.83. `mono`

Возможные аргументы: (отсутствуют), `nuget`

Добавляет зависимость от фреймворка Mono (в настоящее время только C#), устанавливая соответствующие зависимости.

Укажите `nuget`, если порт использует пакеты nuget. `NUGET_DEPENDS` должен содержать имена и версии пакетов nuget в формате `имя=версия`. Можно добавить необязательное расположение пакета (origin), используя `имя=версия:_ расположение _`.

Вспомогательная цель `buildnuget` выведет содержимое `NUGET_DEPENDS` на основе предоставленного файла packages.config.

## 17.84. `motif`

Возможные аргументы: (отсутствуют)

Использует x11-toolkits/open-motif как зависимость библиотеки. Конечные пользователи могут установить `WANT_LESSTIF` в make.conf, чтобы использовать x11-toolkits/lesstif как зависимость вместо x11-toolkits/open-motif. Аналогично, установка `WANT_OPEN_MOTIF_DEVEL` в make.conf добавит зависимость от x11-toolkits/open-motif-devel

## 17.85. `mpi`

Возможные аргументы: `mpich` (по умолчанию), `openmpi`

Обеспечить поддержку портов, зависящих от `MPI`.

Если указан аргумент `mpich`, в порт добавляется зависимость от net/mpich.

Если указан аргумент `openmpi`, в порт добавляется зависимость от net/openmpi.

Фреймворк портов предоставляет следующие переменные, которые могут быть прочитаны портом:

`MPI_LIBS`

  Библиотеки, необходимые для связывания программ с использованием `MPI`.

`MPI_CFLAGS`

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

`MPICC`

  Расположение исполняемого файла `mpicc`. По умолчанию: ${MPI_HOME}/bin/mpicc.

`MPICXX`

  Расположение исполняемого файла `mpicxx`. По умолчанию: ${MPI_HOME}/bin/mpicxx.

`MPIF90`

  Расположение исполняемого файла `mpif90`. По умолчанию: ${MPI_HOME}/bin/mpif90.

`MPIFC`

  То же, что и выше.

`MPI_HOME`

  Каталог установки `MPI`. По умолчанию используется `${LOCALBASE}` для `MPICH`.

`MPIEXEC`

  Расположение исполняемого файла `mpiexec`. По умолчанию: ${MPI_HOME}/bin/mpiexec.

`MPIRUN`

  Расположение исполняемого файла `mpirun`. По умолчанию: ${MPI_HOME}/bin/mpirun.

## 17.86. `ncurses`

Возможные аргументы: (нет), `base`, `port`

Использует ncurses и устанавливает некоторые полезные переменные.

## 17.87. `nextcloud`

Возможные аргументы: (отсутствуют)

Добавляет поддержку приложений Nextcloud, добавляя зависимость во время выполнения на www/nextcloud.

## 17.88. `ninja`

Возможные аргументы: (нет), `build`, `make` (по умолчанию), `run`

Если указаны аргументы `build` или `run`, это соответственно добавляет зависимость во время сборки или выполнения от пакета devel/ninja. Если указан `make` или аргументы не предоставлены, используется ninja для сборки порта вместо make. `make` подразумевает `build`. Если переменная `NINJA_DEFAULT` установлена в `samurai`, тогда зависимости устанавливаются для пакета devel/samurai вместо этого.

## 17.89. `nodejs`

Возможные аргументы: (нет), `build`, `run`, `current`, `lts`, `10`, `14`, `16`, `17`.

Использует nodejs. Добавляет зависимость от пакета www/node*. Если указана поддерживаемая версия, то также необходимо указать `run` и/или `build`.

## 17.90. `objc`

Возможные аргументы: (отсутствуют)

Добавить зависимости Objective C (компилятор, библиотека времени выполнения), если базовая система их не поддерживает.

## 17.91. `ocaml`

Возможные аргументы: (нет), `build`, `camlp4`, `dune`, `findlib`, `findplist`, `ldconfig`, `run`, `tk`, `tkbuild`, `tkrun`, `wash`

Обеспечить поддержку OCaml.

Если аргументы не указаны, по умолчанию используются `build`, `run`.

Если указан аргумент `build`, то lang/ocamlc добавляется в `BUILD_DEPENDS`, `EXTRACT` и `PATCH_DEPENDS`.

Если указан аргумент `camlp4`, то для сборки используется devel/ocamlp4.

Если указан аргумент `dune`, то devel/ocaml-dune используется как система сборки.

Если указан аргумент `findlib`, то для установки пакетов будет использоваться `ocamlfind`. Каталоги пакетов будут автоматически удалены.

Если указан аргумент `findplist`, то содержимое целевых каталогов `findlib` будет добавлено автоматически.

Если указан аргумент `ldconfig`, то файл ld.conf OCaml будет обработан автоматически. При использовании `dune` Dune может устанавливать stublibs в каталог(-и) пакетов site-lib или в отдельный каталог ниже каталога `DUNE_LIBDIR` site-lib. Установите, если порт устанавливает общие библиотеки в ocaml

Если указан аргумент `run`, добавить ocamlc в `RUN_DEPENDS`.

Если указан аргумент `tk`, то в порт добавляется зависимость на сборку и выполнение от пакета x11-toolkits/ocaml-labltk. Подразумевает `tkbuild` и `tkrun`.

Если указан аргумент `tkbuild`, то пакет x11-toolkits/ocaml-labltk добавляется в `BUILD_DEPENDS`, `EXTRACT` и `PATCH_DEPENDS`.

Если указан аргумент `tkrun`, то x11-toolkits/ocaml-labltk добавляется в `RUN_DEPENDS`.

Если указан аргумент `wash`, общие каталоги Ocaml будут очищены при удалении. Полезно при установке в нестандартный `PREFIX`.

Портом могут быть установлены следующие переменные:

`OCAML_PKGDIRS`

  Каталоги в site-lib для обработки, если указан аргумент `findlib`. По умолчанию: `${PORTNAME}`

`OCAML_LDLIBS`

  Каталоги в `PREFIX`, которые будут автоматически добавлены/удалены из ld.conf. По умолчанию: `${OCAML_SITELIBDIR}/${PORTNAME}`

`OCAML_PACKAGES`

  Список пакетов для сборки и установки. По умолчанию `${PORTNAME}`

## 17.92. `octave`

Возможные аргументы: (нет), env

Использует math/octave. `env` загружает только одну переменную окружения `OCTAVE_VERSION`.

## 17.93. `openal`

Возможные аргументы: `al`, `soft` (по умолчанию), `si`, `alut`

Использует OpenAL. Бэкенд может быть указан, с программной реализацией по умолчанию. Пользователь может указать предпочтительный бэкенд с помощью `WANT_OPENAL`. Допустимые значения для этой настройки: `soft` (по умолчанию) и `si`.

## 17.94. `pathfix`

Возможные аргументы: (отсутствуют)

Ищите Makefile.in и configure в `PATHFIX_WRKSRC` (по умолчанию `WRKSRC`) и исправляйте стандартные пути, чтобы они соответствовали иерархии FreeBSD. Например, исправляется каталог установки для файлов .pc `pkgconfig` на ${PREFIX}/libdata/pkgconfig. Если порт использует `USES=autoreconf`, Makefile.am будет автоматически добавлен в `PATHFIX_MAKEFILEIN`.

Если порт `USES=cmake`, он будет искать файл CMakeLists.txt в `PATHFIX_WRKSRC`. При необходимости это имя файла по умолчанию можно изменить с помощью `PATHFIX_CMAKELISTSTXT`.

## 17.95. `pear`

Возможные аргументы: `env`

Добавляет зависимость от пакета devel/pear. Настраивает поведение по умолчанию для программного обеспечения, использующего PHP Extension and Application Repository. Использование аргументов `env` только устанавливает переменные окружения PEAR. Дополнительную информацию см. в Модули PEAR.

## 17.96. `perl5`

Возможные аргументы: (отсутствуют)

Зависит от Perl. Настройка выполняется с помощью `USE_PERL5`.

`USE_PERL5` может содержать фазы, в которых используется Perl: `extract`, `patch`, `build`, `run` или `test`.

`USE_PERL5` также может содержать `configure`, `modbuild` или `modbuildtiny`, если требуется Makefile.PL, Build.PL или вариант Build.PL для Module::Build::Tiny.

`USE_PERL5` по умолчанию имеет значение `build run`. При использовании `configure`, `modbuild` или `modbuildtiny`, `build` и `run` подразумеваются автоматически.

См. Использование Perl для получения дополнительной информации.

## 17.97. `pgsql`

Возможные аргументы: (нет), `X.Y`, `X.Y+`, `X.Y-`, `X.Y-Z.A`

Предоставить поддержку PostgreSQL. Ответственный за порт может указать требуемую версию. Можно указать минимальную и максимальную версии или диапазон; например, `9.0-`, `8.4+`, `8.4-9.2`

По умолчанию добавляемая зависимость будет клиентской, но если порту требуются дополнительные компоненты, это можно указать с помощью `WANT_PGSQL=компонент[:цель]`; например, `WANT_PGSQL=server:configure pltcl plperl`. Доступные компоненты:

- `client`

- `contrib`

- `docs`

- `pgtcl`

- `plperl`

- `plpython`

- `pltcl`

- `server`

## 17.98. `php`

Возможные аргументы: (нет), `phpize`, `ext`, `zend`, `build`, `cli`, `cgi`, `mod`, `web`, `embed`, `pecl`, `flavors`, `noflavors`

Обеспечить поддержку PHP. Добавить зависимость во время выполнения на версию PHP по умолчанию, lang/php81.

`phpize`

  Используется для создания расширения PHP. Поддерживает флейворы.

`ext`

  Используется для сборки, установки и регистрации расширения PHP. Поддерживает флейворы.

`zend`

  Используется для сборки, установки и регистрации Zend-расширения. Поддерживает флейворы.

`build`

  Установить PHP также как зависимость во время сборки.

`cli`

  Требуется версия PHP для командной строки.

`cgi`

  Требуется CGI-версия PHP.

`mod`

  Требуется модуль Apache для PHP.

`web`

  Требуется модуль Apache или CGI-версия PHP.

`embed`

  Требуется встроенная версия библиотеки PHP.

`pecl`

  Установить значения по умолчанию для загрузки расширений PHP из репозитория PECL. Включает флейворы.

`flavors`

  Включить автоматическую генерацию флейворов PHP. Флейворы будут созданы для всех версий PHP, за исключением указанных в `IGNORE_WITH_PHP`.

`noflavors`

  Отключить автоматическое создание флейворов PHP. Должно использоваться только с расширениями, предоставляемыми самим PHP.

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

`USE_PHP`

  Список необходимых расширений PHP во время выполнения. Добавьте `:build` к названию расширения, чтобы указать зависимость во время сборки. Пример: `pcre xml:build gettext`

`IGNORE_WITH_PHP`

  Порт не работает с PHP указанной версии. Возможные значения можно посмотреть в содержимом `_ALL_PHP_VERSIONS` в Mk/Uses/php.mk.

При сборке расширения PHP или Zend с помощью `:ext` или `:zend`, можно задать следующие переменные:

`PHP_MODNAME`

  Имя расширения PHP или Zend. Значение по умолчанию: `${PORTNAME}`.

`PHP_HEADER_DIRS`

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

`PHP_MOD_PRIO`

  Приоритет загрузки расширения. Это число от `00` до `99`.

  Для расширений, которые не зависят от других расширений, приоритет автоматически устанавливается в `20`, а для расширений, зависящих от другого расширения, приоритет автоматически устанавливается в `30`. Некоторые расширения могут требовать загрузки перед всеми остальными, например, www/php56-opcache. Некоторые могут требовать загрузки после расширения с приоритетом `30`. В таком случае добавьте `PHP_MOD_PRIO=XX` в Makefile порта. Например:

      USES=		php:ext
      USE_PHP=	wddx
      PHP_MOD_PRIO=	40

Эти переменные доступны для использования в `PKGNAMEPREFIX` или `PKGNAMESUFFIX`:

`PHP_PKGNAMEPREFIX`

  Содержит `php_XY_-`, где XY — версия PHP текущей редакции. Используется с расширениями и модулями PHP.

`PHP_PKGNAMESUFFIX`

  Содержит `-php_XY_`, где XY — версия PHP текущего варианта. Используется с PHP-приложениями.

`PECL_PKGNAMEPREFIX`

  Содержит `php_XY_-pecl-`, где XY — версия PHP текущей редакции. Используется с модулями PECL.

| С вариантами сборки все расширения PHP, расширения PECL, модули PEAR должны иметь разные имена пакетов, поэтому они должны использовать одну из трёх переменных в `PKGNAMEPREFIX` или `PKGNAMESUFFIX`.

## 17.99. `pkgconfig`

Возможные аргументы: (отсутствуют), `build` (по умолчанию), `run`, `both`

Использует devel/pkgconf. Без аргументов или с аргументом `build` подразумевает зависимость от `pkg-config` во время сборки. `run` подразумевает зависимость во время выполнения, а `both` — зависимости как во время выполнения, так и во время сборки.

## 17.100. `pure`

Возможные аргументы: (нет), `ffi`

Использует lang/pure. В основном применяется для сборки портов, зависящих от pure. С аргументом `ffi` подразумевает devel/pure-ffi как зависимость во время выполнения.

## 17.101. `pyqt`

Возможные аргументы: (нет), `4`, `5`

Использует PyQt. Если порт является частью самого PyQT, установите `PYQT_DIST`. Используйте `USE_PYQT` для выбора необходимых порту компонентов. Доступные компоненты:

- `core`

- `dbus`

- `dbussupport`

- `demo`

- `designer`

- `designerplugin`

- `doc`

- `gui`

- `multimedia`

- `network`

- `opengl`

- `qscintilla2`

- `sip`

- `sql`

- `svg`

- `test`

- `webkit`

- `xml`

- `xmlpatterns`

Эти компоненты доступны только с PyQT4:

- `assistant`

- `declarative`

- `help`

- `phonon`

- `script`

- `scripttools`

Эти компоненты доступны только с PyQT5:

- `multimediawidgets`

- `printsupport`

- `qml`

- `serialport`

- `webkitwidgets`

- `widgets`

Зависимость по умолчанию для каждого компонента — это время сборки и выполнения. Чтобы выбрать только сборку или выполнение, добавьте `_build` или `_run` к имени компонента. Например:

    USES=		pyqt
    USE_PYQT=	core doc_build designer_run

## 17.102. `pytest`

Возможные аргументы: (нет), 4

Вводит новую зависимость от devel/pytest. Он определяет цель `do-test`, которая будет правильно запускать тесты. Используйте аргумент, чтобы зависеть от определённой версии devel/pytest. Для портов, использующих devel/pytest, рекомендуется использовать это вместо конкретной цели `do-test`. Фреймворк предоставляет порту следующие переменные:

`PYTEST_ARGS`

  Дополнительные аргументы для pytest (по умолчанию пусто).

`PYTEST_IGNORED_TESTS`

  списки шаблонов `pytest -k` для игнорирования тестов (по умолчанию пустые). Для тестов, которые не должны проходить, например, требующих доступа к базе данных.

`PYTEST_BROKEN_TESTS`

  списки шаблонов `pytest -k` тестов для игнорирования (по умолчанию пустые). Для сломанных тестов, которые требуют исправления.

В дополнение следующие переменные могут быть заданы пользователем:

`PYTEST_ENABLE_IGNORED_TESTS`

  Включить тесты, которые в противном случае игнорируются `PYTEST_IGNORED_TESTS`.

`PYTEST_ENABLE_BROKEN_TESTS`

  Включить тесты, которые в противном случае игнорируются `PYTEST_BROKEN_TESTS`.

`PYTEST_ENABLE_ALL_TESTS`

  Включить тесты, которые в противном случае игнорируются `PYTEST_IGNORED_TESTS` и `PYTEST_BROKEN_TESTS`.

## 17.103. `python`

Возможные аргументы: (нет), `X.Y`, `X.Y+`, `-X.Y`, `X.Y-Z.A`, `patch`, `build`, `run`, `test`

Использует Python. Можно указать поддерживаемую версию или диапазон версий. Если Python требуется только во время сборки, выполнения или тестирования, его можно установить как зависимость для сборки, выполнения или тестирования с помощью `build`, `run` или `test`. Если Python также требуется на этапе исправлений, используйте `patch`. Дополнительную информацию см. в разделе Использование Python.

`USES=python:env` можно использовать, когда необходимы переменные, экспортируемые фреймворком, но зависимость от Python не требуется. Это может быть полезно при использовании с `USES=shebangfix`, если цель состоит только в исправлении shebang без добавления зависимости от Python.

## 17.104. `qmail`

Возможные аргументы: (нет), `build`, `run`, `both`, `vars`

Использует mail/qmail. С аргументом `build` подразумевается зависимость от `qmail` во время сборки. Аргумент `run` подразумевает зависимость во время выполнения. Использование без аргументов или с аргументом `both` подразумевает зависимости как во время выполнения, так и во время сборки. Аргумент `vars` только устанавливает переменные QMAIL для использования в порте.

## 17.105. `qmake`

Возможные аргументы: (отсутствуют), `norecursive`, `outsource`, `no_env`, `no_configure`

Использует QMake для настройки. Для получения дополнительной информации см. Использование `qmake`.

## 17.106. `qt`

Возможные аргументы: `5`, `6`, `no_env`

Добавить зависимость от компонентов Qt. `no_env` передаётся напрямую в `USES= qmake`. Подробнее см. в Использование Qt.

## 17.107. `qt-dist`

Возможные аргументы: (нет) или `5` и (нет) или `6` и (нет) или один из `3d`, `5compat`, `base`, `charts`, `connectivity`, `datavis3d`, `declarative`, `doc`, `languageserver`, `gamepad`, `graphicaleffects`, `imageformats`, `location`, `lottie`, `multimedia`, `networkauth`, `positioning`, `quick3d`, `quickcontrols2`, `quickcontrols`, `quicktimeline`, `remoteobjects`, `script`, `scxml`, `sensors`, `serialbus`, `serialport`, `shadertools`, `speech`, `svg`, `tools`, `translations`, `virtualkeyboard`, `wayland`, `webchannel`, `webengine`, `webglplugin`, `websockets`, `webview`, `x11extras`, `xmlpatterns`.

Предоставляет поддержку сборки компонентов Qt 5 и Qt 6. Обеспечивает настройку соответствующей конфигурации окружения для сборки порта.

Пример 7. Сборка компонентов Qt 5

Порт представляет собой компонент `networkauth` из Qt 5, который входит в файл дистрибутива `networkauth`.

    PORTNAME=	networkauth
    DISTVERSION=	${QT5_VERSION}

    USES=		qt-dist:5

Пример 8. Сборка компонентов Qt 6

Порт представляет собой компонент `websockets` из Qt 6, который входит в файл дистрибутива `websockets`.

    PORTNAME=       websockets
    PORTVERSION=    ${QT6_VERSION}

    USES=           qt-dist:6

Если `PORTNAME` не совпадает с именем компонента, его можно передать как аргумент в `qt-dist`.

Пример 9. Сборка компонентов Qt 5 с разными именами

Порт представляет собой компонент `gui` из Qt 5, который входит в файл дистрибутива `base`.

    PORTNAME=	gui
    DISTVERSION=	${QT5_VERSION}

    USES=		qt-dist:5,base

## 17.108. `readline`

Возможные аргументы: (нет), `port`

Использует readline в качестве зависимости библиотеки и устанавливает `CPPFLAGS` и `LDFLAGS` по необходимости. Если используется аргумент `port` или если readline отсутствует в базовой системе, добавляет зависимость от devel/readline

## 17.109. `ruby`

Возможные аргументы: (нет), `build`, `extconf`, `run`, `setup`

Предоставить поддержку для портов, связанных с Ruby. `(none)` без аргументов добавляет зависимость во время выполнения на lang/ruby. `build` добавляет зависимость на lang/ruby во время сборки. `extconf` указывает, что порт использует extconf.rb для настройки. `run` добавляет зависимость на lang/ruby во время выполнения. Это также значение по умолчанию. `setup` указывает, что порт использует setup.rb для настройки и сборки.

Пользователь может определить следующие переменные:

`RUBY_VER`

  Альтернативная короткая версия ruby в виде `x.y`.

`RUBY_DEFAULT_VER`

  Установите (например) `2.7`, чтобы использовать `ruby27` в качестве версии по умолчанию.

`RUBY_ARCH`

  Установите имя архитектуры (например, i386-freebsd7).

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

`RUBY`

  Установлена в полный путь к ruby. Если задано, значения следующих переменных автоматически получаются из исполняемого файла ruby: `RUBY_ARCH`, `RUBY_ARCHLIBDIR`, `RUBY_LIBDIR`, `RUBY_SITEARCHLIBDIR`, `RUBY_SITELIBDIR`, `RUBY_VER` и `RUBY_VERSION`

`RUBY_VER`

  Установлена в альтернативную короткую версию ruby в формате `x.y`.

`RUBY_EXTCONF`

  Установлена в альтернативное имя для extconf.rb (по умолчанию: extconf.rb).

`RUBY_EXTCONF_SUBDIRS`

  Установлена в список подкаталогов, если включено несколько модулей.

`RUBY_SETUP`

  Установлена в альтернативное имя для setup.rb (по умолчанию: setup.rb).

## 17.110. `samba`

Возможные аргументы: `build`, `env`, `lib`, `run`

Обработать зависимость от Samba. `env` не добавит никаких зависимостей, а только установит переменные. `build` и `run` добавят зависимости во время сборки и выполнения на smbd. `lib` добавит зависимость на libsmbclient.so. Экспортируемые переменные:

`SAMBA_PORT`

  Расположение порта Samba по умолчанию.

`SAMBA_INCLUDEDIR`

  Расположение заголовочных файлов Samba.

`SAMBA_LIBS`

  Каталог, в котором доступны общие библиотеки Samba.

`SAMBA_LDB_PORT`

  Расположение порта ldb, используемого выбранной версией Samba (например, databases/ldb28). Он должен использоваться, если порту требуется зависимость от той же версии ldb, что и у выбранной версии Samba.

`SAMBA_TALLOC_PORT`

  Расположение порта talloc, используемого выбранной версией Samba. Следует использовать, если порту требуется зависеть от той же версии talloc, что и выбранная версия Samba.

`SAMBA_TDB_PORT`

  Расположение порта TDB, используемого выбранной версией Samba. Его следует использовать, если порту требуется зависеть от той же версии TDB, что и выбранная версия Samba.

`SAMBA_TEVENT_PORT`

  Расположение порта tevent, используемого выбранной версией Samba. Это следует использовать, если порту необходимо зависеть от той же версии tevent, что и выбранная версия Samba.

## 17.111. `scons`

Возможные аргументы: (отсутствуют)

Предоставить поддержку для использования devel/scons. Дополнительную информацию смотрите в Использование `scons`.

## 17.112. `sdl`

Возможные аргументы: `sdl`

Обеспечить поддержку использования пакетов `SDL`. Переменная `USE_SDL` является обязательной и указывает, какие компоненты добавить в зависимости.

Поддерживаемые в настоящее время модули `SDL1.2`:

- sdl

- console

- gfx

- image

- mixer

- mm

- net

- pango

- sound

- ttf

Текущие поддерживаемые модули `SDL2`:

- sdl2

- gfx2

- image2

- mixer2

- net2

- sound2

- ttf2

Текущие поддерживаемые модули `SDL3`:

- sdl3

- image3

- ttf3

## 17.113. `shared-mime-info`

Возможные аргументы: (отсутствуют)

Использует update-mime-database из пакета misc/shared-mime-info. Это автоматически добавит шаг post-install таким образом, что сам порт всё ещё может указать собственный шаг post-install при необходимости. Также добавляет запись `@shared-mime-info` в plist.

## 17.114. `shebangfix`

Возможные аргументы: (отсутствуют)

Множество программ используют некорректные расположения для интерпретаторов скриптов, особенно /usr/bin/perl и /bin/bash. Макрос shebangfix исправляет строки shebang в скриптах, перечисленных в `SHEBANG_REGEX`, `SHEBANG_GLOB` или `SHEBANG_FILES`.

`SHEBANG_REGEX`

  Содержит одно расширенное регулярное выражение и используется с аргументом `-iregex` в find(1). См. `USESshebangfix` с `SHEBANG_REGEX`.

`SHEBANG_GLOB`

  Содержит список шаблонов, используемых с аргументом `-name` в find(1). См. `USESshebangfix` с `SHEBANG_GLOB`.

`SHEBANG_FILES`

  Содержит список файлов или шаблонов sh(1). Макрос shebangfix выполняется из `${WRKSRC}`, поэтому `SHEBANG_FILES` может содержать пути, относительные к `${WRKSRC}`. Также он может работать с абсолютными путями, если требуется исправление файлов вне `${WRKSRC}`. См. `USESshebangfix` с `SHEBANG_FILES`.

В настоящее время Bash, Java, Ksh, Lua, Perl, PHP, Python, Ruby, Tcl и Tk поддерживаются по умолчанию.

Существует три переменных конфигурации:

`SHEBANG_LANG`

  Список поддерживаемых интерпретаторов.

`_interp__CMD`

  Путь к интерпретатору команд в FreeBSD. Значение по умолчанию — `${LOCALBASE}/bin/interp`.

`_interp__OLD_CMD`

  Список неправильных вызовов интерпретаторов. Обычно это устаревшие пути или пути, используемые в других операционных системах, которые неверны в FreeBSD. Они будут заменены на правильные пути в `_interp__CMD`.

  | Эти пути всегда будут частью `interp__OLD_CMD`: `"/usr/bin/env _interp``" /bin/interp /usr/bin/interp /usr/local/bin/interp`.

  | `_interp__OLD_CMD` содержит несколько значений. Любая запись с пробелами должна быть заключена в кавычки. См. Указание всех путей при добавлении интерпретатора в `USESshebangfix`.

| Исправление шебанг-строк выполняется на этапе `patch`. Если скрипты создаются с некорректными шебанг-строками на этапе `build`, процесс сборки (например, скрипт configure или Makefiles) должен быть исправлен или ему должен быть указан правильный путь (например, с помощью `CONFIGURE_ENV`, `CONFIGURE_ARGS`, `MAKE_ENV` или `MAKE_ARGS`) для генерации корректных шебанг-строк. Правильные пути для поддерживаемых интерпретаторов доступны в `_interp__CMD`.

| При использовании с `USES=python`, если цель состоит только в исправлении shebang, но зависимость от самого Python не требуется, используйте `USES=python:env`.

Пример 10. Добавление другого интерпретатора в `USES=shebangfix`

Чтобы добавить другой интерпретатор, установите `SHEBANG_LANG`. Например:

    SHEBANG_LANG=	lua

Пример 11. Указание всех путей при добавлении интерпретатора в `USES=shebangfix`

Если они ещё не были определены и не было значений по умолчанию для `_interpOLD_CMD` и `_interp` `CMD`, запись Ksh можно определить как:

    SHEBANG_LANG=	ksh
    ksh_OLD_CMD=	"/usr/bin/env ksh" /bin/ksh /usr/bin/ksh
    ksh_CMD=	${LOCALBASE}/bin/ksh

Пример 12. Добавление нестандартного расположения интерпретатора

Некоторое программное обеспечение использует нестандартные пути для интерпретатора. Например, приложение может ожидать, что Python будет расположен в /opt/bin/python2.7. Нестандартный путь, который нужно заменить, можно указать в Makefile порта:

    python_OLD_CMD=	/opt/bin/python2.7

Пример 13. `USES=shebangfix` с `SHEBANG_REGEX`

Для исправления всех файлов в `${WRKSRC}/scripts`, оканчивающихся на .pl, .sh или .cgi, выполните:

    USES=	shebangfix
    SHEBANG_REGEX=	./scripts/.*\.(sh|pl|cgi)

| `SHEBANG_REGEX` используется при выполнении `find -E`, который применяет современные регулярные выражения, также известные как расширенные регулярные выражения. Подробнее см. в re_format(7).

Пример 14. `USES=shebangfix` с `SHEBANG_GLOB`

Для исправления всех файлов в `${WRKSRC}` с окончанием .pl или .sh выполните:

    USES=	shebangfix
    SHEBANG_GLOB=	*.sh *.pl

Пример 15. `USES=shebangfix` с `SHEBANG_FILES`

Для исправления файлов script/foobar.pl и script/*.sh в `${WRKSRC}` выполните:

    USES=	shebangfix
    SHEBANG_FILES=	scripts/foobar.pl scripts/*.sh

## 17.115. `sqlite`

Возможные аргументы: (нет), `2`, `3`

Добавить зависимость от SQLite. Используемая по умолчанию версия — 3, но также возможна версия 2 с использованием модификатора `:2`.

## 17.116. `sbrk`

Возможные аргументы: (отсутствуют)

Помечает порт как `BROKEN` для `aarch64` и `riscv64`.

## 17.117. `ssl`

Возможные аргументы: (нет), `build`, `run`

Обеспечить поддержку OpenSSL. Зависимость только для сборки или выполнения может быть указана с использованием `build` или `run`. Эти переменные доступны для использования портом, а также добавлены в `MAKE_ENV`:

`OPENSSLBASE`

  Путь к базовой установке OpenSSL.

`OPENSSLDIR`

  Путь к файлам конфигурации OpenSSL.

`OPENSSLLIB`

  Путь к библиотекам OpenSSL.

`OPENSSLINC`

  Путь к заголовочным файлам OpenSSL.

`OPENSSLRPATH`

  Если определено, путь, который требуется компоновщику для поиска библиотек OpenSSL.

| Если порт не собирается с вариантом OpenSSL, установите переменную `BROKEN_SSL`, а также, возможно, `BROKEN_SSL_REASON__flavor_`:
    BROKEN_SSL=	libressl
    BROKEN_SSL_REASON_libressl=	needs features only available in OpenSSL

## 17.118. `sudo`

Возможные аргументы: (отсутствуют)

Добавляет зависимость времени выполнения от security/sudo.

## 17.119. `tar`

Возможные аргументы: (нет), `Z`, `bz2`, `bzip2`, `lzma`, `tbz`, `tbz2`, `tgz`, `txz`, `xz`, `zst`, `zstd`

Установите `EXTRACT_SUFX` в `.tar`, `.tar.Z`, `.tar.bz2`, `.tar.bz2`, `.tar.lzma`, `.tbz`, `.tbz2`, `.tgz`, `.txz`, `.tar.xz`, `.tar.zst` или `.tar.zstd` соответственно.

## 17.120. `tcl`

Возможные аргументы: version, `wrapper`, `build`, `run`, `tea`

Добавьте зависимость от Tcl. Конкретная версия может быть запрошена с помощью version. Версия может быть пустой, одной или несколькими точными номерами версий (в настоящее время `84`, `85` или `86`), либо минимальным номером версии (в настоящее время `84+`, `85+` или `86+`). Чтобы запросить только неспецифичную для версии обёртку, используйте `wrapper`. Зависимость только на время сборки или выполнения может быть указана с помощью `build` или `run`. Для сборки порта с использованием Tcl Extension Architecture используйте `tea`. После включения bsd.port.pre.mk порт может проверить результаты с помощью этих переменных:

- `TCL_VER`: выбранная версия Tcl в формате major.minor

- `TCLSH`: полный путь к интерпретатору Tcl

- `TCL_LIBDIR`: путь к библиотекам Tcl

- `TCL_INCLUDEDIR`: путь к заголовочным файлам Tcl на языке C

- `TCL_PKG_LIB_PREFIX`: Префикс библиотеки, согласно TIP595

- `TCL_PKG_STUB_POSTFIX`: Постфикс библиотеки заглушки

- `TK_VER`: выбранная версия Tk в формате major.minor

- `WISH`: полный путь к интерпретатору Tk

- `TK_LIBDIR`: путь к библиотекам Tk

- `TK_INCLUDEDIR`: путь к заголовочным файлам Tk на языке C

## 17.121. `terminfo`

Возможные аргументы: (отсутствуют)

Добавляет `@terminfo` в файл plist. Используется, когда порт устанавливает файлы *.terminfo в каталог ${PREFIX}/share/misc.

## 17.122. `tex`

Возможные аргументы: (отсутствуют)

Обеспечить поддержку tex. Загружает все стандартные переменные для портов, связанных с TEX, и не добавляет зависимостей от других портов.

Переменные используются для указания того, какие модули TEX требуются.

`USE_TEX`

  Список необходимых расширений TEX во время выполнения. Добавьте `:build` к названию расширения, чтобы добавить зависимость на время сборки, `:run` — для зависимости во время выполнения, `:test` — для зависимости во время тестирования, `:extract` — для зависимости во время извлечения. Пример: `base texmf:build source:run`

Текущие возможные аргументы следующие:

- `base`

- `texmf`

- `source`

- `docs`

- `web2c`

- `kpathsea`

- `ptexenc`

- `basic`

- `tlmgr`

- `texlua`

- `texluajit`

- `synctex`

- `xpdfopen`

- `dvipsk`

- `dvipdfmx`

- `xdvik`

- `gbklatex`

- `formats`

- `tex`

- `latex`

- `pdftex`

- `jadetex`

- `luatex`

- `ptex`

- `xetex`

- `xmltex`

- `texhash`

- `updmap`

- `fmtutil`

## 17.123. `tk`

Так же, как аргументы для `tcl`

Небольшая обёртка при использовании Tcl и Tk. Возвращаются те же переменные, что и при использовании Tcl.

## 17.124. `trigger`

Возможные аргументы: (отсутствуют)

Предоставить поддержку для портов, требующих выполнения триггеров с помощью pkg(8). Триггеры выполняются в конце транзакции, если условия выполнены.

Следующая переменная может быть установлена портами:

`TRIGGERS`

  Список триггеров для пакета. По умолчанию используется `${PORTNAME}`.

Триггеры указываются в формате UCL и обычно размещаются в каталоге files/ порта.

## 17.125. `uidfix`

Возможные аргументы: (отсутствуют)

Изменяет некоторые стандартные настройки (в основном переменные) системы сборки, чтобы позволить установку этого порта обычным пользователем. Попробуйте это в порте перед использованием `USES=fakeroot` или исправлением.

## 17.126. `uniquefiles`

Возможные аргументы: (нет), `dirs`

Сделать файлы или каталоги 'уникальными', добавляя префикс или суффикс. Если используется аргумент `dirs`, порту требуется префикс (и только префикс) на основе `UNIQUE_PREFIX` для стандартных каталогов `DOCSDIR`, `EXAMPLESDIR`, `DATADIR`, `WWWDIR`, `ETCDIR`. Эти переменные доступны для портов:

- `UNIQUE_PREFIX`: Префикс, используемый для каталогов и файлов. По умолчанию: `${PKGNAMEPREFIX}`.

- `UNIQUE_PREFIX_FILES`: Список файлов, которые необходимо предварить префиксом. По умолчанию: пусто.

- `UNIQUE_SUFFIX`: Суффикс, используемый для файлов. По умолчанию: `${PKGNAMESUFFIX}`.

- `UNIQUE_SUFFIX_FILES`: Список файлов, к которым необходимо добавить суффикс. По умолчанию: пусто.

## 17.127. `vala`

Возможные аргументы: `build`, `lib`, `no_depend`

Добавляет зависимости сборки или библиотеки на lang/vala. Аргумент `no_depend` зарезервирован для самого lang/vala.

## 17.128. `varnish`

Возможные аргументы: `4` (по умолчанию), `6`, `7`

Обрабатывает зависимости для Varnish Cache. Добавляет зависимость от пакета `www/varnish*`.

## 17.129. `waf`

Возможные аргументы: (отсутствуют)

Обеспечить поддержку портов, использующих систему сборки `waf`.

Это подразумевает `USES=python:build`.

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

`WAF_CMD`

  Расположение скрипта `waf`. Установите этот параметр, если скрипт `waf` не находится в WRKSRC/waf.

`CONFIGURE_TARGET`

  Цель для `configure`. По умолчанию – `configure`.

`ALL_TARGET`

  Цель для `all`. По умолчанию `build`.

`INSTALL_TARGET`

  Цель для `install`. По умолчанию `install`.

## 17.130. `webplugin`

Возможные аргументы: (нет), `ARGS`

Автоматически создавать и удалять символические ссылки для каждого приложения, поддерживающего фреймворк webplugin. `ARGS` может быть одним из:

- `gecko`: поддержка плагинов на основе Gecko

- `native`: поддержка плагинов для Gecko, Opera и WebKit-GTK

- `linux`: поддержка Linux плагинов

- `all` (по умолчанию, неявно): поддержка всех типов плагинов

- (отдельные записи): поддерживаются только перечисленные браузеры

Эти переменные можно настроить:

- `WEBPLUGIN_FILES`: Значение по умолчанию отсутствует, должно быть установлено вручную. Файлы плагинов для установки.

- `WEBPLUGIN_DIR`: Каталог для установки файлов плагина, по умолчанию PREFIX/lib/browser_plugins/WEBPLUGIN_NAME. Установите это значение, если порт устанавливает файлы плагина вне стандартного каталога, чтобы избежать битых символических ссылок.

- `WEBPLUGIN_NAME`: Конечный каталог для установки файлов плагина, по умолчанию `PKGBASE`.

## 17.131. `xfce`

Возможные аргументы: (нет), `gtk2`

Предоставить поддержку для портов, связанных с Xfce. Подробности см. в Использование Xfce.

Аргумент `gtk2` указывает, что порт требует поддержки GTK2. Он добавляет дополнительные возможности, предоставляемые некоторыми основными компонентами, например, x11/libxfce4menu и x11-wm/xfce4-panel.

## 17.132. `xorg`

Возможные аргументы: (отсутствуют)

Предоставляет простой способ зависеть от компонентов X.org. Компоненты должны быть перечислены в `USE_XORG`. Доступные компоненты:

Таблица 1. Доступные компоненты X.Org
Имя | Описание
--- | ---
`dmx` | Библиотека расширений DMX
`fontenc` | Библиотека fontenc
`fontutil` | Создать индекс файлов шрифтов X в каталоге
`ice` | Библиотека Inter Client Exchange для X11
`libfs` | Библиотека FS
`pciaccess` | Универсальная библиотека доступа к PCI
`pixman` | Библиотека для низкоуровневого управления пикселями
`sm` | Библиотека управления сеансами для X11
`x11` | Библиотека X11
`xau` | Библиотека протокола аутентификации для X11
`xaw` | Библиотека X Athena Widgets
`xaw6` | Библиотека X Athena Widgets
`xaw7` | Библиотека X Athena Widgets
`xbitmaps` | Данные растровых изображений X.Org
`xcb` | Библиотека с интерфейсом языка С для X протокола (XCB)
`xcomposite` | Библиотека расширения X Composite
`xcursor` | X библиотека загрузки курсоров на стороне клиента
`xdamage` | Библиотека расширения X Damage
`xdmcp` | Библиотека протокола управления дисплейным менеджером X (XDMCP)
`xext` | Библиотека расширений X11
`xfixes` | Библиотека расширений X Fixes
`xfont` | Библиотека шрифтов X
`xfont2` | Библиотека шрифтов X
`xft` | Клиентский API шрифтов для приложений X
`xi` | Библиотека расширения X Input
`xinerama` | Библиотека X11 Xinerama
`xkbfile` | Библиотека файлов XKB
`xmu` | Библиотека X Miscellaneous Utilities
`xmuu` | Библиотека X Miscellaneous Utilities
`xorg-macros` | X.Org макросы разработки aclocal
`xorg-server` | Сервер X.Org X и относящиеся к нему программы
`xorgproto` | Заголовочные файлы протокола xorg
`xpm` | Библиотека X Pixmap
`xpresent` | Библиотека расширений X Present
`xrandr` | Библиотека расширений X Resize and Rotate
`xrender` | Библиотека расширения X Render
`xres` | Библиотека мониторинга ресурсов X Resource usage
`xscrnsaver` | Библиотека XScrnSaver
`xshmfence` | Примитив синхронизации "SyncFence" в разделяемой памяти
`xt` | Библиотека X Toolkit
`xtrans` | Абстрактный сетевой код для X
`xtst` | Расширение X Test
`xv` | Библиотека расширения X Video
`xvmc` | Библиотека X Video Extension Motion Compensation
`xxf86dga` | Расширение X DGA
`xxf86vm` | Расширение X Vidmode

## 17.133. `xorg-cat`

Возможные аргументы: `app`, `data`, `doc`, `driver`, `font`, `lib`, `proto`, `util`, `xserver` и (без аргументов) или один из `autotools` (по умолчанию), `meson`

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

Категория должна соответствовать категориям вышестоящего репозитория.

Второй аргумент — используемая система сборки. По умолчанию используется `autotools`, но также поддерживается `meson`.

## 17.134. `zig`

Возможные аргументы: (отсутствуют)

Обеспечить поддержку построения портов на основе lang/zig.

Фреймворк предоставляет следующие переменные порту:

`ZIG_TUPLE`

  Список зависимостей zig, необходимых для сборки порта. Каждая запись представляет собой триплет из имени, URL-адреса и каталога, где ожидается найти зависимость. Эти триплеты можно сгенерировать, выполнив команду:

    % make make-zig-tuple

## 17.135. `zip`

Возможные аргументы: (нет), `infozip`

Указывает, что файлы дистрибутива используют алгоритм сжатия ZIP. Для файлов, использующих алгоритм InfoZip, необходимо передать аргумент `infozip`, чтобы установить соответствующие зависимости.

Изменено: 15 марта 2026 г. by Vladlen Popolitov

Назад
Главная
Далее