NO_MTREE= yes
Глава 6. Особые соглашения
Этот перевод может быть устаревшим. Для того, чтобы помочь с переводом, пожалуйста, обратитесь к Сервер переводов FreeBSD.
Содержание
Имеется ещё несколько вещей, которые вы должны иметь в виду при создании порта. Этот раздел описывает наиболее часто встречающиеся из них.
6.1. Разделение длинных файлов
Иногда Makefiles могут быть очень длинными. Например, порты rust могут содержать очень длинный список CARGO_CRATES
. В других случаях Makefile может содержать код, который варьируется в зависимости от архитектуры. В таких ситуациях может быть удобно разделить исходный Makefile на несколько файлов. bsd.port.mk автоматически включает некоторые типы Makefiles в основной Makefile порта.
Вот файлы, которые система обрабатывает автоматически, если они обнаружены:
Makefile.crates. Пример можно найти в пакете audio/ebur128.
Makefile.inc. Пример можно найти в пакете net/ntp.
Makefile.${ARCH}-${OPSYS}
Makefile.${OPSYS}. Пример можно найти в пакете net/cvsup-static.
Makefile.${ARCH}
Makefile.local
Также распространённой практикой является разделение списка пакетов порта на несколько файлов, если список сильно различается в зависимости от архитектуры или выбранного флейвора. В этом случае файл pkg-plist для каждой архитектуры именуется по шаблону pkg-plist.${ARCH} или pkg-plist.${FLAVOR}. Фреймворк не создаёт список пакетов автоматически, если существует несколько файлов pkg-plist. Ответственность за выбор подходящего файла pkg-plist и его присвоение переменной PLIST
лежит на того, кто делает порт. Примеры работы с этим можно найти в портах audio/logitechmediaserver и deskutils/libportal.
6.2. Staging
bsd.port.mk ожидает, что порты будут работать с "директорией стадии". Это означает, что порт не должен устанавливать файлы напрямую в обычные целевые директории (например, под PREFIX
), а вместо этого в отдельную директорию, из которой затем собирается пакет. Во многих случаях это не требует прав root, что позволяет собирать пакеты от имени непривилегированного пользователя. При использовании стадии порт собирается и устанавливается в директорию стадии STAGEDIR
. Пакет создаётся из директории стадии и затем устанавливается в систему. Инструменты Automake называют эту концепцию DESTDIR
, но в FreeBSD DESTDIR
имеет другое значение (см. PREFIX
и DESTDIR
).
Ни один порт на самом деле не должен работать от root. Этого в большинстве случаев можно избежать, используя |
Метапорты, то есть порты, которые не устанавливают файлы непосредственно, а только зависят от других портов, должны по возможности избегать распаковки mtree(8) в каталог сборки. Это основная иерархия каталогов пакета, и эти пустые каталоги будут выглядеть лишними. Для предотвращения распаковки mtree(8) добавьте эту строку:
Метапорты должны использовать |
Этап подготовки включается путем добавления STAGEDIR
к путям, используемым в целях pre-install
, do-install
и post-install
(см. примеры в книге). Обычно это включает PREFIX
, ETCDIR
, DATADIR
, EXAMPLESDIR
, DOCSDIR
и т. д. Каталоги должны создаваться как часть цели post-install
. По возможности избегайте использования абсолютных путей.
Порты, которые устанавливают модули ядра, должны добавлять |
6.2.1. Обработка символических ссылок
При создании символической ссылки настоятельно рекомендуется использовать относительные пути. Используйте ${RLN}
для создания относительных символических ссылок. Эта команда использует install(1) для автоматического определения относительной ссылки, которую нужно создать.
${RLN}
использует относительную символическую ссылку из install(1), что освобождает сборщика порта от вычисления относительного пути.
${RLN} ${STAGEDIR}${PREFIX}/lib/libfoo.so.42 ${STAGEDIR}${PREFIX}/lib/libfoo.so ${RLN} ${STAGEDIR}${PREFIX}/libexec/foo/bar ${STAGEDIR}${PREFIX}/bin/bar ${RLN} ${STAGEDIR}/var/cache/foo ${STAGEDIR}${PREFIX}/share/foo
Будет создано:
% ls -lF ${STAGEDIR}${PREFIX}/lib
lrwxr-xr-x 1 nobody nobody 181 Aug 3 11:27 libfoo.so@ -> libfoo.so.42
-rwxr-xr-x 1 nobody nobody 15 Aug 3 11:24 libfoo.so.42*
% ls -lF ${STAGEDIR}${PREFIX}/bin
lrwxr-xr-x 1 nobody nobody 181 Aug 3 11:27 bar@ -> ../libexec/foo/bar
% ls -lF ${STAGEDIRDIR}${PREFIX}/share
lrwxr-xr-x 1 nobody nobody 181 Aug 3 11:27 foo@ -> ../../../var/cache/foo
6.3. Встроенные библиотеки
Этот раздел объясняет, почему встроенные зависимости считаются плохими и что с этим делать.
6.3.1. Почему встроенные библиотеки — это плохо
Некоторое программное обеспечение требует от упаковщика найти сторонние библиотеки и добавить необходимые зависимости в порт. Другое ПО включает все необходимые библиотеки в дистрибутивный файл. Второй подход кажется проще на первый взгляд, но имеет серьёзные недостатки:
Этот список частично основан на вики Fedora и Gentoo, оба распространяются по лицензии CC-BY-SA 3.0.
- Безопасность
Если уязвимости обнаружены в вышестоящей библиотеке и исправлены там, они могут остаться неисправленными в библиотеке, поставляемой с портом. Одной из причин может быть то, что автор не знает о проблеме. Это означает, что портировщик должен исправить их или обновить до не уязвимой версии и отправить исправление автору. Всё это требует времени, что приводит к тому, что программное обеспечение остаётся уязвимым дольше, чем необходимо. Это, в свою очередь, затрудняет координацию исправления без неоправданного раскрытия информации об уязвимости.
- Ошибки
Эта проблема аналогична проблеме с безопасностью в последнем абзаце, но в целом менее серьезная.
- Ветвление
Автору проще создать форк upstream-библиотеки после её включения в дистрибутив. Хотя на первый взгляд это кажется удобным, такой подход приводит к расхождению кода с исходным репозиторием, что усложняет исправление уязвимостей и других проблем в ПО. Одна из причин — затруднённое применение патчей.
Еще одна проблема форкинга заключается в том, что из-за расхождения кода с основной веткой, ошибки исправляются снова и снова, вместо того чтобы быть исправленными один раз в центральном месте. Это противоречит самой идее открытого программного обеспечения.
- Конфликты символов
Когда библиотека установлена в системе, может возникнуть конфликт с встроенной в порт версией. Это может привести к немедленным ошибкам во время компиляции или компоновки. Также могут возникать ошибки при запуске программы, которые сложнее отследить. Последняя проблема может быть вызвана несовместимостью версий двух библиотек.
- Лицензирование
При объединении проектов из различных источников могут возникать проблемы с лицензиями, особенно если лицензии несовместимы.
- Растрата ресурсов
Библиотеки, поставляемые в комплекте, растрачивают ресурсы на нескольких уровнях. Сборка самого приложения занимает больше времени, особенно если эти библиотеки уже присутствуют в системе. Во время выполнения они могут занимать дополнительную память, когда общесистемная библиотека уже загружена одной программой, а входящая в комплект библиотека загружена другой программой.
- Пустая трата усилий
Когда библиотеке требуются патчи для FreeBSD, эти патчи приходится дублировать в составе библиотеки. Это приводит к потере времени разработчиков, поскольку патчи могут применяться некорректно. Кроме того, бывает сложно сразу заметить, что эти патчи вообще необходимы.
6.3.2. Что делать со встроенными библиотеками
По возможности используйте независимую версию библиотеки, добавив LIB_DEPENDS
в порт. Если такого порта ещё не существует, рассмотрите возможность его создания.
Используйте встроенные библиотеки только в том случае, если разработчик имеет хорошую репутацию в вопросах безопасности, а использование внешних версий приводит к излишне сложным исправлениям.
В некоторых особых случаях, например, для эмуляторов, таких как Wine, порт должен включать библиотеки, потому что они предназначены для другой архитектуры или были изменены для использования в данном программном обеспечении. В таком случае эти библиотеки не должны быть доступны для связывания с другими портами. Добавьте |
6.4. Динамические библиотеки
Если ваш порт устанавливает одну или несколько динамических библиотек, определите переменную USE_LDCONFIG
, которая приведёт к запуску из bsd.port.mk команды ${LDCONFIG} -m
относительно каталога, в который устанавливается новая библиотека (как правило, это PREFIX/lib), во время выполнения цели post-install
для её регистрации в кэше динамических библиотек. Эта переменная, если она определена, также приведёт к добавлению соответствующей пары команд @exec /sbin/ldconfig -m
и @unexec /sbin/ldconfig -R
в ваш файл pkg-plist, так что пользователь, устанавливающий пакет, сможет сразу же использовать динамическую библиотеку, а удаление пакета не приведёт к тому, что система будет предполагать, что библиотека всё ещё имеется в наличии.
USE_LDCONFIG= yes
Если нужно, вы можете переопределить каталог по умолчанию, задав значение USE_LDCONFIG
, в котором должны быть перечислены каталоги, в которые устанавливаются динамические библиотеки. Например, если ваш порт устанавливает динамические библиотеки в каталоги PREFIX/lib/foo и PREFIX/lib/bar, то вы можете в файле Makefile указать следующее:
USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar
Будьте добры перепроверить, т.к. часто это вовсе не является необходимым и может быть решено иначе с помощью -rpath
или установки LD_RUN_PATH
во время компоновки (для примера смотрите lang/moscow_ml), или с помощью сценария-обёртки, который выставляет LD_LIBRARY_PATH
перед запуском исполняемого файла как это делает www/seamonkey.
При установке 32-разрядных библиотек на 64-разрядной системе используйте вместо этого USE_LDCONFIG32
.
Если программное обеспечение использует autotools, в частности libtool
, добавьте USES=libtool
.
Если при обновлении порта увеличивается старший номер версии библиотеки, то для всех портов, компонуемых с затронутой библиотекой, следует увеличить значение PORTREVISION
для форсирования перекомпиляции с новой версией библиотеки.
6.5. Порты с ограничениями на распространение или с правовым обременением
Лицензии бывают разных видов, и некоторые накладывают ограничение на то, как приложение может быть оформлено в виде пакета, может ли оно продаваться для извлечения коммерческой выгоды, и так далее.
На вас, как на человека, портирующего приложение, ложится обязанность прочесть лицензионные соглашения на программное обеспечение и удостовериться, что проект FreeBSD не будет являться их нарушителем, если будет заниматься распространением исходного кода или в бинарном виде по FTP/HTTP или на CD-ROM. Если у вас возникли сомнения, то, пожалуйста, обратитесь в Список рассылки, посвящённый Портам FreeBSD. |
В подобных ситуациях можно использовать переменные, описываемые в последующих разделах.
6.5.1. NO_PACKAGE
Эта переменная указывает, что мы не можем создавать для приложения двоичный пакет. К примеру, лицензия не позволяет бинарное распространение или она может запрещать распространение пакетов, созданных из изменённых исходников.
Однако файлы DISTFILES
могут свободно зеркалироваться по FTP/HTTP. Они также могут распространяться, используя CD-ROM (или на похожих носителях), если не установлена переменная NO_CDROM
.
NO_PACKAGE
должна также использоваться, если двоичный пакет, как правило, бесполезен, а приложение должно всегда компилироваться из исходного кода. К примеру, если в приложение во время компиляции жёстко включается конфигурационная информация, привязанная к конкретной системе, то задайте переменную NO_PACKAGE
.
Значением переменной NO_PACKAGE
должна быть строка, описывающая причину, по которой пакет не должен создаваться.
6.5.2. NO_CDROM
Эта переменная указывает на то, что, хотя мы имеем право создавать бинарные пакеты, мы не можем помещать эти пакеты или файлы DISTFILES
порта на CD-ROM (или на похожие носители) для перепродажи. Однако бинарные пакеты и файлы DISTFILES
порта будут оставаться доступными посредством FTP/HTTP.
Если эта переменная устанавливается вместе с NO_PACKAGE
, то только файлы порта DISTFILES
будут доступны, и только посредством FTP/HTTP.
В качестве значения NO_CDROM
должна указываться строка, описывающая причины, по которым порт не может распространяться на CD-ROM. К примеру, это применяется, если лицензионное соглашение приложения предполагает только его "некоммерческое" использование.
6.5.3. NOFETCHFILES
Файлы, определенные в переменной NOFETCHFILES
, не будут извлекаться ни из одного из MASTER_SITES
. Примером такого файла является файл, поставляемый на CD-ROM.
Инструменты, проверяющие доступность этих файлов на MASTER_SITES
, должны игнорировать эти файлы и не сообщать о них.
6.5.4. RESTRICTED
Задайте эту переменную, если лицензия на приложение не позволяет ни зеркалировать файлы DISTFILES
, ни распространять бинарный пакет через FTP/HTTP или на CD-ROM.
Ни NO_CDROM
, ни NO_PACKAGE
не стоит устанавливать вместе с RESTRICTED
, так как последняя переменная подразумевает первые две.
В качестве значения RESTRICTED
должна указываться строка, описывающая причины, по которым порт нельзя распространять. Обычно это означает, что порт использует закрытое программное обеспечение, а пользователь должен вручную сгрузить файлы DISTFILES
, возможно, после заполнения регистрационной формы или подтверждения соглашения с условиями EULA.
6.5.5. RESTRICTED_FILES
Если заданы RESTRICTED
или NO_CDROM
, то значение этой переменной по умолчанию соответствует ${DISTFILES} ${PATCHFILES}
, в противном случае она пуста. Если ограничены в распространении лишь некоторые из дистрибутивных файлов, то в этой переменной задаётся их список.
6.5.6. LEGAL_TEXT
Если порт имеет правовое обременение, которое не покрывается перечисленными выше переменными, то переменной LEGAL_TEXT
следует присвоить строку с описанием данного обременения. Например, если было получено особое разрешение для FreeBSD на распространение двоичного файла, то эта переменная должна содержать соответствующее указание.
6.5.7. /usr/ports/LEGAL и LEGAL
Порт, содержащий любую из перечисленных выше переменных, также должен быть добавлен в /usr/ports/LEGAL. Первый столбец содержит шаблон совпадения с дистрибутивными файлами, имеющими ограничения на распространение. Второй столбец содержит корень порта. Третий столбец содержит вывод make -VLEGAL
.
6.5.8. Примеры
Предпочтительным способом реализации утверждения "архивы исходных текстов для этого порта должны загружаться самостоятельно" является следующее:
.if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX}) IGNORE= may not be redistributed because of licensing reasons. Please visit some-website to accept their license and download ${DISTFILES} into ${DISTDIR} .endif
Это одновременно и информирует пользователя, и устанавливает нужные метаданные на пользовательской машине для использования автоматическими программами.
Обратите внимание, что данная кляуза должна предшествовать подключению файла bsd.port.pre.mk.
6.6. Механизмы построения
6.6.1. Параллельное построение портов
Инфраструктура портов FreeBSD поддерживает параллельное построение с использованием множественных подпроцессов make
, что позволяет системам SMP задействовать всю доступную мощность CPU, тем самым делая построение портов более быстрым и эффективным.
Это достигается путём передачи флага -jX
команде make(1). Такое построение портов является поведением по умолчанию. К сожалению, не все порты поддерживают параллельную сборку достаточно хорошо, и поэтому может потребоваться выключить этот механизм явным образом путём добавления переменной MAKE_JOBS_UNSAFE=yes
. Эта переменная используется в случае, когда известно, что порт ломается с -jX
.
При установке |
6.6.2. make
, gmake
и imake
Существует несколько различных реализаций make
. Переносимому программному обеспечению часто требуется конкретная реализация, например GNU make
, известная в FreeBSD как gmake
.
Если порт использует GNU make, добавьте gmake
в USES
.
MAKE_CMD
может использоваться для ссылки на конкретную команду, настроенную параметром USES
в Makefile порта. Используйте MAKE_CMD
только внутри Makefile приложения в WRKSRC
для вызова реализации make
, ожидаемой портируемым программным обеспечением.
Если ваш порт является приложением X, которое создает файлы Makefile из Imakefile, используя imake, то установите USES= imake
. Это заставит стадию конфигурирования автоматически выполнить xmkmf -a
. Если флаг -a
представляет для вашего порта проблему, то установите XMKMF=xmkmf
. Если порт использует imake, но не понимает цель install.man
, то следует установить NO_INSTALL_MANPAGES=yes
.
Если исходный Makefile вашего порта имеет что-нибудь помимо all
в качестве основной цели построения, то задайте соответствующее значение ALL_TARGET
. То же касается install
и INSTALL_TARGET
.
6.6.3. Сценарий configure
Если ваш порт использует сценарий configure
для получения файлов Makefile из файлов Makefile.in, то установите GNU_CONFIGURE=yes
. Если вы хотите дать дополнительные параметры сценарию configure
(аргументом по умолчанию является --prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH} --mandir=${MANPREFIX}/man --build=${CONFIGURE_TARGET}
), установите эти параметры в CONFIGURE_ARGS
. Дополнительные переменные окружения можно передать, используя переменную CONFIGURE_ENV
.
Переменная | Значение |
---|---|
| Порт использует сценарий |
| То же, что и |
| Дополнительные параметры, передаваемые сценарию |
| Дополнительные переменные окружения, задаваемые для запуска сценария |
| Переопределить цель configure по умолчанию. Значением по умолчанию является |
6.6.4. Использование cmake
Если порт использует CMake, определите USES= cmake
.
Переменная | Значение |
---|---|
| Специфичные для порта флаги CMake, передаваемые в бинарный файл |
| Для каждой записи в |
| Для каждой записи в |
| Тип сборки (предопределённые профили сборки CMake). По умолчанию |
| Путь к исходному каталогу. По умолчанию |
| Дополнительные переменные окружения, которые должны быть установлены для бинарного файла |
Переменная | Значение |
---|---|
| Запрещает цветной вывод сообщений при построении. Значение по умолчанию не задано, если не заданы |
CMake поддерживает следующие профили построения: Debug
, Release
, RelWithDebInfo
и MinSizeRel
. Профили Debug
и Release
учитывают системные флаги *FLAGS
; RelWithDebInfo
и MinSizeRel
соответственно определяют CFLAGS
со значением -O2 -g
и -Os -DNDEBUG
. Значение CMAKE_BUILD_TYPE
экспортируется в нижнем регистре в PLIST_SUB
и должно использоваться, если порт устанавливает файлы *.cmake
в зависимости от типа построения (для примера посмотрите на deskutils/strigi). Следует учитывать, что некоторые проекты могут определять собственные профили построения и/или форсировать конкретный тип построения через установку CMAKE_BUILD_TYPE
в файлах CMakeLists.txt. Для того чтобы порт для такого проекта учитывал CFLAGS
и WITH_DEBUG
, из этих файлов должны быть удалены значения CMAKE_BUILD_TYPE
.
Большинство проектов, основанных на CMake, поддерживают метод внешнего (out-of-source) построения. Для порта внешнее построение можно запросить с использованием суффикса :outsource
. В этом случае CONFIGURE_WRKSRC
, BUILD_WRKSRC
и INSTALL_WRKSRC
будут иметь значение ${WRKDIR}/.build
для каталога, содержащего файлы, получаемые на этапах конфигурации и построения; при этом каталог с исходным кодом будет оставаться без изменений.
USES= cmake
Следующий отрывок демонстрирует использование CMake для порта. CMAKE_SOURCE_PATH
обычно не требуется, но может быть установлен, когда исходный код не находится в верхнем каталоге или если порт используется для построения части проекта.
USES= cmake CMAKE_SOURCE_PATH= ${WRKSRC}/subproject
CMAKE_ON
и CMAKE_OFF
При добавлении логических значений в CMAKE_ARGS
проще использовать переменные CMAKE_ON
и CMAKE_OFF
вместо этого. Это:
CMAKE_ON= VAR1 VAR2 CMAKE_OFF= VAR3
Эквивалентно:
CMAKE_ARGS= -DVAR1:BOOL=TRUE -DVAR2:BOOL=TRUE -DVAR3:BOOL=FALSE
Это относится только к значениям по умолчанию в |
6.6.5. Использование scons
Если порт использует SCons, определите USES=scons
.
Чтобы сторонний SConstruct учитывал все, что передается в SCons через окружение (то есть, что наиболее важно, CC/CXX/CFLAGS/CXXFLAGS
), исправьте SConstruct, чтобы сборка Environment
создавалась следующим образом:
env = Environment(**ARGUMENTS)
Он может быть изменён с помощью env.Append
и env.Replace
.
6.6.6. Сборка приложений на Rust с помощью cargo
Для портов, использующих Cargo, определите USES=cargo
.
Переменная | По умолчанию | Описание |
---|---|---|
| Список ящиков (crates), от которых зависит порт. Каждая запись должна быть в формате | |
| Список функций приложения для сборки (список через пробел). Чтобы отключить все функции по умолчанию, добавьте специальный токен | |
|
| Путь к файлу Cargo.toml, который следует использовать. |
|
| Путь к файлу Cargo.lock, используемому для |
| Список переменных окружения, передаваемых в Cargo, аналогично | |
| Флаги для передачи компилятору Rust. | |
|
| Используйте стандартный |
| Дополнительные аргументы для передачи Cargo во время фазы настройки. Допустимые аргументы можно посмотреть с помощью | |
|
| Добавить зависимость сборки на lang/rust. |
|
| Расположение бинарного файла |
|
| Используйте значение по умолчанию |
| Дополнительные аргументы для передачи Cargo во время фазы сборки. Допустимые аргументы можно посмотреть с помощью | |
|
| Используйте настройку |
| Дополнительные аргументы для передачи Cargo во время фазы установки. Допустимые аргументы можно посмотреть с помощью | |
|
| Путь к пакету для установки. Этот аргумент передается в |
|
| Используйте значение по умолчанию |
| Дополнительные аргументы для передачи Cargo во время тестовой фазы. Допустимые аргументы можно посмотреть с помощью | |
|
| Расположение выходного каталога cargo. |
| rust/crates | Каталог относительно |
|
| Расположение каталога сторонних поставщиков ПО, в который будут извлечены все крейты. Старайтесь держать его в пределах |
|
| Включить загрузку крейтов, привязанных к определённым коммитам Git на GitHub, с помощью |
|
| То же, что и |
Создание порта на основе Cargo — это процесс из трёх этапов. Сначала необходимо предоставить шаблон портов, который загружает дистрибутивный файл приложения:
PORTNAME= tokei DISTVERSIONPREFIX= v DISTVERSION= 7.0.2 CATEGORIES= devel MAINTAINER= tobik@FreeBSD.org COMMENT= Display statistics about your code WWW= https://github.com/XAMPPRocky/tokei/ USES= cargo USE_GITHUB= yes GH_ACCOUNT= Aaronepower .include <bsd.port.mk>
Сгенерировать первоначальный distinfo:
% make makesum
=> Aaronepower-tokei-v7.0.2_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://codeload.github.com/Aaronepower/tokei/tar.gz/v7.0.2?dummy=/Aaronepower-tokei-v7.0.2_GH0.tar.gz
fetch: https://codeload.github.com/Aaronepower/tokei/tar.gz/v7.0.2?dummy=/Aaronepower-tokei-v7.0.2_GH0.tar.gz: size of remote file is not known
Aaronepower-tokei-v7.0.2_GH0.tar.gz 45 kB 239 kBps 00m00s
Теперь файл дистрибутива готов к использованию, и мы можем продолжить, извлекая зависимости пакета из встроенного файла Cargo.lock:
% make cargo-crates
CARGO_CRATES= aho-corasick-0.6.4 \
ansi_term-0.11.0 \
arrayvec-0.4.7 \
atty-0.2.9 \
bitflags-1.0.1 \
byteorder-1.2.2 \
[...]
Вывод этой команды необходимо вставить напрямую в Makefile:
PORTNAME= tokei DISTVERSIONPREFIX= v DISTVERSION= 7.0.2 CATEGORIES= devel MAINTAINER= tobik@FreeBSD.org COMMENT= Display statistics about your code WWW= https://github.com/XAMPPRocky/tokei/ USES= cargo USE_GITHUB= yes GH_ACCOUNT= Aaronepower CARGO_CRATES= aho-corasick-0.6.4 \ ansi_term-0.11.0 \ arrayvec-0.4.7 \ atty-0.2.9 \ bitflags-1.0.1 \ byteorder-1.2.2 \ [...] .include <bsd.port.mk>
distinfo необходимо перегенерировать, чтобы включить все дистрибутивные файлы крейтов:
% make makesum
=> rust/crates/aho-corasick-0.6.4.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://crates.io/api/v1/crates/aho-corasick/0.6.4/download?dummy=/rust/crates/aho-corasick-0.6.4.tar.gz
rust/crates/aho-corasick-0.6.4.tar.gz 100% of 24 kB 6139 kBps 00m00s
=> rust/crates/ansi_term-0.11.0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://crates.io/api/v1/crates/ansi_term/0.11.0/download?dummy=/rust/crates/ansi_term-0.11.0.tar.gz
rust/crates/ansi_term-0.11.0.tar.gz 100% of 16 kB 21 MBps 00m00s
=> rust/crates/arrayvec-0.4.7.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://crates.io/api/v1/crates/arrayvec/0.4.7/download?dummy=/rust/crates/arrayvec-0.4.7.tar.gz
rust/crates/arrayvec-0.4.7.tar.gz 100% of 22 kB 3237 kBps 00m00s
=> rust/crates/atty-0.2.9.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://crates.io/api/v1/crates/atty/0.2.9/download?dummy=/rust/crates/atty-0.2.9.tar.gz
rust/crates/atty-0.2.9.tar.gz 100% of 5898 B 81 MBps 00m00s
=> rust/crates/bitflags-1.0.1.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
[...]
Порт теперь готов к тестовой сборке и дальнейшим настройкам, таким как создание plist, написание описания, добавление информации о лицензии, опций и т.д., как обычно.
Если вы не тестируете свой порт в чистой среде, например, с использованием poudriere, не забудьте выполнить make clean
перед любым тестированием.
Некоторые приложения определяют дополнительные возможности в своем Cargo.toml. Их можно включить при компиляции, установив CARGO_FEATURES
в порте.
Здесь мы включаем функции json
и yaml
в Tokei:
CARGO_FEATURES= json yaml
Пример раздела [features]
в Cargo.toml может выглядеть так:
[features] pulseaudio_backend = ["librespot-playback/pulseaudio-backend"] portaudio_backend = ["librespot-playback/portaudio-backend"] default = ["pulseaudio_backend"]
pulseaudio_backend
— это функция по умолчанию. Она всегда включена, если мы явно не отключим функции по умолчанию, добавив --no-default-features
в CARGO_FEATURES
. Здесь мы превращаем функции portaudio_backend
и pulseaudio_backend
в опции порта:
CARGO_FEATURES= --no-default-features OPTIONS_DEFINE= PORTAUDIO PULSEAUDIO PORTAUDIO_VARS= CARGO_FEATURES+=portaudio_backend PULSEAUDIO_VARS= CARGO_FEATURES+=pulseaudio_backend
Крейты имеют собственные лицензии. Важно знать, какие они, при добавлении блока LICENSE
в порт (см. Лицензии). Вспомогательная цель cargo-crates-licenses
попытается перечислить все лицензии всех ящиков, определённых в CARGO_CRATES
.
% make cargo-crates-licenses
aho-corasick-0.6.4 Unlicense/MIT
ansi_term-0.11.0 MIT
arrayvec-0.4.7 MIT/Apache-2.0
atty-0.2.9 MIT
bitflags-1.0.1 MIT/Apache-2.0
byteorder-1.2.2 Unlicense/MIT
[...]
Названия лицензий, которые выводит |
6.6.7. Использование meson
Для портов, использующих Meson, определите USES=meson
.
Переменная | Описание |
---|---|
| Порт-специфичные флаги Meson, передаваемые в бинарный файл |
| Путь к директории сборки относительно |
USES=meson
Этот фрагмент демонстрирует использование Meson для порта.
USES= meson MESON_ARGS= -Dfoo=enabled
6.6.8. Создание приложений на Go
Для портов, использующих Go, определите USES=go
. Обратитесь к go
для получения списка переменных, которые можно задать для управления процессом сборки.
В большинстве случаев достаточно установить переменную GO_MODULE
в значение, указанное директивой module
в go.mod
:
PORTNAME= hey DISTVERSIONPREFIX= v DISTVERSION= 0.1.4 CATEGORIES= benchmarks MAINTAINER= dmgk@FreeBSD.org COMMENT= Tiny program that sends some load to a web application WWW= https://github.com/rakyll/hey/ LICENSE= APACHE20 LICENSE_FILE= ${WRKSRC}/LICENSE USES= go:modules GO_MODULE= github.com/rakyll/hey PLIST_FILES= bin/hey .include <bsd.port.mk>
Если «простой» способ не подходит или требуется больший контроль над зависимостями, полный процесс переноса описан ниже.
Создание порта на основе Go — это процесс из пяти этапов. Сначала необходимо предоставить шаблон портов, который загружает дистрибутивный файл приложения:
PORTNAME= ghq DISTVERSIONPREFIX= v DISTVERSION= 0.12.5 CATEGORIES= devel MAINTAINER= tobik@FreeBSD.org COMMENT= Remote repository management made easy WWW= https://github.com/x-motemen/ghq/ USES= go:modules USE_GITHUB= yes GH_ACCOUNT= motemen .include <bsd.port.mk>
Сгенерировать первоначальный distinfo:
% make makesum
===> License MIT accepted by the user
=> motemen-ghq-v0.12.5_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://codeload.github.com/motemen/ghq/tar.gz/v0.12.5?dummy=/motemen-ghq-v0.12.5_GH0.tar.gz
fetch: https://codeload.github.com/motemen/ghq/tar.gz/v0.12.5?dummy=/motemen-ghq-v0.12.5_GH0.tar.gz: size of remote file is not known
motemen-ghq-v0.12.5_GH0.tar.gz 32 kB 177 kBps 00s
Теперь файл дистрибутива готов к использованию, и мы можем извлечь необходимые зависимости модуля Go. Этот шаг требует наличия установленного пакета ports-mgmt/modules2tuple:
% make gomod-vendor
[...]
GH_TUPLE= \
Songmu:gitconfig:v0.0.2:songmu_gitconfig/vendor/github.com/Songmu/gitconfig \
daviddengcn:go-colortext:186a3d44e920:daviddengcn_go_colortext/vendor/github.com/daviddengcn/go-colortext \
go-yaml:yaml:v2.2.2:go_yaml_yaml/vendor/gopkg.in/yaml.v2 \
golang:net:3ec191127204:golang_net/vendor/golang.org/x/net \
golang:sync:112230192c58:golang_sync/vendor/golang.org/x/sync \
golang:xerrors:3ee3066db522:golang_xerrors/vendor/golang.org/x/xerrors \
motemen:go-colorine:45d19169413a:motemen_go_colorine/vendor/github.com/motemen/go-colorine \
urfave:cli:v1.20.0:urfave_cli/vendor/github.com/urfave/cli
Вывод этой команды необходимо вставить напрямую в Makefile:
PORTNAME= ghq DISTVERSIONPREFIX= v DISTVERSION= 0.12.5 CATEGORIES= devel MAINTAINER= tobik@FreeBSD.org COMMENT= Remote repository management made easy WWW= https://github.com/x-motemen/ghq/ USES= go:modules USE_GITHUB= yes GH_ACCOUNT= motemen GH_TUPLE= Songmu:gitconfig:v0.0.2:songmu_gitconfig/vendor/github.com/Songmu/gitconfig \ daviddengcn:go-colortext:186a3d44e920:daviddengcn_go_colortext/vendor/github.com/daviddengcn/go-colortext \ go-yaml:yaml:v2.2.2:go_yaml_yaml/vendor/gopkg.in/yaml.v2 \ golang:net:3ec191127204:golang_net/vendor/golang.org/x/net \ golang:sync:112230192c58:golang_sync/vendor/golang.org/x/sync \ golang:xerrors:3ee3066db522:golang_xerrors/vendor/golang.org/x/xerrors \ motemen:go-colorine:45d19169413a:motemen_go_colorine/vendor/github.com/motemen/go-colorine \ urfave:cli:v1.20.0:urfave_cli/vendor/github.com/urfave/cli .include <bsd.port.mk>
distinfo необходимо обновить, чтобы включить все дистрибутивные файлы:
% make makesum
=> Songmu-gitconfig-v0.0.2_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://codeload.github.com/Songmu/gitconfig/tar.gz/v0.0.2?dummy=/Songmu-gitconfig-v0.0.2_GH0.tar.gz
fetch: https://codeload.github.com/Songmu/gitconfig/tar.gz/v0.0.2?dummy=/Songmu-gitconfig-v0.0.2_GH0.tar.gz: size of remote file is not known
Songmu-gitconfig-v0.0.2_GH0.tar.gz 5662 B 936 kBps 00s
=> daviddengcn-go-colortext-186a3d44e920_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://codeload.github.com/daviddengcn/go-colortext/tar.gz/186a3d44e920?dummy=/daviddengcn-go-colortext-186a3d44e920_GH0.tar.gz
fetch: https://codeload.github.com/daviddengcn/go-colortext/tar.gz/186a3d44e920?dummy=/daviddengcn-go-colortext-186a3d44e920_GH0.tar.gz: size of remote file is not known
daviddengcn-go-colortext-186a3d44e920_GH0.tar. 4534 B 1098 kBps 00s
[...]
Порт теперь готов к тестовой сборке и дальнейшим настройкам, таким как создание plist, написание описания, добавление информации о лицензии, опций и т.д., как обычно.
Если вы не тестируете свой порт в чистой среде, например, с использованием poudriere, не забудьте выполнить make clean
перед любым тестированием.
Некоторые порты требуют установки результирующего бинарного файла под другим именем или в путь, отличный от стандартного ${PREFIX}/bin
. Это можно сделать с помощью синтаксиса кортежа GO_TARGET
, например:
GO_TARGET= ./cmd/ipfs:ipfs-go
установит бинарный файл ipfs
как ${PREFIX}/bin/ipfs-go
и
GO_TARGET= ./dnscrypt-proxy:${PREFIX}/sbin/dnscrypt-proxy
установит dnscrypt-proxy
в ${PREFIX}/sbin
.
6.6.9. Построение приложений на Haskell с помощью cabal
Для портов, использующих Cabal, система сборки определяет USES=cabal
. Обратитесь к cabal
для получения списка переменных, которые можно задать для управления процессом сборки.
При подготовке порта Haskell Cabal требуются программы devel/hs-cabal-install и ports-mgmt/hs-cabal2tuple, поэтому убедитесь, что они установлены заранее. Сначала необходимо определить общие переменные портов, которые позволяют cabal-install загрузить файл дистрибутива пакета:
PORTNAME= ShellCheck DISTVERSION= 0.6.0 CATEGORIES= devel MAINTAINER= haskell@FreeBSD.org COMMENT= Shell script analysis tool WWW= https://www.shellcheck.net/ USES= cabal .include <bsd.port.mk>
Этот минимальный Makefile загружает файл дистрибутива с помощью вспомогательной цели cabal-extract
:
% make cabal-extract
[...]
Downloading the latest package list from hackage.haskell.org
cabal get ShellCheck-0.6.0
Downloading ShellCheck-0.6.0
Downloaded ShellCheck-0.6.0
Unpacking to ShellCheck-0.6.0/
Теперь, когда у нас есть файл описания пакета ShellCheck.cabal в ${WRKSRC}
, мы можем использовать cabal-configure
для создания плана сборки:
% make cabal-configure
[...]
Resolving dependencies...
Build profile: -w ghc-8.10.7 -O1
In order, the following would be built (use -v for more details):
- Diff-0.4.1 (lib) (requires download & build)
- OneTuple-0.3.1 (lib) (requires download & build)
[...]
После завершения можно сгенерировать список необходимых зависимостей:
% make make-use-cabal
USE_CABAL= QuickCheck-2.12.6.1 \
hashable-1.3.0.0 \
integer-logarithms-1.0.3 \
[...]
Пакеты Haskell могут содержать ревизии, как и порты FreeBSD. Ревизии могут затрагивать только файлы .cabal. Обратите внимание на дополнительные номера версий после символа _
. Замените старый список USE_CABAL
на вновь сгенерированный.
Наконец, файл distinfo необходимо перегенерировать, чтобы он содержал все файлы дистрибутива:
% make makesum
=> ShellCheck-0.6.0.tar.gz doesn't seem to exist in /usr/local/poudriere/ports/git/distfiles/cabal.
=> Attempting to fetch https://hackage.haskell.org/package/ShellCheck-0.6.0/ShellCheck-0.6.0.tar.gz
ShellCheck-0.6.0.tar.gz 136 kB 642 kBps 00s
=> QuickCheck-2.12.6.1/QuickCheck-2.12.6.1.tar.gz doesn't seem to exist in /usr/local/poudriere/ports/git/distfiles/cabal.
=> Attempting to fetch https://hackage.haskell.org/package/QuickCheck-2.12.6.1/QuickCheck-2.12.6.1.tar.gz
QuickCheck-2.12.6.1/QuickCheck-2.12.6.1.tar.gz 65 kB 361 kBps 00s
[...]
Порт теперь готов к тестовой сборке и дальнейшим настройкам, таким как создание plist, написание описания, добавление информации о лицензии, опций и т.д., как обычно.
Если вы не тестируете свой порт в чистой среде, например, с использованием poudriere, не забудьте выполнить make clean
перед любым тестированием.
Некоторые порты Haskell устанавливают различные файлы данных в share/${PORTNAME}
. В таких случаях требуется особая обработка на стороне порта. Порт должен определить параметр CABAL_WRAPPER_SCRIPTS
, перечислив каждый исполняемый файл, который будет использовать файлы данных. Более того, в редких случаях портируемая программа использует файлы данных других пакетов Haskell, и тогда на помощь приходит FOO_DATADIR_VARS
.
devel/hs-profiteur
— это приложение на Haskell, которое генерирует одностраничный HTML с некоторым содержимым.
PORTNAME= profiteur [...] USES= cabal USE_CABAL= OneTuple-0.3.1_2 \ QuickCheck-2.14.2 \ [...] .include <bsd.port.mk>
Он устанавливает HTML-шаблоны в share/profiteur
, поэтому необходимо добавить параметр CABAL_WRAPPER_SCRIPTS
:
[...] USE_CABAL= OneTuple-0.3.1_2 \ QuickCheck-2.14.2 \ [...] CABAL_WRAPPER_SCRIPTS= ${CABAL_EXECUTABLES} .include <bsd.port.mk>
Программа также пытается получить доступ к файлу jquery.js
, который является частью пакета Haskell js-jquery-3.3.1
. Чтобы этот файл был найден, необходимо, чтобы скрипт-обёртка искал файлы данных js-jquery
также в share/profiteur
. Для этого используется profiteur_DATADIR_VARS
:
[...] CABAL_WRAPPER_SCRIPTS= ${CABAL_EXECUTABLES} profiteur_DATADIR_VARS= js-jquery .include <bsd.port.mk>
Теперь порт установит непосредственно бинарный файл в libexec/cabal/profiteur
, а скрипт — в bin/profiteur
.
Не существует простого способа определить подходящее значение для параметра FOO_DATADIR_VARS
, кроме как запустить программу и проверить, что всё работает. К счастью, необходимость использовать FOO_DATADIR_VARS
возникает очень редко.
Еще один крайний случай при переносе сложных программ на Haskell — наличие зависимостей от систем контроля версий (VCS) в файле cabal.project
.
net-p2p/cardano-node
— это чрезвычайно сложное программное обеспечение. В его cabal.project
содержится множество блоков, подобных этому:
[...] source-repository-package type: git location: https://github.com/input-output-hk/cardano-crypto tag: f73079303f663e028288f9f4a9e08bcca39a923e [...]
Зависимости типа source-repository-package
автоматически подтягиваются cabal
в процессе сборки. К сожалению, это приводит к использованию сети после этапа fetch
, что запрещено в рамках системы портов. Эти исходники необходимо указать в Makefile порта. Вспомогательная цель make-use-cabal
может упростить работу с пакетами, размещёнными на GitHub. Запуск этой цели после стандартных cabal-extract
и cabal-configure
позволит получить не только параметр USE_CABAL
, но и GH_TUPLE
:
% make make-use-cabal
USE_CABAL= Diff-0.4.1 \
Glob-0.10.2_3 \
HUnit-1.6.2.0 \
[...]
GH_TUPLE= input-output-hk:cardano-base:0f3a867493059e650cda69e20a5cbf1ace289a57:cardano_base/dist-newstyle/src/cardano-b_-c8db9876882556ed \
input-output-hk:cardano-crypto:f73079303f663e028288f9f4a9e08bcca39a923e:cardano_crypto/dist-newstyle/src/cardano-c_-253fd88117badd8f \
[...]
Может быть полезно отделить элементы GH_TUPLE
, поступающие из make-use-cabal
, от остальных, чтобы упростить обновление порта:
GH_TUPLE= input-output-hk:cardano-base:0f3a867493059e650cda69e20a5cbf1ace289a57:cardano_base/dist-newstyle/src/cardano-b_-c8db9876882556ed \ input-output-hk:cardano-crypto:f73079303f663e028288f9f4a9e08bcca39a923e:cardano_crypto/dist-newstyle/src/cardano-c_-253fd88117badd8f \ [...] GH_TUPLE+= bitcoin-core:secp256k1:ac83be33d0956faf6b7f61a60ab524ef7d6a473a:secp
Версия Haskell-портов с зависимостями от систем контроля версий временно требует следующего обходного решения:
BINARY_ALIAS= git=true
6.7. Использование GNU Autotools
Если порту требуется какое-либо программное обеспечение GNU Autotools, добавьте USES=autoreconf
. Подробнее см. в autoreconf
.
6.8. Использование GNU gettext
6.8.1. Простые варианты использования
Если порт требует gettext
, установите USES=gettext
, и порт унаследует зависимость от libintl.so из пакета devel/gettext. Другие значения для использования gettext
перечислены в USES=gettext
.
Довольно распространённый случай — порт, использующий gettext
и configure
. Обычно GNU configure
должен автоматически находить gettext
.
USES= gettext GNU_CONFIGURE= yes
Если он не сработает, можно указать расположение gettext
через CPPFLAGS
и LDFLAGS
, используя localbase
следующим образом:
USES= gettext localbase:ldflags GNU_CONFIGURE= yes
6.8.2. Оптимальное использование
Некоторые программные продукты позволяют отключать NLS, к примеру, передавая параметр --disable-nls
сценарию configure
. В этом случае ваш порт должен использовать gettext
, в зависимости от значения NLS
. Для портов небольшой или средней сложности вы можете полагаться на следующую идиому:
GNU_CONFIGURE= yes OPTIONS_DEFINE= NLS OPTIONS_SUB= yes NLS_USES= gettext NLS_CONFIGURE_ENABLE= nls .include <bsd.port.mk>
Или используя старый способ с опциями:
GNU_CONFIGURE= yes OPTIONS_DEFINE= NLS .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MNLS} USES+= gettext PLIST_SUB+= NLS="" .else CONFIGURE_ARGS+= --disable-nls PLIST_SUB+= NLS="@comment " .endif .include <bsd.port.mk>
Следующий пункт в списке задач — организовать условное включение файлов каталогов сообщений в упаковочный список. Часть, связанная с Makefile, уже предусмотрена идиомой. Это объясняется в разделе расширенные практики работы с pkg-plist. Вкратце, каждое вхождение %%NLS%%
в pkg-plist будет заменено на "`@comment ", если NLS отключен, или на пустую строку, если NLS включен. Следовательно, строки с префиксом `%%NLS%%
станут обычными комментариями в итоговом упаковочном списке, если NLS выключен; в противном случае префикс будет просто удален. Затем вставьте %%NLS%%
перед каждым путем к файлу каталога сообщений в pkg-plist. Например:
%%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo %%NLS%%share/locale/no/LC_MESSAGES/foobar.mo
В особо сложных случаях вам понадобиться использовать более продвинутые техники, чем данный рецепт, такие как динамические списки упаковки.
6.8.3. Управление каталогами сообщений
Существует момент, который следует учитывать при установке файлов каталогов сообщений. Целевые каталоги для размещения, расположенные под LOCALBASE/shared/locale, редко когда должны создаваться и удаляться портом. Для наиболее популярных языков имеются собственные каталоги, перечисленные в PORTSDIR/Templates/BSD.local.dist. Каталоги для множества других языков управляются с помощью порта devel/gettext. Обратите внимание на его pkg-plist и посмотрите, куда данный порт собирается установить файлы каталогов сообщений для единственного в своем роде языка.
6.9. Использование Perl
Если MASTER_SITES
установлена в значение CPAN
, то правильная поддиректория выбирается автоматически. Если подкаталог по умолчанию указан неверно, можно использовать CPAN/Module
для его изменения. Также можно установить MASTER_SITES
в старое значение MASTER_SITE_PERL_CPAN
, тогда предпочтительным значением MASTER_SITE_SUBDIR
будет имя иерархии выше уровнем. Например, рекомендуемое значение для p5-Module-Name
- Module
. Иерархию верхнего уровня можно посмотреть на cpan.org. Это гарантирует работоспособность порта при смене автора модуля.
Исключением этого правила является отсутствие соответствующего каталога или файла с дистрибутивом в этом каталоге. В качестве MASTER_SITE_SUBDIR
в этом случае разрешается использовать id автора. Можно использовать макрос CPAN:AUTHOR
, который будет преобразован в хешированный каталог автора. Например, CPAN:AUTHOR
преобразуется в authors/id/A/AU/AUTHOR
.
Когда порту требуется поддержка Perl, он должен установить USES=perl5
с опциональным USE_PERL5
, как описано в описание USES для perl5.
Переменные (только для чтения) | Значение |
---|---|
| Полный путь к интерпретатору Perl 5, будь то системный или установленный из порта, но без номера версии. Используйте это, когда программному обеспечению требуется путь к интерпретатору Perl. Для замены строк “`#! |
| Полная версия Perl установлена (например, |
| Установленная версия Perl в виде целого числа формата |
| Где Perl хранит архитектурно-зависимые библиотеки. По умолчанию: |
| Имя порта Perl, который установлен (например, |
| Имя каталога, в котором размещаются специфичные для сайта пакеты Perl. Это значение добавляется в |
Порты Perl-модулей, у которых нет официального сайта, должны ссылаться на |
Не используйте |
p5-IO-Tee>=0.64:devel/p5-IO-Tee
Для портов Perl, которые устанавливают страницы руководства, макросы PERL5_MAN3
и PERL5_MAN1
могут использоваться внутри pkg-plist. Например,
lib/perl5/5.14/man/man1/event.1.gz lib/perl5/5.14/man/man3/AnyEvent::I3.3.gz
может быть заменено на
%%PERL5_MAN1%%/event.1.gz %%PERL5_MAN3%%/AnyEvent::I3.3.gz
Для других разделов (x в |
Поскольку значение USE_PERL5 по умолчанию включает build и run, установите его в:
USES= perl5 USE_PERL5= build
ExtUtils::MakeMaker
Большинство модулей Perl поставляются с конфигурационным скриптом Makefile.PL. В этом случае установите:
USES= perl5 USE_PERL5= configure
Module::Build
Когда модуль Perl поставляется с конфигурационным скриптом Build.PL, он может требовать Module::Build, и в этом случае установите
USES= perl5 USE_PERL5= modbuild
Если вместо этого требуется Module::Build::Tiny, установите
USES= perl5 USE_PERL5= modbuildtiny
6.10. Использование X11
6.10.1. Компоненты X.Org
Реализация X11, доступная в Коллекции портов, — это X.Org. Если приложение зависит от компонентов X, добавьте USES= xorg
и укажите необходимые компоненты в USE_XORG
. Полный список можно найти в xorg
.
Проект Mesa — это инициатива по предоставлению свободной реализации OpenGL. Чтобы указать зависимость от различных компонентов этого проекта, используйте USES=gl
и USE_GL
. См. gl
для полного списка доступных компонентов. Для обратной совместимости значение yes
соответствует glu
.
USE_XORG
USES= gl xorg USE_GL= glu USE_XORG= xrender xft xkbfile xt xaw
| Порт использует |
| Установить путь к |
# Use some X11 libraries USES= xorg USE_XORG= x11 xpm
6.10.2. Порты, требующие Motif
Если порт требует библиотеку Motif, определите USES= motif
в Makefile. Реализация Motif по умолчанию — это x11-toolkits/open-motif. Пользователи могут выбрать x11-toolkits/lesstif вместо этого, установив WANT_LESSTIF
в своём make.conf. Аналогично x11-toolkits/open-motif-devel можно выбрать, установив WANT_OPEN_MOTIF_DEVEL
в make.conf.
MOTIFLIB
будет установлен в файле motif.mk для ссылки на соответствующую библиотеку Motif. Пожалуйста, исправьте исходный код порта, чтобы использовать ${MOTIFLIB}
везде, где библиотека Motif упоминается в оригинальном Makefile или Imakefile.
Есть два распространённых случая:
Если порт ссылается на библиотеку Motif как
-lXm
в своем Makefile или Imakefile, замените это на${MOTIFLIB}
.Если порт использует
XmClientLibs
в своем Imakefile, замените это на${MOTIFLIB} ${XTOOLLIB} ${XLIB}
.
Обратите внимание, что MOTIFLIB
(обычно) раскрывается в -L/usr/local/lib -lXm -lXp
или /usr/local/lib/libXm.a
, поэтому нет необходимости добавлять -L
или -l
перед этим.
6.10.3. Шрифты X11
Если порт устанавливает шрифты для X Window System, поместите их в LOCALBASE/lib/X11/fonts/local.
6.10.4. Получение поддельного DISPLAY
с помощью Xvfb
Некоторые приложения требуют рабочего дисплея X11 для успешной компиляции. Это создаёт проблему для машин, работающих без монитора. При использовании этой переменной инфраструктура сборки запустит виртуальный X-сервер с буфером кадров. Рабочий DISPLAY
затем передаётся в процесс сборки. См. USES=display
для возможных аргументов.
USES= display
6.10.5. Desktop Entries (пункты рабочего стола)
Desktop entries (стандарт Freedesktop) предоставляют способ автоматической настройки функций рабочего стола при установке новой программы без вмешательства пользователя. Например, вновь установленные программы автоматически появляются в меню приложений совместимых сред рабочего стола. Desktop entries появились в среде GNOME, но теперь стали стандартом и также работают с KDE и Xfce. Эта автоматизация приносит реальную пользу пользователю, поэтому Desktop entries рекомендуются для приложений, которые могут использоваться в среде рабочего стола.
6.10.5.1. Использование предопределенных файлов .desktop
Порты, включающие предопределённые файлы *.desktop, должны добавлять эти файлы в pkg-plist и устанавливать их в директорию $LOCALBASE/share/applications. Для установки таких файлов полезен макрос INSTALL_DATA
.
6.10.5.2. Обновление базы данных рабочего стола
Если порт имеет запись MimeType в файле portname.desktop, базу данных рабочего стола необходимо обновить после установки и удаления. Для этого определите USES
= desktop-file-utils.
6.10.5.3. Создание Desktop Entries с помощью DESKTOP_ENTRIES
Desktop Entries могут быть легко созданы для приложений с использованием DESKTOP_ENTRIES
. Файл с именем name.desktop будет создан, установлен и автоматически добавлен в pkg-plist. Синтаксис следующий:
DESKTOP_ENTRIES= "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify
Список возможных категорий доступен на сайте Freedesktop. StartupNotify
указывает, совместимо ли приложение с уведомлениями о запуске. Обычно это графический индикатор, например, часы, который появляется у указателя мыши, в меню или на панели, чтобы дать пользователю понять, что программа запускается. Программа, совместимая с уведомлениями о запуске, очищает индикатор после своего старта. Программы, не совместимые с уведомлениями о запуске, никогда не очищают индикатор (что может сбивать с толку и раздражать пользователя), и у них должен быть установлен параметр StartupNotify
в значение false
, чтобы индикатор вообще не отображался.
Пример:
DESKTOP_ENTRIES= "ToME" "Roguelike game based on JRR Tolkien's work" \ "${DATADIR}/xtra/graf/tome-128.png" \ "tome -v -g" "Application;Game;RolePlaying;" \ false
DESKTOP_ENTRIES
устанавливаются в директорию, указанную переменной DESKTOPDIR
. По умолчанию DESKTOPDIR
имеет значение ${PREFIX}/share/applications
6.11. Использование GNOME
6.11.1. Введение
Эта глава объясняет фреймворк GNOME, используемый в портах. Фреймворк можно условно разделить на базовые компоненты, компоненты рабочего стола GNOME и несколько специальных макросов, упрощающих работу сопровождающих портов.
6.11.2. Использование USE_GNOME
Добавление этой переменной в порт позволяет использовать макросы и компоненты, определённые в bsd.gnome.mk. Код в bsd.gnome.mk добавляет необходимые зависимости для сборки, выполнения или библиотеки, а также обработку специальных файлов. Приложения GNOME в FreeBSD используют инфраструктуру USE_GNOME
. Включите все необходимые компоненты в виде списка, разделённого пробелами. Компоненты USE_GNOME
разделены на следующие виртуальные списки: основные компоненты, компоненты GNOME 3 и устаревшие компоненты. Если порту требуются только библиотеки GTK3, это кратчайший способ определить это:
USE_GNOME= gtk30
USE_GNOME
компоненты автоматически добавляют необходимые им зависимости. Подробный список всех компонентов USE_GNOME
, а также информацию о том, какие другие компоненты они подразумевают и их зависимости, можно найти в Компоненты GNOME.
Вот пример Makefile для порта GNOME, в котором используются многие методы, описанные в этом документе. Пожалуйста, используйте его в качестве руководства при создании новых портов.
PORTNAME= regexxer DISTVERSION= 0.10 CATEGORIES= devel textproc gnome MASTER_SITES= GNOME MAINTAINER= kwm@FreeBSD.org COMMENT= Interactive tool for performing search and replace operations WWW= http://regexxer.sourceforge.net/ USES= gettext gmake localbase:ldflags pathfix pkgconfig tar:xz GNU_CONFIGURE= yes USE_GNOME= gnomeprefix intlhack gtksourceviewmm3 GLIB_SCHEMAS= org.regexxer.gschema.xml .include <bsd.port.mk>
Макрос |
6.11.3. Переменные
Этот раздел объясняет, какие макросы доступны и как они используются. Как, например, в приведённом выше примере. В Компоненты GNOME содержится более подробное объяснение. Для использования этих макросов необходимо установить USE_GNOME
.
GLIB_SCHEMAS
Список всех файлов схем glib, которые устанавливает порт. Макрос добавит файлы в plist порта и обработает регистрацию этих файлов при установке и удалении.
Файлы схем glib написаны в XML и имеют расширение gschema.xml. Они устанавливаются в директорию share/glib-2.0/schemas/. Эти файлы схем содержат все настройки конфигурации приложений со значениями по умолчанию. Фактическая база данных, используемая приложениями, создаётся с помощью glib-compile-schema, которая запускается макросом
GLIB_SCHEMAS
.GLIB_SCHEMAS=foo.gschema.xml
Не добавляйте схемы glib в файл pkg-plist. Если они указаны в pkg-plist, они не будут зарегистрированы, и приложения могут работать некорректно.
GCONF_SCHEMAS
Перечислите все файлы схем gconf. Макрос добавит файлы схем в plist порта и обеспечит их регистрацию при установке и удалении.
GConf — это база данных на основе XML, которую используют практически все приложения GNOME для хранения своих настроек. Эти файлы устанавливаются в директорию etc/gconf/schemas. Эта база данных определяется установленными файлами схем, которые используются для генерации ключевых файлов %gconf.xml. Для каждого файла схемы, устанавливаемого портом, должна быть запись в Makefile:
GCONF_SCHEMAS=my_app.schemas my_app2.schemas my_app3.schemas
Схемы Gconf перечислены в макросе
GCONF_SCHEMAS
, а не в файле pkg-plist. Если они указаны в pkg-plist, они не будут зарегистрированы, и приложения могут работать некорректно.INSTALLS_OMF
Файлы Open Source Metadata Framework (OMF) часто используются приложениями GNOME 2. Эти файлы содержат информацию о файлах справки приложений и требуют специальной обработки с помощью ScrollKeeper/rarian. Для правильной регистрации файлов OMF при установке приложений GNOME из пакетов убедитесь, что файлы
omf
указаны вpkg-plist
и что в Makefile порта определеноINSTALLS_OMF
:INSTALLS_OMF=yes
При установке bsd.gnome.mk автоматически сканирует pkg-plist и добавляет соответствующие директивы
@exec
и@unexec
для каждого файла .omf, который необходимо отслеживать в базе данных регистрации OMF.
6.12. Компоненты GNOME
Для получения дополнительной помощи с портом GNOME, ознакомьтесь с некоторыми из существующих портов в качестве примеров. На странице FreeBSD GNOME указана контактная информация, если требуется дополнительная помощь. Компоненты разделены на используемые в настоящее время компоненты GNOME и устаревшие компоненты. Если компонент поддерживает аргументы, они перечислены в скобках в описании. Первый аргумент является значением по умолчанию. "Both" указывается, если компонент по умолчанию добавляется как в зависимости для сборки, так и для выполнения.
Компонент | Связанная программа | Описание |
---|---|---|
| accessibility/atk | Инструментарий доступности (ATK) |
| accessibility/atkmm | C++ интерфейс для atk |
| graphics/cairo | Векторная графическая библиотека с поддержкой вывода на различные устройства |
| graphics/cairomm | C++ интерфейс для cairo |
| devel/dconf | Система базы данных конфигурации (both, build, run) |
| databases/evolution-data-server | Бэкенды данных для интегрированного почтового клиента/PIM Evolution |
| graphics/gdk-pixbuf2 | Графическая библиотека для GTK+ |
| devel/glib20 | Основная библиотека GNOME |
| devel/glibmm | C++ интерфейс для glib20 |
| sysutils/gnome-control-center | Центр управления GNOME 3 |
| x11/gnome-desktop | Библиотека пользовательского интерфейса рабочего стола GNOME 3 |
| audio/gsound | Библиотека GObject для воспроизведения системных звуков (both, build, run) |
| graphics/gtk-update-icon-cache | Утилита |
| x11-toolkits/gtk20 | Набор инструментов Gtk+ 2 |
| x11-toolkits/gtk30 | Набор инструментов Gtk+ 3 |
| x11-toolkits/gtkmm20 | C++ интерфейс 2.0 для инструментария gtk20 |
| x11-toolkits/gtkmm24 | C++ интерфейс 2.4 для инструментария gtk20 |
| x11-toolkits/gtkmm30 | C++ интерфейс 3.0 для набора инструментов gtk30 |
| x11-toolkits/gtksourceview2 | Виджет, добавляющий подсветку синтаксиса в GtkTextView |
| x11-toolkits/gtksourceview3 | Текстовая виджет, добавляющая подсветку синтаксиса к виджету GtkTextView |
| x11-toolkits/gtksourceviewmm3 | C++ интерфейс для библиотеки gtksourceview3 |
| devel/gvfs | Виртуальная файловая система GNOME |
| textproc/intltool | Инструмент для интернационализации (см. также intlhack) |
| devel/gobject-introspection | Базовые привязки (биндинги) интроспекции и инструменты для генерации привязок интроспекции. В большинстве случаев достаточно |
| databases/libgda5 | Обеспечивает единообразный доступ к различным типам источников данных |
| databases/libgda5-ui | Библиотека пользовательского интерфейса из библиотеки libgda5 |
| databases/libgdamm5 | привязки C++ для библиотеки libgda5 |
| devel/libgsf | Расширяемая абстракция ввода-вывода для работы со структурированными форматами файлов |
| graphics/librsvg2 | Библиотека для разбора и отображения SVG-файлов векторной графики |
| devel/libsigc++20 | Фреймворк обратных вызовов для C++ |
| textproc/libxml++26 | C++ привязки для библиотеки libxml2 |
| textproc/libxml2 | Библиотека парсера XML (both, build, run) |
| textproc/libxslt | Библиотека XSLT (сборка, выполнение) |
| x11-wm/metacity | Менеджер окон из GNOME |
| x11-fm/nautilus | GNOME файловый менеджер |
| x11-toolkits/pango | Открытый фреймворк для разметки и отображения интернационализированного текста |
| x11-toolkits/pangomm | C++ интерфейс для библиотеки pango |
| devel/py3-gobject3 | Python 3, интерфейс GObject 3.0 |
| devel/py-gobject3 | Python 2, интерфейс GObject 3.0 |
| x11-toolkits/vte3 | Виджет терминала с улучшенной поддержкой доступности и интернационализации (I18N) |
Компонент | Описание |
---|---|
| Предоставляет |
| То же, что и |
| Этот макрос предназначен для помощи в разделении API или справочной документации на собственный порт. |
Компонент | Связанная программа | Описание |
---|---|---|
| accessibility/at-spi | Интерфейс поставщика услуг вспомогательных технологий (AT-SPI) |
| audio/esound | Пакет звука Enlightenment |
| x11-toolkits/gal2 | Коллекция виджетов, взятых из GNOME 2 gnumeric |
| devel/gconf2 | Система базы данных конфигурации для GNOME 2 |
| devel/gconfmm26 | C привязки C для gconf2 |
| graphics/gdk-pixbuf | Графическая библиотека для GTK+ |
| devel/glib12 | Библиотека ядра glib 1.2 |
| textproc/gnome-doc-utils | Утилиты документации GNOME |
| misc/gnome-mime-data | База данных MIME и приложений для GNOME 2 |
| x11-toolkits/gnome-sharp20 | Интерфейсы GNOME 2 для среды выполнения .NET |
| accessibility/gnome-speech | GNOME 2 API преобразования текста в речь |
| devel/gnome-vfs | Виртуальная файловая система GNOME 2 |
| x11-toolkits/gtk12 | Набор инструментов Gtk+ 1.2 |
| www/gtkhtml3 | Облегченный движок для отображения/печати/редактирования HTML |
| www/gtkhtml4 | Облегченный движок для отображения/печати/редактирования HTML |
| x11-toolkits/gtk-sharp20 | Интерфейсы GTK+ и GNOME 2 для среды выполнения .NET |
| x11-toolkits/gtksourceview | Виджет, добавляющий подсветку синтаксиса в GtkTextView |
| graphics/libart_lgpl | Библиотека для высокопроизводительной 2D графики |
| devel/libbonobo | Система компонентов и составных документов для GNOME 2 |
| x11-toolkits/libbonoboui | Интерфейс для libbonobo в GNOME 2 |
| databases/libgda4 | Обеспечивает единообразный доступ к различным типам источников данных |
| devel/libglade2 | Библиотека glade для GNOME 2 |
| x11/libgnome | Библиотеки для GNOME 2, GNU окружения рабочего стола |
| graphics/libgnomecanvas | Графическая библиотека для GNOME 2 |
| x11/libgnomekbd | Динамическая библиотека клавиатуры GNOME 2 |
| print/libgnomeprint | Библиотека поддержки печати Gnome 2 |
| x11-toolkits/libgnomeprintui | Библиотека поддержки печати Gnome 2 |
| x11-toolkits/libgnomeui | Библиотеки для графического интерфейса GNOME 2, среды рабочего стола GNU |
| www/libgtkhtml | Облегченный движок для отображения/печати/редактирования HTML |
| x11-toolkits/libgtksourceviewmm | C++ интерфейс GtkSourceView |
| devel/libIDL | Библиотека для создания деревьев файлов CORBA IDL |
| devel/libsigc++12 | Фреймворк обратных вызовов для C++ |
| x11-toolkits/libwnck | Библиотека, используемая для написания пейджеров и списков задач |
| x11-toolkits/libwnck3 | Библиотека, используемая для написания пейджеров и списков задач |
| devel/ORBit2 | Высокопроизводительный CORBA ORB с поддержкой языка C |
| x11-toolkits/py-gnome2 | Интерфейс Python для GNOME 2 |
| devel/py-gobject | Python 2, интерфейс GObject 2.0 |
| x11-toolkits/py-gtk2 | Набор интерфейсов Python для GTK+ |
| x11-toolkits/py-gtksourceview | Интерфейс Python для GtkSourceView 2 |
| x11-toolkits/vte | Виджет терминала с улучшенной поддержкой доступности и интернационализации (I18N) |
Компонент | Описание |
---|---|
| pangox-compat устарел и был отделён от пакета pango. |
6.13. Использование Qt
Для портов, которые являются частью самого Qt, см. |
6.13.1. Порты, требующие Qt
Коллекция портов поддерживает Qt 5 и Qt 6 с помощью USES+=qt:5
и USES+=qt:6
соответственно. Установите USE_QT
в список необходимых компонентов Qt (libraries, tools, plugins - библиотеки, инструменты, плагины).
Фреймворк Qt экспортирует ряд переменных, которые могут использоваться портами, некоторые из них перечислены ниже:
| Полный путь к исполняемому файлу |
| Полный путь к утилите |
| Полный путь к |
| Полный путь к |
| Полный путь к |
| Каталог включаемых файлов Qt. |
| Путь к библиотекам Qt. |
| Путь к плагинам Qt. |
6.13.2. Выбор компонентов
Отдельные зависимости инструментов и библиотек Qt должны быть указаны в USE_QT
. Каждый компонент может иметь суффикс _build
или _run
, указывающий, требуется ли компонент во время сборки или выполнения. Если суффикс отсутствует, компонент будет требоваться как во время сборки, так и во время выполнения. Обычно компоненты библиотек указываются без суффикса, компоненты инструментов чаще всего указываются с суффиксом _build
, а компоненты плагинов — с суффиксом _run
. Наиболее часто используемые компоненты перечислены ниже (все доступные компоненты перечислены в _USE_QT_ALL
, которая формируется из _USE_QT_COMMON
и _USE_QT[56]_ONLY
в /usr/ports/Mk/Uses/qt.mk):
Имя | Описание |
---|---|
| Модуль Qt3D |
| Модуль совместимости Qt 5 для Qt 6 |
| Браузер документации Qt 5 |
| Модуль Qt 6 base |
| Модуль Qt canvas3d |
| Модуль Qt 5 charts |
| Модуль многопоточности Qt |
| Модуль Qt для подключения (Bluetooth/NFC) |
| Ядро Qt, неграфический модуль |
| Модуль визуализации 3D данных Qt 5 |
| Модуль межпроцессного взаимодействия Qt D-Bus |
| Декларативный фреймворк Qt для динамических пользовательских интерфейсов |
| Интерфейсный конструктор Qt 5 для графического пользовательского интерфейса |
| Инструмент для сбора диагностической информации о Qt и его окружении |
| Документация Qt 5 |
| Исходный код примеров Qt 5 |
| Модуль Qt 5 Gamepad |
| Графические эффекты Qt Quick |
| Модуль графического интерфейса Qt |
| Модуль интеграции справки Qt в режиме онлайн |
| Локализованные сообщения Qt |
| Реализация протокола Language Server Protocol в Qt 6 |
| Инструмент перевода Qt 5 |
| Модуль Qt Location |
| Qt 6 QML API для отрисовки графики и анимаций |
| Модуль поддержки аудио, видео, радио и камеры Qt |
| Сетевой модуль Qt |
| Модуль сетевой аутентификации Qt |
| Модуль поддержки OpenGL, совместимый с Qt 5 |
| Клиент командной строки для QStandardPaths |
| Мультимедийный фреймворк KDE |
| Увеличитель экрана Qt 5 |
| Дампер метаданных плагинов Qt 5 |
| Qt 6 API позиционирования из источников, таких как спутники, Wi-Fi или текстовые файлы. |
| Модуль поддержки печати Qt |
| Интерфейс командной строки Qt для D-Bus |
| Графический интерфейс Qt 5 для D-Bus |
| Генератор документации Qt |
| Файлы конфигурации QDoc |
| Инструмент для интроспекции событий Qt QWidget |
| Генератор Makefile Qt |
| Набор элементов управления для создания полных интерфейсов в Qt Quick |
| Набор элементов управления для создания полных интерфейсов в Qt Quick |
| Модуль Qt 5 SXCML |
| Совместимый с Qt 4 модуль для написания сценариев |
| Дополнительные компоненты Qt Script |
| Модуль Qt 5 SXCML |
| Модуль Qt sensors |
| Функции Qt для доступа к промышленным шинным системам |
| Функции Qt для доступа к последовательным портам |
| Инструменты Qt 6 для кроссплатформенного конвейера шейдеров Qt |
| Доступность в Qt5 |
| Модуль интеграции с базой данных Qt SQL |
| Плагин Qt баз данных InterBase/Firebird |
| Плагин Qt базы данных MySQL |
| Плагин Qt ODBC |
| Плагин Qt базы данных PostgreSQL |
| Плагин Qt базы данных SQLite 2 |
| Плагин Qt базы данных SQLite 3 |
| Плагин Qt для подключение к базам данных по протоколу TDS |
| Модуль поддержки SVG в Qt |
| Модуль тестирования Qt |
| Различные инструменты Qt 6 |
| Модуль перевода Qt 6 |
| Интерфейс плагина пользовательского виджета Qt для Qt Designer |
| Модуль поддержки форм пользовательского интерфейса Qt Designer |
| Модуль виртуальной клавиатуры Qt 5 |
| Оболочка Qt 5 для Wayland |
| Библиотека Qt 5 для интеграции C++/QML с клиентами на HTML/js |
| Библиотека Qt 5 для отображения веб-содержимого |
| QtWebKit с более современной кодовой базой WebKit |
| Реализация протокола WebSocket на Qt |
| Реализация протокола WebSocket на Qt (привязки QML) |
| Компонент Qt для отображения веб-содержимого |
| Модуль виджетов Qt C++ |
| Платформо-специфичные возможности Qt для систем на основе X11 |
| Реализации SAX и DOM в Qt |
| Поддержка Qt для XPath, XQuery, XSLT и XML Schema |
Чтобы определить библиотеки, от которых зависит приложение, выполните ldd
для основного исполняемого файла после успешной компиляции.
Имя | Описание |
---|---|
| инструменты сборки ( |
| инструменты локализации: |
| Генератор Makefile/утилита сборки |
Имя | Описание |
---|---|
| плагины для графических форматов TGA, TIFF и MNG |
В этом примере портированное приложение использует библиотеку графического интерфейса Qt 5, основную библиотеку Qt 5, все инструменты генерации кода Qt 5 и генератор Makefile Qt 5. Поскольку библиотека gui
подразумевает зависимость от основной библиотеки, core
не нужно указывать. Инструменты генерации кода Qt 5 moc
, uic
и rcc
, а также генератор Makefile qmake
требуются только во время сборки, поэтому они указаны с суффиксом _build
:
USES= qt:5 USE_QT= gui buildtools_build qmake_build
6.13.3. Использование qmake
Если приложение предоставляет файл проекта qmake (*.pro), определите USES= qmake
вместе с USE_QT
. USES= qmake
уже подразумевает зависимость сборки от qmake, поэтому компонент qmake может быть опущен в USE_QT
. Подобно CMake, qmake поддерживает сборку вне исходного дерева, которую можно включить, указав аргумент outsource
(см. пример USES= qmake
). Также см. Возможные аргументы для USES qmake
.
Переменная | Описание |
---|---|
| Не добавлять цель configure. Это подразумевается при |
| Подавить модификацию окружения configure и make. Это требуется только когда |
| Не передавать аргумент |
| Выполнить сборку вне исходного кода. |
Переменная | Описание |
---|---|
| Специфичные для порта флаги qmake, передаваемые в бинарный файл |
| Переменные окружения, которые должны быть установлены для бинарного файла |
| Путь к файлам проекта qmake (.pro). По умолчанию используется |
При использовании USES= qmake
применяются следующие настройки:
CONFIGURE_ARGS+= --with-qt-includes=${QT_INCDIR} \ --with-qt-libraries=${QT_LIBDIR} \ --with-extra-libs=${LOCALBASE}/lib \ --with-extra-includes=${LOCALBASE}/include CONFIGURE_ENV+= QTDIR="${QT_PREFIX}" QMAKE="${QMAKE}" \ MOC="${MOC}" RCC="${RCC}" UIC="${UIC}" \ QMAKESPEC="${QMAKESPEC}" PLIST_SUB+= QT_INCDIR=${QT_INCDIR_REL} \ QT_LIBDIR=${QT_LIBDIR_REL} \ QT_PLUGINDIR=${QT_PLUGINDIR_REL}
Некоторые скрипты configure не поддерживают указанные выше аргументы. Чтобы отключить изменение CONFIGURE_ENV
и CONFIGURE_ARGS
, установите USES= qmake:no_env
.
USES= qmake
Этот фрагмент демонстрирует использование qmake для порта Qt 5:
USES= qmake:outsource qt:5 USE_QT= buildtools_build
Приложения Qt часто разрабатываются как кроссплатформенные, и зачастую X11/Unix — не та платформа, на которой они создаются. Это, в свою очередь, приводит к определённым недоработкам, таким как:
Отсутствуют дополнительные пути для заголовочных файлов. Многие приложения поддерживают значки в системном трее, но не учитывают пути для заголовочных файлов и/или библиотек в каталогах X11. Чтобы добавить каталоги в пути поиска заголовочных файлов и библиотек для
qmake
через командную строку, используйте:QMAKE_ARGS+= INCLUDEPATH+=${LOCALBASE}/include \ LIBS+=-L${LOCALBASE}/lib
Некорректные пути установки. Иногда данные, такие как иконки или файлы .desktop, по умолчанию устанавливаются в каталоги, которые не сканируются приложениями, совместимыми с XDG. Например, editors/texmaker — посмотрите на файл patch-texmaker.pro в директории files этого порта, чтобы увидеть шаблон исправления этой проблемы напрямую в проектом файле
qmake
.
6.14. Использование KDE
6.14.1. Определения переменных KDE
Если приложение зависит от KDE, установите USES+=kde:5
и USE_KDE
в список необходимых компонентов. Суффиксы _build
и _run
можно использовать для принудительного указания типа зависимости компонентов (например, baseapps_run
). Если суффикс не задан, будет использован тип зависимости по умолчанию. Чтобы принудительно задать оба типа, добавьте компонент дважды с обоими суффиксами (например, ecm_build ecm_run
). Доступные компоненты перечислены ниже (актуальный список компонентов также приведён в /usr/ports/Mk/Uses/kde.mk):
Имя | Описание |
---|---|
| Среда выполнения и библиотека KF5 для организации работы в отдельных автивностях |
| KF5 статистика для активностей |
| Системный сервис для управления активностью пользователей, отслеживания шаблонов использования |
| Хранилище данных для KDE-Pim |
| Интеграция Akonadi с Календарем |
| Консоль управления и отладки Akonadi |
| Библиотеки и демоны для реализации управления контактами в Akonadi |
| Импорт данных из других почтовых клиентов в KMail |
| Библиотеки и демоны для реализации базовой обработки электронной почты |
| Библиотека KDE для доступа к хранилищам почты в формате MBox |
| Библиотеки и демоны для реализации поиска в Akonadi |
| Читатель лент от KDE |
| KDE API для будильников KAlarm |
| Документация API KF5 |
| Библиотека KF5, предоставляющая классы для работы с форматами архивов |
| Библиотека API Open Collaboration Services, версия для KDE5 |
| Библиотека API Open Collaboration Services, версия для KDE5 |
| Абстракция KF5 для системной политики и функций аутентификации |
| KF5 Фреймворк для поиска и управления пользовательскими метаданными |
| Библиотека BalooWidgets |
| KF5 Фреймворк для поиска и управления пользовательскими метаданными |
| KDE API для доступа к веб-логам |
| Библиотека KF5 для закладок и формата XBEL |
| Plasma5 artwork, стили и ресурсы для визуального стиля Breeze |
| Plasma5 Breeze визуальный стиль для Gtk |
| Тема значков Breeze для KDE |
| Библиотека доступа к календарю KDE |
| Библиотеки поддержки календарей для KDEPim |
| Утилита KDE и пользовательские функции интерфейса для доступа к календарю |
| Библиотека KF5 для работы со строками |
| KF5 вспомогательные средства и виджеты автодополнения текста |
| Виджеты KF5 для диалогов настройки |
| Виджеты KF5 для диалогов настройки |
| KDE API для управления контактной информацией |
| KF5 аддоны для QtCore |
| Библиотека KF5 для обработки анализа сбоев и отчётов об ошибках в приложениях |
| KF5 дополнения к QtDBus |
| Библиотека Plasma5 для создания оформления окон |
| Интеграция KF5 виджетов Frameworks в Qt Designer/Creator |
| Инструменты управления пакетами Plasma5 |
| Абстракция KF5 для системных функций DNSSD |
| Генерация документации KF5 из docbook |
| Обработчик сбоев Plasma5 |
| Дополнительные модули и скрипты для CMake |
| Библиотека KF5 для преобразования эмотиконов |
| Библиотеки просмотра событий для KDEPim |
| Библиотека KF5 для извлечения метаданных файлов |
| Плагины рабочего пространства KF5 и интеграции фреймворков |
| Библиотека на основе KDE для доступа к сервисам Google |
| Библиотека KF5 для добавления поддержки глобальных сочетаний клавиш рабочего пространства |
| Редактор тем Grantlee |
| KDE PIM grantleetheme |
| Библиотека для поддержки gravatar |
| KF5 аддоны для QtGui |
| Библиотека KDE для календарных праздников |
| Библиотека Plasma5 для горячих клавиш |
| KF5 — расширенная инфраструктура интернационализации |
| Библиотека KF5 для работы с иконками в приложениях |
| KDE pim идентификации |
| Библиотека KF5 для мониторинга активности пользователей |
| KDE API для поддержки IMAP |
| Инцидентные редакторские библиотеки для KDEPim |
| Утилита Plasma5, предоставляющая системную информацию |
| Запускатель процессов KF5 для ускорения запуска приложений KDE |
| Модели KF5 для системы Qt Model/View |
| KF5 виджеты-дополнения для Qt Model/View |
| Виджеты KF5 для отслеживания экземпляра KJob |
| Библиотека KF5, предоставляющая интерпретатор ECMAScript |
| Библиотека KF5 для привязки объектов JavaScript к QObjects |
| Менеджер контактов KDE |
| Планировщик персональных сигналов тревоги |
| Планировщик персональных сигналов тревоги |
| Базовая структура редактора для системы KDE |
| KF5 утилиты для работы с KCModules |
| Неинтерактивные системные инструменты Plasma5 |
| Plasma5 конфигуратор GTK2 и GTK3 |
| Библиотека KF5, обеспечивающая интеграцию QML и KDE Frameworks |
| KF5 расширяемый демон для предоставления системных сервисов |
| Помощник в портировании KF5 из KDELibs4 |
| Дополнения KDE PIM |
| Библиотеки KDE PIM, связанные с почтой |
| Инструменты и службы KDE PIM |
| Дополнения Plasma5 для улучшения работы с Plasma |
| Интеграция KF5 с su для повышенных привилегий |
| Библиотека KF5, обеспечивающая интеграцию QtWebKit |
| Настройки гаммы монитора Plasma5 |
| Механизм рендеринга KF5 KTHML |
| Библиотека KF5, обеспечивающая поддержку дополнительных форматов изображений |
| Абстракция ресурсов и сетевого доступа KF5 |
| Набор компонентов на основе QtQuick |
| Модель данных и система извлечения информации о бронировании путешествий |
| Клиент электронной почты KDE |
| Клиент электронной почты KDE |
| Мастер настройки почтового аккаунта KDE |
| Редактор меню Plasma5 |
| Всплывающие примечания |
| KDE Персональный Органайзер |
| KDE Персональный Органайзер |
| KDE glue для встраивания KParts в Kontact |
| Программа для календаря и планирования |
| Реализация протокола DAV с KJobs |
| Библиотека для работы с файлами паролей Apple Wallet |
| KF5 мультиязыковые прикладные скрипты |
| Библиотека управления экраном Plasma5 |
| Архитектура безопасной блокировки экрана Plasma5 |
| Библиотека на основе задач для отправки электронной почты через SMTP-сервер |
| Plasma5 интерфейс для ssh-add |
| Утилита Plasma5 для отслеживания и управления запущенными процессами |
| Интеграция Plasma5 KWallet с PAM |
| Интеграционные плагины для рабочего стола на основе Wayland |
| Менеджер окон Plasma5 |
| Демон Plasma5, ожидающий сообщения wall и write |
| API доступа к LDAP для KDE |
| Библиотека KDE CDDB |
| Библиотека KDE для взаимодействия с аудио-CD |
| Интерфейс LibRaw для KDE |
| Библиотеки, используемые играми KDE |
| Библиотеки KDE PIM |
| Библиотека для чтения и записи файлов словарей |
| Интерфейс библиотеки Exiv2 для KDE |
| Интерфейс плагинов изображений KDE |
| Менеджер сертификатов для KDE |
| Интерфейс библиотеки SANE для KDE |
| Библиотека управления экраном Plasma5 |
| Библиотеки Sieve для KDEPim |
| Библиотека Plasma5 для отслеживания и управления запущенными процессами |
| Общие библиотеки для KDEPim |
| Импорт файлов mbox в KMail |
| Библиотека KDE для управления транспортом почты |
| Виртуальный глобус и мировой атлас для KDE |
| Библиотека KDE для доступа к хранилищам почты в формате MBox |
| Импорт файлов mbox в KMail |
| Интерфейс плагина KF5 для функций медиаплеера |
| Библиотека для обработки сообщений |
| Plasma5 Plasmoid для поиска |
| Библиотека для обработки данных MIME |
| Библиотека KF5 для загрузки ресурсов приложений из сети |
| Абстракция KF5 для системных уведомлений |
| Система конфигурации KF5 для KNotify |
| Универсальная программа для просмотра документов KDE |
| Стиль Plasma5 Oxygen |
| Тема иконок Oxygen для KDE |
| Библиотека KF5 для загрузки и установки пакетов |
| KF5 система плагинов для работы с документами |
| Библиотека KF5, предоставляющая доступ к контактам |
| Импорт и экспорт настроек KDE PIM |
| Общие библиотеки для KDEPim |
| Библиотека KDE для утилит редактирования текста, специфичных для PIM |
| Компоненты Plasma5 для интеграции браузеров в рабочий стол |
| Plasma5 рабочий стол Plasma |
| KF5 - среда выполнения пользовательского интерфейса на основе плагинов, используемая для создания пользовательских интерфейсов |
| Плагины интеграции Qt Platform Theme для рабочего окружения Plasma |
| Plasma5 Микшер звука Plasma Pulse |
| Приложения Plasma5, полезные для разработки Plasma |
| Plasma5 Рабочее пространство Plasma |
| Обои Plasma5 |
| KF5 облегченный фреймворк для построения графиков |
| Демон Plasma5, предоставляющий интерфейс аутентификации polkit |
| Инструмент Plasma5 для управления настройками энергопотребления |
| Интерфейс API для создания штрихкодов |
| Абстракция pty KF5 |
| Предлагает доступные действия для конкретной цели |
| Стиль Qt QuickControl2 для KDE |
| KF5 параллелизованная система запросов |
| KF5 расширенные плагины и интроспекция сервисов |
| Интеграция и обнаружение оборудования KF5 |
| KF5 библиотека проверки орфографии на основе плагинов |
| Библиотека KDE для обработки RSS-лент |
| Движок подсветки синтаксиса KF5 для структурированного текста и кода |
| Настройки системы Plasma5 |
| KF5 продвинутый встраиваемый текстовый редактор |
| KF5 расширенные виджеты для редактирования текста |
| KF5 дополнения к QtDBus |
| KDE API для обработки данных TNEF |
| Библиотека KF5 для преобразования единиц измерения |
| Пользовательский менеджер Plasma5 |
| KF5 безопасный и унифицированный контейнер для паролей пользователей |
| Обёртка клиентской и серверной библиотек KF5 для библиотек Wayland |
| KF5 аддоны для QtWidgets |
| Библиотека KF5 для доступа к оконной системе |
| KF5 настраиваемые пользователем главные окна |
| Взаимодействие KF5 с XMLRPC-сервисами |
USE_KDE
Это простой пример порта для KDE. USES= cmake
указывает порту использовать CMake, инструмент конфигурации, широко применяемый в проектах KDE (см. Использование cmake
для подробного описания). USE_KDE
добавляет зависимость от библиотек KDE. Необходимые компоненты KDE и другие зависимости можно определить через лог конфигурации. USE_KDE
не подразумевает USE_QT
. Если порту требуются некоторые компоненты Qt, укажите их в USE_QT
.
USES= cmake kde:5 qt:5 USE_KDE= ecm USE_QT= core buildtools_build qmake_build
6.15. Использование LXQt
Приложения, зависящие от LXQt, должны устанавливать USES+= lxqt
и задавать USE_LXQT
списком необходимых компонентов из таблицы ниже
Имя | Описание |
---|---|
| Помощники для дополнительных модулей CMake |
| Привязки Libfm к Qt |
| Ядро библиотеки LXQt |
| Реализация Qt спецификаций freedesktop.org XDG |
USE_LXQT
Это простой пример, USE_LXQT
добавляет зависимость от библиотек LXQt. Необходимые компоненты LXQt и другие зависимости можно определить из лога конфигурации.
USES= cmake lxqt qt:5 tar:xz USE_QT= core dbus widgets buildtools_build qmake_build USE_LXQT= buildtools libfmqt
6.16. Использование Java
6.16.1. Определения переменных
Если порту требуется Java™ Development Kit (JDK™) для сборки, запуска или даже извлечения distfile, определите USE_JAVA
.
В коллекции портов доступно несколько JDK от различных поставщиков и в нескольких версиях. Если порт должен использовать определённую версию, укажите её с помощью переменной JAVA_VERSION
. Самая актуальная версия — java/openjdk18, также доступны java/openjdk17, java/openjdk16, java/openjdk15, java/openjdk14, java/openjdk13, java/openjdk12, java/openjdk11, java/openjdk8 и java/openjdk7.
Переменная | Значение |
---|---|
| Определите для остальных переменных, чтобы они имели какой-либо эффект. |
| Список подходящих версий Java для порта, разделённых пробелами.
Необязательный символ |
| Список разделенных пробелами подходящих операционных систем портов JDK для порта (допустимые значения: |
| Список подходящих поставщиков портов JDK для порта через пробел (допустимые значения: |
| Когда установлено, добавляет выбранный порт JDK в зависимости сборки. |
| Когда установлено, добавляет выбранный порт JDK в зависимости времени выполнения. |
| Когда установлено, добавляет выбранный порт JDK в зависимости для извлечения. |
Ниже приведен список всех настроек, которые порт получит после установки USE_JAVA
:
Переменная | Значение |
---|---|
| Имя порта JDK (например, |
| Полная версия порта JDK (например, |
| Операционная система, используемая портом JDK (например, |
| Поставщик порта JDK (например, |
| Описание операционной системы, используемой портом JDK (например, |
| Описание поставщика порта JDK (например, |
| Путь к каталогу установки JDK (например, '/usr/local/openjdk6'). |
| Путь к используемому компилятору Java (например, '/usr/local/openjdk6/bin/javac'). |
| Путь к инструменту |
| Путь к утилите |
| Путь к исполняемому файлу |
| Путь к программе |
| Путь к программе |
| Путь к программе |
| Путь к утилите |
| Путь к инструменту |
| Путь к программе |
| Путь к утилите |
| Путь к генератору RMI-заглушек/скелетов, |
| Путь к программе реестра RMI, |
| Путь к программе демона RMI |
| Путь к архиву, содержащему файлы классов JDK, ${JAVA_HOME}/jre/lib/rt.jar. |
Используйте цель java-debug
в make для получения информации для отладки порта. Она отобразит значения многих из перечисленных ранее переменных.
Кроме того, определены следующие константы, чтобы все порты Java могли быть установлены единообразно:
Константа | Значение |
---|---|
| Базовый каталог для всего, связанного с Java. По умолчанию: ${PREFIX}/share/java. |
| Каталог, в котором установлены JAR-файлы. По умолчанию: ${JAVASHAREDIR}/classes. |
| Каталог, в котором расположены JAR-файлы, установленные другими портами. По умолчанию: ${LOCALBASE}/share/java/classes. |
Связанные записи определены как в PLIST_SUB
(документировано в Изменение pkg-plist на основе переменных Make), так и в SUB_LIST
.
6.16.2. Сборка с Ant
Когда порт должен собираться с использованием Apache Ant, он должен определять USE_ANT
. Таким образом, Ant считается командой sub-make. Если цель do-build
не определена в порте, будет установлена цель по умолчанию, которая запускает Ant в соответствии с MAKE_ENV
, MAKE_ARGS
и ALL_TARGET
. Это аналогично механизму USES= gmake
, который документирован в Building Mechanisms.
6.16.3. Лучшие практики
При переносе библиотеки Java порт должен устанавливать JAR-файл(ы) в ${JAVAJARDIR}, а все остальное — в ${JAVASHAREDIR}/${PORTNAME} (за исключением документации, см. ниже). Чтобы уменьшить размер упаковочного файла, ссылайтесь на JAR-файл(ы) напрямую в Makefile. Используйте следующую инструкцию (где myport.jar — имя JAR-файла, устанавливаемого как часть порта):
PLIST_FILES+= ${JAVAJARDIR}/myport.jar
При переносе Java-приложения порт обычно устанавливает все компоненты в единый каталог (включая зависимости в виде JAR-файлов). В этом отношении настоятельно рекомендуется использовать ${JAVASHAREDIR}/${PORTNAME}. Портеру предстоит решить, устанавливать ли дополнительные JAR-зависимости в этот каталог или использовать уже установленные (из ${JAVAJARDIR}).
При переносе Java™-приложения, которое требует сервера приложений, такого как www/tomcat7, для запуска службы, вендор часто распространяет файл .war. .war — это веб-архив приложения (Web application ARchive), который извлекается при вызове приложением. Избегайте добавления .war в pkg-plist. Это не считается лучшей практикой. Сервер приложений развернет архив war, но не очистит его должным образом при удалении порта. Более предпочтительный способ работы с этим файлом — извлечь архив, затем установить файлы и, наконец, добавить эти файлы в pkg-plist.
TOMCATDIR= ${LOCALBASE}/apache-tomcat-7.0 WEBAPPDIR= myapplication post-extract: @${MKDIR} ${WRKDIR}/${PORTDIRNAME} @${TAR} xf ${WRKDIR}/myapplication.war -C ${WRKDIR}/${PORTDIRNAME} do-install: cd ${WRKDIR} && \ ${INSTALL} -d -o ${WWWOWN} -g ${WWWGRP} ${TOMCATDIR}/webapps/${PORTDIRNAME} cd ${WRKDIR}/${PORTDIRNAME} && ${COPYTREE_SHARE} \* ${WEBAPPDIR}/${PORTDIRNAME}
Независимо от типа порта (библиотека или приложение), дополнительная документация устанавливается в том же месте, что и для любого другого порта. Известно, что инструмент Javadoc создает разный набор файлов в зависимости от версии используемого JDK. Для портов, которые не требуют использования конкретной версии JDK, указание списка упаковки (pkg-plist) становится сложной задачей. Это одна из причин, по которой разработчикам портов настоятельно рекомендуется использовать PORTDOCS
. Более того, даже если набор файлов, генерируемых javadoc
, можно предсказать, размер результирующего pkg-plist говорит в пользу использования PORTDOCS
.
Значение по умолчанию для DATADIR
— ${PREFIX}/share/${PORTNAME}. Рекомендуется переопределить DATADIR
на ${JAVASHAREDIR}/${PORTNAME} для портов Java. Действительно, DATADIR
автоматически добавляется в PLIST_SUB
(документировано в Изменение pkg-plist на основе переменных Make), поэтому используйте %%DATADIR%%
напрямую в pkg-plist.
Что касается выбора между сборкой портов Java из исходного кода или их непосредственной установкой из бинарного дистрибутива, на момент написания документации определённой политики не существует. Однако участники FreeBSD Java Project рекомендуют сопровождающим портов по возможности собирать их из исходного кода, если это не представляет сложностей.
Все функции, представленные в этом разделе, реализованы в bsd.java.mk. Если порту требуется более сложная поддержка Java, сначала ознакомьтесь с историей изменений bsd.java.mk, так как документирование новых функций обычно занимает некоторое время. Затем, если отсутствующая поддержка будет полезна для многих других Java-портов, не стесняйтесь обсудить это на списке рассылки freebsd-java.
Хотя существует категория java
для PR, она относится к усилиям по портированию JDK в рамках проекта FreeBSD Java. Поэтому отправляйте порт Java в категорию ports
, как и любой другой порт, если только проблема не связана либо с реализацией JDK, либо с bsd.java.mk.
Аналогично существует определённая политика в отношении CATEGORIES
для портов Java, которая подробно описана в Категоризация.
6.17. Веб-приложения, Apache и PHP
6.17.1. Apache
| Порт требует Apache. Возможные значения: |
| Полный путь к бинарному файлу |
| Полный путь к бинарному файлу |
| Версия установленной Apache (переменная только для чтения). Эта переменная доступна только после включения bsd.port.pre.mk. Возможные значения: |
| Каталог для модулей Apache. Эта переменная автоматически раскрывается в pkg-plist. |
| Каталог для заголовков Apache. Эта переменная автоматически раскрывается в pkg-plist. |
| Каталог для файлов конфигурации Apache. Эта переменная автоматически раскрывается в pkg-plist. |
| Имя модуля. Значение по умолчанию — |
| Короткое имя модуля. Автоматически определяется из |
| Используйте |
| Также автоматически создаёт файл pkg-plist. |
| Добавляет каталог в путь поиска заголовков во время компиляции. |
| Добавляет каталог в путь поиска библиотек во время компиляции. |
| Дополнительные флаги для передачи в |
6.17.2. Веб-приложения
Веб-приложения должны быть установлены в PREFIX/www/appname. Этот путь доступен как в Makefile, так и в pkg-plist как WWWDIR
, а путь относительно PREFIX
доступен в Makefile как WWWDIR_REL
.
Пользователь и группа процесса веб-сервера доступны как WWWOWN
и WWWGRP
, если необходимо изменить владельца некоторых файлов. Значения по умолчанию для обоих — www
. Используйте WWWOWN?= myuser
и WWWGRP?= mygroup
, если порту требуются другие значения. Это позволяет пользователю легко их переопределить.
Используйте |
Не зависьте от Apache, если веб-приложение явно не требует Apache. Учитывайте, что пользователи могут захотеть запускать веб-приложение на другом веб-сервере, кроме Apache.
6.17.3. PHP
Веб-приложения PHP объявляют свою зависимость от него с помощью USES=php
. Подробнее см. в php
.
6.17.4. Модули PEAR
Портирование модулей PEAR — это очень простой процесс.
Добавьте USES=pear
в Makefile порта. Фреймворк установит соответствующие файлы в нужные места и автоматически сгенерирует plist во время установки.
PORTNAME= Date DISTVERSION= 1.4.3 CATEGORIES= devel www pear MAINTAINER= someone@example.org COMMENT= PEAR Date and Time Zone Classes WWW= https://pear.php.net/package/Date/ USES= pear .include <bsd.port.mk>
Модули PEAR будут автоматически преобразованы в порт с флейвором с использованием флейворов PHP. |
Если используется нестандартный |
Модули PEAR не требуют определения |
6.17.4.1. Модули Horde
Также и перенос модулей Horde является простым процессом.
Добавьте USES=horde
в Makefile порта. Фреймворк установит соответствующие файлы в нужные места и автоматически сгенерирует plist во время установки.
Переменные USE_HORDE_BUILD
и USE_HORDE_RUN
могут использоваться для добавления зависимостей времени сборки и выполнения от других модулей Horde. Полный список доступных модулей можно найти в Mk/Uses/horde.mk.
PORTNAME= Horde_Core DISTVERSION= 2.14.0 CATEGORIES= devel www pear MAINTAINER= horde@FreeBSD.org COMMENT= Horde Core Framework libraries WWW= https://pear.horde.org/ OPTIONS_DEFINE= KOLAB SOCKETS KOLAB_DESC= Enable Kolab server support SOCKETS_DESC= Depend on sockets PHP extension USES= horde USE_PHP= session USE_HORDE_BUILD= Horde_Role USE_HORDE_RUN= Horde_Role Horde_History Horde_Pack \ Horde_Text_Filter Horde_View KOLAB_USE= HORDE_RUN=Horde_Kolab_Server,Horde_Kolab_Session SOCKETS_USE= PHP=sockets .include <bsd.port.mk>
Поскольку модули Horde также являются модулями PEAR, они будут автоматически преобразованы с использованием флейворов PHP. |
6.18. Использование Python
Коллекция портов поддерживает параллельную установку нескольких версий Python. Порты должны использовать правильный интерпретатор python
в соответствии с настраиваемым пользователем параметром PYTHON_VERSION
. Важнее всего заменить путь к исполняемому файлу python
в скриптах на значение PYTHON_CMD
.
Порты, которые устанавливают файлы в PYTHON_SITELIBDIR
, должны использовать префикс имени пакета pyXY-
, чтобы их имя пакета включало версию Python, для которой они предназначены.
PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}
| Порту требуется Python. Минимально необходимая версия может быть указана с такими значениями, как |
| Используйте Python distutils для настройки, компиляции и установки. Это требуется, когда порт поставляется с setup.py. Это переопределяет цели |
| Создать список пакетов автоматически. Это также требует установки |
| Порт будет использовать уникальный префикс, обычно |
| Порт не использует distutils, но по-прежнему поддерживает несколько версий Python. |
| Если текущая версия Python не является версией по умолчанию, порт получит |
| Используется как |
| Расположение дерева site-packages, которое содержит путь установки Python (обычно |
| Вариант PREFIX-clean для PYTHON_SITELIBDIR. Всегда используйте |
| Интерпретатор командной строки Python, включая номер версии. |
| Строка зависимости для числового расширения. |
| Строка зависимости для нового числового расширения, numpy. (PYNUMERIC устарел у вендора). |
| Строка зависимости для расширения XML (не требуется для Python 2.0 и выше, так как оно также входит в базовую поставку). |
| Условная зависимость от пакета devel/py-enum34 в зависимости от версии Python. |
| Условная зависимость от пакета devel/py-enum-compat в зависимости от версии Python. |
| Условная зависимость от пакета devel/py-pathlib в зависимости от версии Python. |
| Условная зависимость от пакета net/py-ipaddress в зависимости от версии Python. |
| Условная зависимость от пакета devel/py-futures в зависимости от версии Python. |
Полный список доступных переменных можно найти в /usr/ports/Mk/Uses/python.mk.
Все зависимости для портов Python, использующих флейворы Python (с |
PORTNAME= sample DISTVERSION= 1.2.3 CATEGORIES= devel MAINTAINER= fred.bloggs@example.com COMMENT= Python sample module WWW= https://example.com/project/sample/ RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR} USES= python USE_PYTHON= autoplist distutils .include <bsd.port.mk>
Некоторые приложения на Python заявляют о поддержке DESTDIR
(что необходимо для промежуточной сборки), но она не работает (например, Mailman до версии 2.1.16). Это можно обойти, перекомпилировав скрипты. Это можно сделать, например, в цели post-build
. Предполагая, что Python-скрипты должны находиться в PYTHONPREFIX_SITELIBDIR
после установки, можно применить следующее решение:
(cd ${STAGEDIR}${PREFIX} \ && ${PYTHON_CMD} ${PYTHON_LIBDIR}/compileall.py \ -d ${PREFIX} -f ${PYTHONPREFIX_SITELIBDIR:S;${PREFIX}/;;})
Это перекомпилирует исходники с путём, относительным к stage-директории, и добавляет значение PREFIX
к имени файла, записанному в байт-компилированном выходном файле с помощью -d
. -f
требуется для принудительной перекомпиляции, а :S;${PREFIX}/;;
удаляет префиксы из значения PYTHONPREFIX_SITELIBDIR
, чтобы сделать его относительным к PREFIX
.
6.19. Использование Tcl/Tk
Коллекция Ports поддерживает параллельную установку нескольких версий Tcl/Tk. Порты должны стараться поддерживать как минимум версию Tcl/Tk по умолчанию и выше с помощью USES=tcl
. Можно указать желаемую версию tcl
, добавив :_xx_
, например, USES=tcl:85
.
| выбранная версия Tcl major.minor |
| полный путь к интерпретатору Tcl |
| путь к библиотекам Tcl |
| путь к заголовочным файлам Tcl C |
| Префикс библиотеки, согласно TIP595 |
| Заглушка библиотеки postfix |
| выбранная версия Tk major.minor |
| полный путь к интерпретатору Tk |
| путь к библиотекам Tk |
| путь к заголовочным файлам Tk C |
См. USES=tcl
и USES=tk
в Использование макросов USES
для полного описания этих переменных. Полный список этих переменных доступен в /usr/ports/Mk/Uses/tcl.mk.
6.20. Использование SDL
USE_SDL
используется для автоматической настройки зависимостей для портов, которые используют библиотеку на основе SDL, такие как devel/sdl12 и graphics/sdl_image.
Эти библиотеки SDL для версии 1.2 распознаются:
sdl: devel/sdl12
console: devel/sdl_console
gfx: graphics/sdl_gfx
image: graphics/sdl_image
mixer: audio/sdl_mixer
mm: devel/sdlmm
net: net/sdl_net
pango: x11-toolkits/sdl_pango
sound: audio/sdl_sound
ttf: graphics/sdl_ttf
Эти библиотеки SDL для версии 2.0 распознаются:
sdl: devel/sdl20
gfx: graphics/sdl2_gfx
image: graphics/sdl2_image
mixer: audio/sdl2_mixer
net: net/sdl2_net
ttf: graphics/sdl2_ttf
Следовательно, если порт зависит от net/sdl_net и audio/sdl_mixer, синтаксис будет следующим:
USE_SDL= net mixer
Пакет зависимости devel/sdl12, который требуется для net/sdl_net и audio/sdl_mixer, также автоматически добавляется.
Использование USE_SDL
с указанием SDL 1.2 автоматически:
Добавить зависимость от sdl12-config в
BUILD_DEPENDS
Добавьте переменную
SDL_CONFIG
вCONFIGURE_ENV
Добавьте зависимости выбранных библиотек в
LIB_DEPENDS
Используя USE_SDL
с записями для SDL 2.0, это автоматически:
Добавить зависимость от sdl2-config в
BUILD_DEPENDS
Добавьте переменную
SDL2_CONFIG
вCONFIGURE_ENV
Добавьте зависимости выбранных библиотек в
LIB_DEPENDS
6.21. Использование wxWidgets
Этот раздел описывает состояние библиотек wxWidgets в дереве портов и их интеграцию с системой портов.
6.21.1. Введение
Существует множество версий библиотек wxWidgets, которые конфликтуют между собой (устанавливают файлы с одинаковыми именами). В дереве портов эта проблема решена путем установки каждой версии под разными именами с использованием суффиксов номеров версий.
Очевидный недостаток этого подхода заключается в том, что каждое приложение необходимо модифицировать для поиска нужной версии. К счастью, большинство приложений вызывают скрипт wx-config
для определения необходимых флагов компилятора и компоновщика. Имя этого скрипта отличается для каждой доступной версии. Большинство приложений учитывают переменную окружения или принимают аргумент configure, чтобы указать, какой скрипт wx-config
вызывать. В противном случае их необходимо патчить.
6.21.2. Выбор версии
Чтобы порт использовал определённую версию wxWidgets, доступны две переменные для определения (если задана только одна, другая будет установлена в значение по умолчанию):
Переменная | Описание | Значение по умолчанию |
---|---|---|
| Список версий, которые порт может использовать | Все доступные версии |
| Список версий, которые порт не может использовать | Ничего |
Доступные версии wxWidgets и соответствующие порты в дереве:
Версия | Порт |
---|---|
| |
|
Переменные в Переменные для выбора версий wxWidgets могут быть установлены в одну или несколько комбинаций, разделенных пробелами:
Описание | Пример |
---|---|
Единственная версия |
|
Возрастающий диапазон |
|
Нисходящий диапазон |
|
Полный диапазон (должен быть возрастающим) |
|
Существуют также переменные для выбора предпочтительных версий из доступных. Их можно установить в виде списка версий, где первые будут иметь более высокий приоритет.
Имя | Предназначен для |
---|---|
| порт |
| пользователь |
6.21.3. Выбор компонентов
Существуют другие приложения, которые, не являясь библиотеками wxWidgets, связаны с ними. Эти приложения можно указать в WX_COMPS
. Доступны следующие компоненты:
Имя | Описание | Ограничение версии |
---|---|---|
| основная библиотека | none |
| сторонние библиотеки |
|
| wxPython (интерфейс Python) |
|
Тип зависимости может быть выбран для каждого компонента путем добавления суффикса, разделенного точкой с запятой. Если он отсутствует, будет использоваться тип по умолчанию (см. Типы зависимостей wxWidgets по умолчанию). Доступны следующие типы:
Имя | Описание |
---|---|
| Компонент необходим для сборки, эквивалентен |
| Компонент необходим для запуска, эквивалентно |
| Компонент необходим для сборки и запуска, эквивалентен |
Значения по умолчанию для компонентов подробно описаны в этой таблице:
Компонент | Тип зависимости |
---|---|
|
|
|
|
|
|
|
|
|
|
Этот фрагмент соответствует порту, который использует wxWidgets версии 2.4
и дополнительные библиотеки.
USE_WX= 2.8 WX_COMPS= wx contrib
6.21.4. Обнаружение установленных версий
Для определения установленной версии определите WANT_WX
. Если значение не задано для конкретной версии, компоненты будут иметь суффикс версии. HAVE_WX
будет заполнен после обнаружения.
Этот фрагмент может использоваться в порте, который использует wxWidgets, если они установлены или выбран соответствующий параметр.
WANT_WX= yes .include <bsd.port.pre.mk> .if defined(WITH_WX) || !empty(PORT_OPTIONS:MWX) || !empty(HAVE_WX:Mwx-2.8) USE_WX= 2.8 CONFIGURE_ARGS+= --enable-wx .endif
Этот фрагмент может использоваться в порте, который включает поддержку wxPython, если она установлена или выбрана соответствующая опция, в дополнение к wxWidgets, обе версии 2.8
.
USE_WX= 2.8 WX_COMPS= wx WANT_WX= 2.8 .include <bsd.port.pre.mk> .if defined(WITH_WXPYTHON) || !empty(PORT_OPTIONS:MWXPYTHON) || !empty(HAVE_WX:Mpython) WX_COMPS+= python CONFIGURE_ARGS+= --enable-wxpython .endif
6.21.5. Переменные, определенные в фреймворке
Эти переменные доступны в порте (после определения одной из переменных для выбора версий wxWidgets).
Имя | Описание |
---|---|
| Путь к скрипту |
| Путь к программе |
| Версия wxWidgets, которая будет использоваться (например, |
6.21.6. Обработка в bsd.port.pre.mk
Определите WX_PREMK
, чтобы иметь возможность использовать переменные сразу после включения bsd.port.pre.mk.
При определении |
Этот фрагмент иллюстрирует использование WX_PREMK
путем запуска скрипта wx-config
для получения полной строки версии, присвоения её переменной и передачи в программу.
USE_WX= 2.8 WX_PREMK= yes .include <bsd.port.pre.mk> .if exists(${WX_CONFIG}) VER_STR!= ${WX_CONFIG} --release PLIST_SUB+= VERSION="${VER_STR}" .endif
Переменные wxWidgets можно безопасно использовать в командах внутри целей без необходимости в |
6.21.7. Дополнительные параметры configure
Некоторые скрипты GNU configure
не могут найти wxWidgets, если задана только переменная окружения WX_CONFIG
, и требуют дополнительные параметры. WX_CONF_ARGS
можно использовать для их указания.
Возможное значение | Получаемый параметр |
---|---|
|
|
|
|
6.22. Использование Lua
Этот раздел описывает состояние библиотек Lua в дереве портов и их интеграцию с системой портов.
6.22.1. Введение
Существует множество версий библиотек Lua и соответствующих интерпретаторов, которые конфликтуют между собой (устанавливают файлы с одинаковыми именами). В дереве портов эта проблема решена установкой каждой версии под разными именами с использованием суффиксов номеров версий.
Очевидный недостаток этого заключается в том, что каждое приложение необходимо модифицировать для поиска ожидаемой версии. Однако это можно решить, добавив дополнительные флаги компилятору и компоновщику.
Приложения, использующие Lua, обычно должны собираться только для одной версии. Однако загружаемые модули для Lua собираются в отдельных флейворах для каждой поддерживаемой версии Lua, и зависимости от таких модулей должны указывать флейвор с использованием суффикса @${LUA_FLAVOR}
в расположении (origin) порта.
6.22.2. Выбор версии
Порт, использующий Lua, должен содержать строку следующего вида:
USES= lua
Если требуется определённая версия Lua или диапазон версий, его можно указать в виде параметра XY
(который можно использовать несколько раз), XY+
, -XY
или XY-ZA
. Версия Lua, установленная через DEFAULT_VERSIONS
, будет использована, если она попадает в запрошенный диапазон, в противном случае будет использована ближайшая к умолчанию запрошенная версия. Например:
USES= lua:52-53
Обратите внимание, что не предпринимается попытка изменить выбор версии на основе наличия любой уже установленной версии Lua.
Форма указания версии |
6.22.3. Конфигурация и флаги компилятора
Программное обеспечение, использующее Lua, может быть написано с автоматическим определением версии Lua в использовании. В общем случае порты должны переопределять это предположение и принудительно использовать конкретную выбранную версию Lua, как описано выше. В зависимости от портируемого программного обеспечения, это может потребовать любого или всех из следующих действий:
Использование
LUA_VER
в качестве части параметра для скрипта конфигурации программного обеспечения черезCONFIGURE_ARGS
илиCONFIGURE_ENV
(или эквивалентные для других систем сборки);Добавление
-I${LUA_INCDIR}
,-L${LUA_LIBDIR}
и-llua-${LUA_VER}
вCFLAGS
,LDFLAGS
иLIBS
соответственно, где это необходимо;Исправьте конфигурационные или файлы сборки программного обеспечения, чтобы выбрать правильную версию.
6.22.4. Флейворы версии
Порт, который устанавливает модуль Lua (а не приложение, просто использующее Lua), должен собирать отдельный флейвор для каждой поддерживаемой версии Lua. Это делается путем добавления параметра module
:
USES= lua:module
Так же может быть указае номер версии или диапазон версий. Используйте запятую для разделения параметров.
Поскольку каждый флейвор должен иметь уникальное имя пакета, предоставляется переменная LUA_PKGNAMEPREFIX
, которая будет установлена в соответствующее значение; предполагаемое использование:
PKGNAMEPREFIX= ${LUA_PKGNAMEPREFIX}
Модульные порты обычно должны устанавливать файлы только в LUA_MODLIBDIR
, LUA_MODSHAREDIR
, LUA_DOCSDIR
и LUA_EXAMPLESDIR
, все из которых настроены на ссылки в версионно-зависимые подкаталоги. Установка любых других файлов должна выполняться с осторожностью, чтобы избежать конфликтов между версиями.
Порт (кроме модуля Lua), который хочет собрать отдельный пакет для каждой версии Lua, должен использовать параметр flavors
:
USES= lua:flavors
Это работает так же, как параметр module
, описанный выше, но без предположения, что пакет должен быть задокументирован как модуль Lua (поэтому LUA_DOCSDIR
и LUA_EXAMPLESDIR
по умолчанию не определены). Однако порт может определить LUA_DOCSUBDIR
как подходящее имя подкаталога (обычно PORTNAME
порта, если это не конфликтует с PORTNAME
любого модуля), и в этом случае фреймворк определит как LUA_DOCSDIR
, так и LUA_EXAMPLESDIR
.
Как и в случае с модульными портами, порт с флейворами должен избегать установки файлов, которые могут конфликтовать между версиями. Обычно это достигается добавлением LUA_VER_STR
в качестве суффикса к именам программ (например, с использованием uniquefiles
), а также использованием LUA_VER
или LUA_VER_STR
в составе других файлов или поддиректорий, используемых вне LUA_MODLIBDIR
и LUA_MODSHAREDIR
.
6.22.5. Переменные, определенные в фреймворке
В порте доступны эти переменные.
Имя | Описание |
---|---|
| Версия Lua, которая будет использоваться (например, |
| Версия Lua без точек (например, |
| Имя флейвора, соответствующее выбранной версии Lua, используемое для указания зависимостей |
| Префикс, который должен использоваться для поиска Lua (и компонентов), уже установленных |
| Префикс, куда этим портом будут установлены Lua (и компоненты) |
| Каталог, в котором установлены заголовочные файлы Lua |
| Каталог, в котором установлены библиотеки Lua |
| Каталог, в котором находятся уже установленные библиотеки модулей Lua (.so) |
| Каталог, в котором находятся установленные модули Lua (.lua) |
| Каталог, в котором библиотеки модулей Lua (.so) должны быть установлены данным портом |
| Каталог, в котором должны быть установлены модули Lua (.lua) данным портом |
| Префикс имени пакета, используемый модулями Lua |
| Название интерпретатора Lua (например, |
| Название компилятора Lua (например, |
Эти дополнительные переменные доступны для портов, которые указали параметр module
:
Имя | Описание |
---|---|
| каталог, в который должна быть установлена документация модуля. |
| каталог, в который должны быть установлены примеры файлов модуля. |
6.22.6. Примеры
Makefile
для приложения, использующего LuaЭтот пример показывает, как сослаться на модуль Lua, требуемый во время выполнения. Обратите внимание, что ссылка должна указывать флейвор.
PORTNAME= sample DISTVERSION= 1.2.3 CATEGORIES= whatever MAINTAINER= fred.bloggs@example.com COMMENT= Sample WWW= https://example.com/lua_sample/sample/ RUN_DEPENDS= ${LUA_REFMODLIBDIR}/lpeg.so:devel/lua-lpeg@${LUA_FLAVOR} USES= lua .include <bsd.port.mk>
Makefile
для простого модуля LuaPORTNAME= sample DISTVERSION= 1.2.3 CATEGORIES= whatever PKGNAMEPREFIX= ${LUA_PKGNAMEPREFIX} MAINTAINER= fred.bloggs@example.com COMMENT= Sample WWW= https://example.com/lua_sample/sample/ USES= lua:module DOCSDIR= ${LUA_DOCSDIR} .include <bsd.port.mk>
6.23. Использование Guile
Этот раздел описывает состояние Guile в дереве портов и его интеграцию с системой портов.
6.23.1. Введение
Существует несколько версий библиотек Guile и соответствующих интерпретаторов, которые конфликтуют между собой (устанавливают файлы с одинаковыми именами). В дереве портов эта проблема решена путем установки каждой версии под разными именами с использованием суффиксов номеров версий. В большинстве случаев приложения должны определять правильную версию из предоставленных конфигурационных переменных и использовать pkg-config
для определения имени и связанных путей. Однако некоторые приложения (особенно те, которые используют собственные правила конфигурации для cmake
или meson
) всегда будут пытаться использовать последнюю доступную версию. В этом случае либо исправьте порт, либо объявите конфликт сборки (см. опцию conflicts
ниже), чтобы гарантировать создание правильной зависимости при сборке вне poudriere.
Приложения, использующие Guile, обычно должны собираться только для одной версии, предпочтительно указанной в DEFAULT_VERSIONS
, или, если это невозможно, для последней поддерживаемой версии. Однако библиотеки Guile или Scheme, а также модули расширения для Guile собираются в отдельных флейворах для каждой поддерживаемой версии Guile. Зависимости от таких портов должны указывать флейвор с использованием суффикса @${GUILE_FLAVOR}
в расположении (origin) порта.
6.23.2. Выбор версии
Порт, использующий Guile, должен определять USES=guile:arg,arg…
с соответствующими параметрами следующим образом:
Имя | Описание |
---|---|
| Объявить совместимость с версией Guile |
| Создать флейвор для каждой указанной версии Guile.
Версия, указанная в |
| Добавить интерпретатор Guile только как зависимость для сборки, а не как зависимость библиотеки.
|
| Добавить интерпретатор Guile только как зависимость во время выполнения, а не как зависимость от библиотеки.
|
| Добавить значения |
| Объявить |
Некоторые дополнительные аргументы доступны для обработки нестандартных случаев; подробности см. в Mk/Uses/guile.mk
.
Если не указано build
или run
, то LIB_DEPENDS
получает зависимость от библиотеки libguile
, а также любые дополнительные зависимости, требуемые версией guile, например, libgc
. Обычно порту не требуются дополнительные зависимости, связанные с использованием Guile.
6.23.3. Флаги конфигурации
Программное обеспечение, использующее Guile, должно использовать механизм pkg-config
для получения флагов компилятора и компоновщика. Некоторые старые или экзотические порты могут использовать guile-config
или получать значения напрямую из guile
, что также должно работать (в некоторых из этих случаев может быть полезен аргумент alias
).
Фреймворк пытается сообщить порту желаемую версию Guile, используя следующие методы:
GUILE_EFFECTIVE_VERSION
добавлен вCONFIGURE_ENV
;Полный путь к исполняемому файлу Guile указан в переменной
GUILE
вCONFIGURE_ENV
иMAKE_ENV
;Если используется опция
alias
, то желаемые версии бинарных файлов Guile являются теми, которые имеют алиасы;Если параметр
alias
не используется, пути к инструментам нужной версии Guile (guild
,guile-config
и т.д.) добавляются вCONFIGURE_ENV
иMAKE_ENV
в виде переменныхGUILD
,GUILE_CONFIG
и т.д.
Для некоторых портов может потребоваться указать версию дополнительными способами, например, через CONFIGURE_ARGS
или MESON_ARGS
, в зависимости от порта.
Если ни один из этих методов не приводит к тому, что порт выбирает указанную версию Guile при наличии других версий, то предпочтительно исправить его, чтобы это происходило. Если это невозможно, укажите опцию conflicts
, чтобы предотвратить сборку порта в условиях, когда он обнаруживает неправильную версию.
6.23.4. Флейворы версии
Порт, который устанавливает расширение или библиотеку Guile, или библиотеку Scheme, которая предварительно компилируется для Guile, должен собирать отдельный флейвор для каждой поддерживаемой версии Guile. Это делается путем добавления опции flavors
.
Поскольку каждый флейвор должен иметь уникальное имя пакета, такие порты обычно устанавливают PKGNAMESUFFIX
, например:
PKGNAMESUFFIX= -${FLAVOR}
Такие порты должны устанавливать файлы Scheme в GUILE_SITE_DIR
, а не в GUILE_GLOBAL_SITE_DIR
, даже если файлы не зависят от версии. Это часто требует исправления порта.
Кроме того, если такой порт устанавливает файл .pc
, он должен быть размещён в GUILE_PKGCONFIG_PATH
, а не в глобальной директории pkgconfig
. Это позволяет зависимым портам находить правильную конфигурацию для используемой версии Guile.
Если порт расширения Guile устанавливает файл .so
, то обычно он должен быть размещён в специфичной для версии Guile директории extensions
. Обычно не следует использовать USE_LDCONFIG
.
Любые другие файлы, устанавливаемые портом с флейвором, также должны находиться в версионных каталогах или использовать версионные имена файлов. Для документации и примеров переменные GUILE_DOCS_DIR
и GUILE_EXAMPLES_DIR
указывают подходящие расположения, в которых порт должен создать подкаталог (см. ниже).
6.23.5. Переменные, определенные в фреймворке
В порте доступны эти переменные.
Имя | Пример значения | Описание |
---|---|---|
|
| Используемая версия Guile. |
|
| Короткий суффикс, используемый в некоторых именах. Используйте с осторожностью; может быть неуникальным или измениться в будущем. |
|
| Название флейвора, соответствующее выбранной версии. |
|
| Расположение порта (origin) для указанной версии Guile. |
|
| Префикс каталога для использования при установке. |
|
| Имя интерпретатора Guile с суффиксом версии. |
|
| Полный путь к интерпретатору Guile. |
|
| Название инструмента Guild, с суффиксом версии. |
|
| Полный путь к инструменту Guild. |
| Как | |
|
| Где пакеты, использующие |
|
| Подходящее значение для |
Следующие элементы определены как переменные и как записи PLIST_SUB
. Форма переменной имеет суффикс _DIR
и представляет собой полный путь (с префиксом GUILE_PREFIX
).
Имя | Пример значения | Описание |
---|---|---|
|
| Каталог сайта, общий для всех версий guile; обычно не должен использоваться. |
|
| Каталог сайта для выбранной версии Guile. |
|
| Каталог для скомпилированных файлов байт-кода. |
|
| Родительский каталог для документации, специфичной для версий. |
|
| Родительский каталог для примеров, специфичных для версий. |
6.23.6. Примеры
Makefile
для приложения, использующего GuileЭтот пример демонстрирует, как сослаться на библиотеку Guile, необходимую во время сборки и выполнения. Обратите внимание, что ссылка должна указывать флейвор. В этом примере предполагается, что приложение использует pkg-config
для поиска зависимостей.
PORTNAME= sample DISTVERSION= 1.2.3 CATEGORIES= whatever MAINTAINER= fred.bloggs@example.com COMMENT= Sample WWW= https://example.com/guile_sample/sample/ BUILD_DEPENDS= guile-lib-${GUILE_FLAVOR}>=0.2.5:devel/guile-lib@${GUILE_FLAVOR} RUN_DEPENDS= guile-lib-${GUILE_FLAVOR}>=0.2.5:devel/guile-lib@${GUILE_FLAVOR} USES= guile:2.2,3.0 pkgconfig .include <bsd.port.mk>
6.24. Использование iconv
В FreeBSD имеется встроенная реализация iconv
в самой операционной системе.
Для программного обеспечения, требующего iconv
, определите USES=iconv
.
Когда порт определяет USES=iconv
, становятся доступны следующие переменные:
Имя переменной | Назначение | Порт iconv (при использовании расширений WCHAR_T или //TRANSLIT) | Базовый iconv |
---|---|---|---|
| Каталог, в котором находится бинарный файл |
| /usr/bin/iconv |
| аргумент |
| (пусто) |
| Каталог, в котором находится реализация |
| /usr |
| Предварительно сконструированный аргумент configure для скриптов configure |
| (пусто) |
| Предварительно сконструированный аргумент configure для скриптов configure |
| (пусто) |
Эти два примера автоматически заполняют переменные правильным значением для систем, использующих converters/libiconv или iconv
, входящий в состав операционной системы, соответственно:
iconv
USES= iconv LDFLAGS+= -L${LOCALBASE}/lib ${ICONV_LIB}
iconv
с configure
USES= iconv CONFIGURE_ARGS+=${ICONV_CONFIGURE_ARG}
Как показано выше, ICONV_LIB
пуста, когда присутствует встроенный iconv
. Это можно использовать для обнаружения встроенного iconv
и действовать соответственно.
Иногда в программе аргумент ld
или путь поиска жестко заданы в Makefile или скрипте configure. Для решения этой проблемы можно использовать следующий подход:
-liconv
USES= iconv post-patch: @${REINPLACE_CMD} -e 's/-liconv/${ICONV_LIB}/' ${WRKSRC}/Makefile
В некоторых случаях необходимо установить альтернативные значения или выполнить операции в зависимости от наличия встроенного iconv
. bsd.port.pre.mk должен быть включен до проверки значения ICONV_LIB
:
iconv
USES= iconv .include <bsd.port.pre.mk> post-patch: .if empty(ICONV_LIB) # native iconv detected @${REINPLACE_CMD} -e 's|iconv||' ${WRKSRC}/Config.sh .endif .include <bsd.port.post.mk>
6.25. Использование Xfce
Порты, которым требуются библиотеки или приложения Xfce, устанавливают USES=xfce
.
Конкретные зависимости библиотек и приложений Xfce задаются с помощью значений, присвоенных USE_XFCE
. Они определены в /usr/ports/Mk/Uses/xfce.mk. Возможные значения:
USE_XFCE
- garcon
- libexo
- libgui
- libmenu
- libutil
- panel
- thunar
- xfconf
USES=xfce
USES= xfce USE_XFCE= libmenu
В этом примере портированное приложение использует пакет виджетов, специфичных для GTK2: x11/libxfce4menu и x11/xfce4-conf.
USES= xfce:gtk2 USE_XFCE= libmenu xfconf
Компоненты Xfce, включённые таким образом, автоматически загрузят все необходимые зависимости. Указывать полный список больше не требуется. Если порту нужен только x11-wm/xfce4-panel, используйте: USES= xfce USE_XFCE= panel Нет необходимости перечислять компоненты x11-wm/xfce4-panel, которые ему самому требуются, вот так: USES= xfce USE_XFCE= libexo libmenu libutil panel Однако компоненты Xfce и зависимости порта, не относящиеся к Xfce, должны быть явно включены. Не рассчитывайте, что компонент Xfce предоставит дополнительную зависимость, кроме себя, для основного порта. |
6.26. Использование Budgie
Приложения или библиотеки, зависящие от рабочего стола Budgie, должны указывать USES= budgie
и устанавливать USE_BUDGIE
в список необходимых компонентов.
Имя | Описание |
---|---|
| Ядро рабочего стола (библиотека) |
| Оконный менеджер X11 и библиотека композитинга Budgie |
| Универсальный центр в панели для доступа к различным виджетам приложений |
| Рабочий стол: специальная заставка |
Все виджеты приложений взаимодействуют через службу org.budgie_desktop.Raven. Зависимость по умолчанию включает время сборки и выполнения, её можно изменить с помощью USES= budgie USE_BUDGIE= screensaver:build |
USE_BUDGIE
USES= budgie gettext gnome meson pkgconfig USE_BUDGIE= libbudgie
6.27. Использование баз данных
Используйте один из макросов USES
из Макросы USES
для баз данных, чтобы добавить зависимость от базы данных.
База данных | Макрос USES |
---|---|
Berkeley DB | |
MariaDB, MySQL, Percona | |
PostgreSQL | |
SQLite |
USES= bdb:6
См. bdb
для получения дополнительной информации.
Когда порту требуется клиентская библиотека MySQL, добавьте
USES= mysql
См. mysql
для получения дополнительной информации.
Когда порту требуется сервер PostgreSQL версии 9.6 или новее, добавьте
USES= pgsql:9.6+ WANT_PGSQL= server
См. pgsql
для получения дополнительной информации.
USES= sqlite:3
См. sqlite
для получения дополнительной информации.
6.28. Запуск и остановка служб (скрипты rc
)
rc.d скрипты используются для запуска служб при загрузке системы, а также предоставляют администраторам стандартный способ остановки, запуска и перезапуска служб. Порты интегрируются в систему rc.d. Подробности использования можно найти в соответствующей главе Handbook. Детальное объяснение доступных команд приведено в rc(8) и rc.subr(8). Наконец, существует статья, посвящённая практическим аспектам написания rc.d скриптов.
С мифическим портом под названием doorman, которому необходимо запустить демон doormand. Добавьте следующее в Makefile:
USE_RC_SUBR= doormand
Можно указать несколько скриптов, которые будут установлены. Скрипты должны быть размещены в подкаталоге files, и к их имени должен быть добавлен суффикс .in
. Для этого файла будут выполнены стандартные подстановки SUB_LIST
. Также настоятельно рекомендуется использовать подстановки %%PREFIX%%
и %%LOCALBASE%%
. Подробнее о SUB_LIST
см. в соответствующем разделе.
Начиная с FreeBSD 6.1-RELEASE, локальные скрипты rc.d (включая те, что установлены через порты) включены в общий rcorder(8) базовой системы.
Пример простого скрипта rc.d для запуска демона doormand:
#!/bin/sh # PROVIDE: doormand # REQUIRE: LOGIN # KEYWORD: shutdown # # Add these lines to /etc/rc.conf.local or /etc/rc.conf # to enable this service: # # doormand_enable (bool): Set to NO by default. # Set it to YES to enable doormand. # doormand_config (path): Set to %%PREFIX%%/etc/doormand/doormand.cf # by default. . /etc/rc.subr name=doormand rcvar=doormand_enable load_rc_config $name : ${doormand_enable:="NO"} : ${doormand_config="%%PREFIX%%/etc/doormand/doormand.cf"} command=%%PREFIX%%/sbin/${name} pidfile=/var/run/${name}.pid command_args="-p $pidfile -f $doormand_config" run_rc_command "$1"
Если нет очень веской причины запускать службу раньше или она работает от имени определенного пользователя (не root), все скрипты портов должны использовать:
REQUIRE: LOGIN
Если скрипт запуска демона требует его остановки, следующий код активирует остановку службы при выключении системы:
KEYWORD: shutdown
Если скрипт не запускает постоянную службу, это не требуется.
Для необязательных элементов конфигурации предпочтительнее использовать стиль присваивания переменных по умолчанию "=" вместо стиля ":=", так как первый устанавливает значение по умолчанию только если переменная не задана, а второй — если переменная не задана или равна null. Пользователь может включить что-то вроде:
doormand_flags=""
в свой rc.conf.local, а подстановка переменной с использованием ":=" некорректно переопределила бы намерение пользователя. Переменная _enable
не является опциональной и должна использовать ":" для значения по умолчанию.
Порты не должны запускать и останавливать свои службы при установке и удалении. Не злоупотребляйте ключевыми словами plist, описанными в разделе @preexec command,@postexec command,@preunexec command,@postunexec command, выполняя команды, которые изменяют работающую систему, включая запуск или остановку служб. |
6.28.1. Pre-Commit Checklist
Прежде чем внести порт с rc.d скриптом, и что более важно, перед его коммитом, пожалуйста, ознакомьтесь с этим контрольным списком, чтобы убедиться, что он готов.
Порт devel/rclint может проверить большинство из них, но он не заменяет тщательного просмотра и проверки.
Если это новый файл, имеет ли он расширение .sh? Если да, его необходимо изменить на просто file.in, поскольку файлы rc.d не могут оканчиваться таким расширением.
Совпадают ли имя файла (без .in), строка
PROVIDE
и$`name? Совпадение имени файла с `PROVIDE
упрощает отладку, особенно при проблемах с rcorder(8). Совпадение имени файла и `$`name облегчает понимание того, какие переменные актуальны в rc.conf[.local]. Это также является политикой для всех новых скриптов, включая те, что в базовой системе.Установлена ли строка
REQUIRE
в значениеLOGIN
? Это обязательно для скриптов, выполняемых от имени непривилегированного пользователя. Если скрипт выполняется от имени root, есть ли веская причина для его запуска доLOGIN
? Если нет, он должен запускаться после, чтобы локальные скрипты можно было условно сгруппировать в rcorder(8) после запуска большинства компонентов базовой системы.Запускает ли скрипт постоянную службу? Если да, он должен содержать
KEYWORD: shutdown
.Убедитесь, что отсутствует
KEYWORD: FreeBSD
. Это перестало быть необходимым или желательным уже много лет. Это также указывает на то, что новый скрипт был скопирован/вставлен из старого скрипта, поэтому следует проявить дополнительную осторожность при проверке.Если скрипт использует интерпретируемый язык, например
perl
,python
илиruby
, убедитесь, чтоcommand_interpreter
установлен корректно. Например, для Perl добавьтеPERL=${PERL}
вSUB_LIST
и используйте%%PERL%%
. В противном случае,# service name stop
вероятно, не будет работать корректно. Дополнительную информацию смотрите в service(8).
Проверено, что все вхождения /usr/local заменены на
%%PREFIX%%
?Делаются ли присваивания переменным по умолчанию после
load_rc_config
?Используются ли пустые строки при присвоении значений по умолчанию? Такие присвоения должны быть удалены, но перепроверьте, что эти параметры задокументированы в комментариях в начале файла.
Действительно ли в сценариях используются значения, присвоенные переменным?
Являются ли опции, перечисленные в стандартном name`_flags`, обязательными? Если да, они должны быть в
command_args
. Флаг-d
здесь, как красный флаг (простите за каламбур), так как обычно это опция для "демонизации" процесса и, следовательно, фактически обязательна._name__flags
никогда не должны включаться вcommand_args
(и наоборот, хотя такая ошибка встречается реже).Выполняет ли скрипт любой код безусловно? Это не приветствуется. Обычно такие вещи должны обрабатываться через
start_precmd
.Все логические проверки должны использовать функцию
checkyesno
. Не допускаются самодельные проверки на[Yy][Ee][Ss]
и т.п.Если есть цикл (например, ожидание запуска чего-либо), есть ли в нём счётчик для завершения цикла? Мы не хотим, чтобы загрузка зависала навсегда в случае ошибки.
Создает ли скрипт файлы или каталоги, требующие определенных разрешений, например, pid, который должен принадлежать пользователю, запускающему процесс? Вместо традиционной последовательности touch(1)/chown(8)/chmod(1) рассмотрите использование install(1) с соответствующими аргументами командной строки, чтобы выполнить всю процедуру за один шаг.
6.29. Добавление пользователей и групп
Некоторые порты требуют наличия определённой учётной записи пользователя, обычно для демонов, работающих от имени этого пользователя. Для таких портов выберите уникальный UID в диапазоне от 50 до 999 и зарегистрируйте его в ports/UIDs (для пользователей) и ports/GIDs (для групп). Уникальный идентификатор должен быть одинаковым для пользователей и групп.
Пожалуйста, приложите патч для этих двух файлов, если требуется создать нового пользователя или группу для порта.
Затем используйте USERS
и GROUPS
в Makefile, и пользователь будет автоматически создан при установке порта.
USERS= pulse GROUPS= pulse pulse-access pulse-rt
Текущий список зарезервированных UID и GID можно найти в ports/UIDs и ports/GIDs.
6.30. Порты, зависящие от исходных кодов ядра
Некоторые порты (например, загружаемые модули ядра) требуют исходные файлы ядра для компиляции порта. Вот правильный способ проверить, установлены ли они у пользователя:
USES= kmod
Помимо этой проверки, функция kmod
учитывает большинство аспектов, которые необходимо принимать во внимание данным портам.
6.31. Библиотеки Go
Порты не должны упаковывать или устанавливать библиотеки или исходный код Go. Порты Go должны загружать необходимые зависимости в обычное время загрузки и должны устанавливать только программы и то, что нужно пользователям, а не то, что нужно разработчикам на Go.
Порты должны (в порядке предпочтения):
Использовать зависимости, включенные в исходный код пакета.
Получить версии зависимостей, указанные вышестоящим проектом (в случае go.mod, vendor.json или аналогичных).
В крайнем случае (зависимости не включены и версии не указаны точно) получить версии зависимостей, доступные на момент разработки/выпуска вышестоящего проекта.
6.32. Библиотеки Haskell
Как и в случае с языком Go, коллекция портов не должна включать или устанавливать библиотеки Haskell. Порты Haskell должны статически линковаться со своими зависимостями и загружать все распространяемые файлы на этапе fetch.
6.33. Файлы завершения командной оболочки
Многие современные оболочки (включая bash, fish, tcsh и zsh) поддерживают табуляцию для параметров и/или опций. Эта поддержка обычно обеспечивается файлами завершения, которые содержат определения того, как будет работать завершение по табуляции для определённой команды. Порты иногда поставляются со своими собственными файлами завершения, или разработчики портов могут создавать их самостоятельно.
Если доступны файлы завершения, их всегда следует устанавливать. Нет необходимости создавать для этого опцию. Однако если опция используется, всегда включайте её в OPTIONS_DEFAULT
.
| ${PREFIX}/etc/bash_completion.d or ${PREFIX}/share/bash-completion/completions | (любые уникальные имена файлов в одной из этих папок) |
| ${PREFIX}/share/fish/completions/${PORTNAME}.fish | |
| ${PREFIX}/share/zsh/site-functions/_${PORTNAME} |
Не регистрируйте зависимости от самих оболочек.
Изменено: 18 сентября 2025 г. by Vladlen Popolitov