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/foo6.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}/subprojectCMAKE_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_XORGUSES= 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;" \
falseDESKTOP_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, входящий в состав операционной системы, соответственно:
iconvUSES= iconv
LDFLAGS+= -L${LOCALBASE}/lib ${ICONV_LIB}iconv с configureUSES= iconv
CONFIGURE_ARGS+=${ICONV_CONFIGURE_ARG}Как показано выше, ICONV_LIB пуста, когда присутствует встроенный iconv. Это можно использовать для обнаружения встроенного iconv и действовать соответственно.
Иногда в программе аргумент ld или путь поиска жестко заданы в Makefile или скрипте configure. Для решения этой проблемы можно использовать следующий подход:
-liconvUSES= iconv
post-patch:
@${REINPLACE_CMD} -e 's/-liconv/${ICONV_LIB}/' ${WRKSRC}/MakefileВ некоторых случаях необходимо установить альтернативные значения или выполнить операции в зависимости от наличия встроенного iconv. bsd.port.pre.mk должен быть включен до проверки значения ICONV_LIB:
iconvUSES= 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=xfceUSES= 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_BUDGIEUSES= 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