diff options
Diffstat (limited to 'documentation/content/ru/books/porters-handbook/special/_index.adoc')
| -rw-r--r-- | documentation/content/ru/books/porters-handbook/special/_index.adoc | 4192 |
1 files changed, 3184 insertions, 1008 deletions
diff --git a/documentation/content/ru/books/porters-handbook/special/_index.adoc b/documentation/content/ru/books/porters-handbook/special/_index.adoc index 9bfdfcc275..14f3d94db3 100644 --- a/documentation/content/ru/books/porters-handbook/special/_index.adoc +++ b/documentation/content/ru/books/porters-handbook/special/_index.adoc @@ -1,11 +1,13 @@ --- -title: Глава 6. Особые соглашения +description: 'Особые соображения при создании нового порта FreeBSD' +next: books/porters-handbook/flavors +params: + path: /books/porters-handbook/special/ prev: books/porters-handbook/makefiles -next: books/porters-handbook/plist showBookMenu: true +tags: ["special considerations", "Handling Symbolic Links", "Bundled Libraries"] +title: 'Глава 6. Особые соглашения' weight: 6 -params: - path: "/books/porters-handbook/special/" --- [[special]] @@ -48,17 +50,31 @@ endif::[] Имеется ещё несколько вещей, которые вы должны иметь в виду при создании порта. Этот раздел описывает наиболее часто встречающиеся из них. +[[splitting-long-files]] +== Разделение длинных файлов + +Иногда [.filename]#Makefiles# могут быть очень длинными. Например, порты rust могут содержать очень длинный список `CARGO_CRATES`. В других случаях [.filename]#Makefile# может содержать код, который варьируется в зависимости от архитектуры. В таких ситуациях может быть удобно разделить исходный [.filename]#Makefile# на несколько файлов. [.filename]#bsd.port.mk# автоматически включает некоторые типы [.filename]#Makefiles# в основной [.filename]#Makefile# порта. + +Вот файлы, которые система обрабатывает автоматически, если они обнаружены: + +* [.filename]#Makefile.crates#. Пример можно найти в пакете package:audio/ebur128[]. +* [.filename]#Makefile.inc#. Пример можно найти в пакете package:net/ntp[]. +* [.filename]#Makefile.${ARCH}-${OPSYS}# +* [.filename]#Makefile.${OPSYS}#. Пример можно найти в пакете package:net/cvsup-static[]. +* [.filename]#Makefile.${ARCH}# +* [.filename]#Makefile.local# + +Также распространённой практикой является разделение списка пакетов порта на несколько файлов, если список сильно различается в зависимости от архитектуры или выбранного флейвора. В этом случае файл [.filename]#pkg-plist# для каждой архитектуры именуется по шаблону [.filename]#pkg-plist.${ARCH}# или [.filename]#pkg-plist.${FLAVOR}#. Фреймворк не создаёт список пакетов автоматически, если существует несколько файлов [.filename]#pkg-plist#. Ответственность за выбор подходящего файла [.filename]#pkg-plist# и его присвоение переменной `PLIST` лежит на того, кто делает порт. Примеры работы с этим можно найти в портах package:audio/logitechmediaserver[] и package:deskutils/libportal[]. + [[staging]] == Staging -[.filename]#bsd.port.mk# ожидает от портов работу с "каталогом сборки". Это означает, что порт должен устанавливать файлы не напрямую в назначенные каталоги (то есть, например, под `PREFIX`), а в отдельный каталог, из которого затем собирается пакет. Во многих случаях привилегии root для этого не требуются, что делает возможным сборку пакетов из-под непривилегированного пользователя. В режиме staging порт собирается и устанавливается в каталог сборки `STAGEDIR`. Пакет создается из каталога сборки и затем устанавливается в систему. В инструментарии automake такая концепция именуется `DESTDIR`; в прочем, в FreeBSD `DESTDIR` имеет собственное значение (смотрите crossref:testing[porting-prefix, `PREFIX` и `DESTDIR`]). - -Если для порта всё ещё требуются системные привилегии при выполнении цели `package`, то в [.filename]#Makefile# должна быть добавлена следующая строка: +[.filename]#bsd.port.mk# ожидает, что порты будут работать с "директорией стадии". Это означает, что порт не должен устанавливать файлы напрямую в обычные целевые директории (например, под `PREFIX`), а вместо этого в отдельную директорию, из которой затем собирается пакет. Во многих случаях это не требует прав root, что позволяет собирать пакеты от имени непривилегированного пользователя. При использовании стадии порт собирается и устанавливается в директорию стадии `STAGEDIR`. Пакет создаётся из директории стадии и затем устанавливается в систему. Инструменты Automake называют эту концепцию `DESTDIR`, но в FreeBSD `DESTDIR` имеет другое значение (см. crossref:testing[porting-prefix,`PREFIX` и `DESTDIR`]). -[.programlisting] -.... -NEED_ROOT= yes -.... +[NOTE] +==== +Ни один порт _на самом деле_ не должен работать от root. Этого в большинстве случаев можно избежать, используя crossref:uses[uses-uidfix,`USES=uidfix`]. Если порт всё ещё выполняет команды, такие как man:chown[8], man:chgrp[1], или принудительно устанавливает владельца или группу с помощью man:install[1], то используйте crossref:uses[uses-fakeroot,`USES=fakeroot`], чтобы подделать эти вызовы. Потребуется некоторая правка [.filename]#Makefiles# порта. +==== Метапорты, то есть порты, которые не устанавливают файлы непосредственно, а только зависят от других портов, должны по возможности избегать распаковки man:mtree[8] в каталог сборки. Это основная иерархия каталогов пакета, и эти пустые каталоги будут выглядеть лишними. Для предотвращения распаковки man:mtree[8] добавьте эту строку: @@ -67,18 +83,97 @@ NEED_ROOT= yes NO_MTREE= yes .... -Staging задействуется посредством добавления переменной `STAGEDIR` слева от путей, которые используются в целях `pre-install`, `do-install` и `post-install` (смотрите примеры в книге). Обычно сюда относятся `PREFIX`, `ETCDIR`, `DATADIR`, `EXAMPLESDIR`, `MANPREFIX`, `DOCSDIR` и так далее. Каталоги должны создаваться при выполнении цели `post-install`. Избегайте использования абсолютных путей, когда это возможно. +[TIP] +==== +Метапорты должны использовать crossref:special[uses-metaport,`USES=metaport`]. Это устанавливает значения по умолчанию для портов, которые не загружают, не собирают и не устанавливают ничего. +==== + +Этап подготовки включается путем добавления `STAGEDIR` к путям, используемым в целях `pre-install`, `do-install` и `post-install` (см. примеры в книге). Обычно это включает `PREFIX`, `ETCDIR`, `DATADIR`, `EXAMPLESDIR`, `DOCSDIR` и т. д. Каталоги должны создаваться как часть цели `post-install`. По возможности избегайте использования абсолютных путей. + +[TIP] +==== +Порты, которые устанавливают модули ядра, должны добавлять `STAGEDIR` к пути назначения, по умолчанию это [.filename]#/boot/modules#. +==== -При создании символический ссылки `STAGEDIR` должен ставиться только для пути назначения. Например: +[[staging-symlink]] +=== Обработка символических ссылок + +При создании символической ссылки настоятельно рекомендуется использовать относительные пути. Используйте `${RLN}` для создания относительных символических ссылок. Эта команда использует man:install[1] для автоматического определения относительной ссылки, которую нужно создать. + +[[staging-ex1]] +.Автоматическое создание относительных символических ссылок +[example] +==== +`${RLN}` использует относительную символическую ссылку из man:install[1], что освобождает сборщика порта от вычисления относительного пути. [.programlisting] .... -${LN} -sf libfoo.so.42 ${STAGEDIR}${PREFIX}/lib/libfoo.so +${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 +.... + +Будет создано: + +[source, shell] +.... +% ls -lF ${STAGEDIR}${PREFIX}/lib +lrwxr-xr-x 1 nobody nobody 181 Aug 3 11:27 libfoo.so@ -> libfoo.so.42 +-rwxr-xr-x 1 nobody nobody 15 Aug 3 11:24 libfoo.so.42* +% ls -lF ${STAGEDIR}${PREFIX}/bin +lrwxr-xr-x 1 nobody nobody 181 Aug 3 11:27 bar@ -> ../libexec/foo/bar +% ls -lF ${STAGEDIRDIR}${PREFIX}/share +lrwxr-xr-x 1 nobody nobody 181 Aug 3 11:27 foo@ -> ../../../var/cache/foo .... -Первоначальный путь [.filename]#${PREFIX}/lib/libfoo.so.42# выглядит нормально, но по факту может быть неправильным. Абсолютные пути могут указывать на неподходящее место, например, когда удалённая файловая система смонтирована по NFS как непривилегированная точка монтирования. Относительные пути реже подвержены проблемам и часто намного короче. +==== + +[[bundled-libs]] +== Встроенные библиотеки + +Этот раздел объясняет, почему встроенные зависимости считаются плохими и что с этим делать. + +[[bundled-libs-why-bad]] +=== Почему встроенные библиотеки — это плохо + +Некоторое программное обеспечение требует от упаковщика найти сторонние библиотеки и добавить необходимые зависимости в порт. Другое ПО включает все необходимые библиотеки в дистрибутивный файл. Второй подход кажется проще на первый взгляд, но имеет серьёзные недостатки: + +Этот список частично основан на вики https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries[Fedora] и https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies[Gentoo], оба распространяются по лицензии https://creativecommons.org/licenses/by-sa/3.0/[CC-BY-SA 3.0]. + +Безопасность:: +Если уязвимости обнаружены в вышестоящей библиотеке и исправлены там, они могут остаться неисправленными в библиотеке, поставляемой с портом. Одной из причин может быть то, что автор не знает о проблеме. Это означает, что портировщик должен исправить их или обновить до не уязвимой версии и отправить исправление автору. Всё это требует времени, что приводит к тому, что программное обеспечение остаётся уязвимым дольше, чем необходимо. Это, в свою очередь, затрудняет координацию исправления без неоправданного раскрытия информации об уязвимости. + +Ошибки:: +Эта проблема аналогична проблеме с безопасностью в последнем абзаце, но в целом менее серьезная. + +Ветвление:: +Автору проще создать форк upstream-библиотеки после её включения в дистрибутив. Хотя на первый взгляд это кажется удобным, такой подход приводит к расхождению кода с исходным репозиторием, что усложняет исправление уязвимостей и других проблем в ПО. Одна из причин — затруднённое применение патчей. ++ +Еще одна проблема форкинга заключается в том, что из-за расхождения кода с основной веткой, ошибки исправляются снова и снова, вместо того чтобы быть исправленными один раз в центральном месте. Это противоречит самой идее открытого программного обеспечения. + +Конфликты символов:: +Когда библиотека установлена в системе, может возникнуть конфликт с встроенной в порт версией. Это может привести к немедленным ошибкам во время компиляции или компоновки. Также могут возникать ошибки при запуске программы, которые сложнее отследить. Последняя проблема может быть вызвана несовместимостью версий двух библиотек. -Порты, устанавливающие модули ядра, должны предварять путь установки (по умолчанию [.filename]#/boot/modules#) переменной `STAGEDIR`. +Лицензирование:: +При объединении проектов из различных источников могут возникать проблемы с лицензиями, особенно если лицензии несовместимы. + +Растрата ресурсов:: +Библиотеки, поставляемые в комплекте, растрачивают ресурсы на нескольких уровнях. Сборка самого приложения занимает больше времени, особенно если эти библиотеки уже присутствуют в системе. Во время выполнения они могут занимать дополнительную память, когда общесистемная библиотека уже загружена одной программой, а входящая в комплект библиотека загружена другой программой. + +Пустая трата усилий:: +Когда библиотеке требуются патчи для FreeBSD, эти патчи приходится дублировать в составе библиотеки. Это приводит к потере времени разработчиков, поскольку патчи могут применяться некорректно. Кроме того, бывает сложно сразу заметить, что эти патчи вообще необходимы. + +[[bundled-libs-practices]] +=== Что делать со встроенными библиотеками + +По возможности используйте независимую версию библиотеки, добавив `LIB_DEPENDS` в порт. Если такого порта ещё не существует, рассмотрите возможность его создания. + +Используйте встроенные библиотеки только в том случае, если разработчик имеет хорошую репутацию в вопросах безопасности, а использование внешних версий приводит к излишне сложным исправлениям. + +[NOTE] +==== +В некоторых особых случаях, например, для эмуляторов, таких как Wine, порт должен включать библиотеки, потому что они предназначены для другой архитектуры или были изменены для использования в данном программном обеспечении. В таком случае эти библиотеки не должны быть доступны для связывания с другими портами. Добавьте `BUNDLE_LIBS=yes` в [.filename]#Makefile# порта. Это укажет man:pkg[8] не учитывать предоставляемые библиотеки. Всегда спрашивайте {portmgr}, прежде чем добавлять это в порт. +==== [[porting-shlibs]] == Динамические библиотеки @@ -101,7 +196,7 @@ USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar При установке 32-разрядных библиотек на 64-разрядной системе используйте вместо этого `USE_LDCONFIG32`. -Постарайтесь сохранять номера версий динамических библиотек в формате [.filename]#libfoo.so.0#. Наш компоновщик позаботится только о старшем (первом) номере. +Если программное обеспечение использует crossref:special[using-autotools,autotools], в частности `libtool`, добавьте crossref:uses[uses-libtool,`USES=libtool`]. Если при обновлении порта увеличивается старший номер версии библиотеки, то для всех портов, компонуемых с затронутой библиотекой, следует увеличить значение `PORTREVISION` для форсирования перекомпиляции с новой версией библиотеки. @@ -117,6 +212,7 @@ USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar В подобных ситуациях можно использовать переменные, описываемые в последующих разделах. +[[porting-restrictions-no_package]] === `NO_PACKAGE` Эта переменная указывает, что мы не можем создавать для приложения двоичный пакет. К примеру, лицензия не позволяет бинарное распространение или она может запрещать распространение пакетов, созданных из изменённых исходников. @@ -127,6 +223,7 @@ USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar Значением переменной `NO_PACKAGE` должна быть строка, описывающая причину, по которой пакет не должен создаваться. +[[porting-restrictions-no_cdrom]] === `NO_CDROM` Эта переменная указывает на то, что, хотя мы имеем право создавать бинарные пакеты, мы не можем помещать эти пакеты или файлы `DISTFILES` порта на CD-ROM (или на похожие носители) для перепродажи. Однако бинарные пакеты и файлы `DISTFILES` порта будут оставаться доступными посредством FTP/HTTP. @@ -135,12 +232,14 @@ USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar В качестве значения `NO_CDROM` должна указываться строка, описывающая причины, по которым порт не может распространяться на CD-ROM. К примеру, это применяется, если лицензионное соглашение приложения предполагает только его "некоммерческое" использование. +[[porting-restrictions-nofetchfiles]] === `NOFETCHFILES` Файлы, определенные в переменной `NOFETCHFILES`, не будут извлекаться ни из одного из `MASTER_SITES`. Примером такого файла является файл, поставляемый на CD-ROM. Инструменты, проверяющие доступность этих файлов на `MASTER_SITES`, должны игнорировать эти файлы и не сообщать о них. +[[porting-restrictions-restricted]] === `RESTRICTED` Задайте эту переменную, если лицензия на приложение не позволяет ни зеркалировать файлы `DISTFILES`, ни распространять бинарный пакет через FTP/HTTP или на CD-ROM. @@ -149,19 +248,23 @@ USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar В качестве значения `RESTRICTED` должна указываться строка, описывающая причины, по которым порт нельзя распространять. Обычно это означает, что порт использует закрытое программное обеспечение, а пользователь должен вручную сгрузить файлы `DISTFILES`, возможно, после заполнения регистрационной формы или подтверждения соглашения с условиями EULA. +[[porting-restrictions-restricted_files]] === `RESTRICTED_FILES` Если заданы `RESTRICTED` или `NO_CDROM`, то значение этой переменной по умолчанию соответствует `${DISTFILES} ${PATCHFILES}`, в противном случае она пуста. Если ограничены в распространении лишь некоторые из дистрибутивных файлов, то в этой переменной задаётся их список. +[[porting-restrictions-legal_text]] === `LEGAL_TEXT` Если порт имеет правовое обременение, которое не покрывается перечисленными выше переменными, то переменной `LEGAL_TEXT` следует присвоить строку с описанием данного обременения. Например, если было получено особое разрешение для FreeBSD на распространение двоичного файла, то эта переменная должна содержать соответствующее указание. +[[porting-restrictions-legal]] === [.filename]#/usr/ports/LEGAL# и `LEGAL` Порт, содержащий любую из перечисленных выше переменных, также должен быть добавлен в [.filename]#/usr/ports/LEGAL#. Первый столбец содержит шаблон совпадения с дистрибутивными файлами, имеющими ограничения на распространение. Второй столбец содержит корень порта. Третий столбец содержит вывод `make -VLEGAL`. -=== Примеры использования +[[porting-restrictions-examples]] +=== Примеры Предпочтительным способом реализации утверждения "архивы исходных текстов для этого порта должны загружаться самостоятельно" является следующее: @@ -186,23 +289,19 @@ IGNORE= may not be redistributed because of licensing reasons. Please visit some Это достигается путём передачи флага `-jX` команде man:make[1]. Такое построение портов является поведением по умолчанию. К сожалению, не все порты поддерживают параллельную сборку достаточно хорошо, и поэтому может потребоваться выключить этот механизм явным образом путём добавления переменной `MAKE_JOBS_UNSAFE=yes`. Эта переменная используется в случае, когда известно, что порт ломается с `-jX`. +[IMPORTANT] +==== +При установке `MAKE_JOBS_UNSAFE` очень важно объяснить либо комментарием в [.filename]#Makefile#, либо хотя бы в сообщении коммита, _почему_ порт не собирается при включении. В противном случае практически невозможно ни исправить проблему, ни проверить, была ли она исправлена при коммите обновления в дальнейшем. +==== + [[using-make]] === `make`, `gmake` и `imake` -Если ваш порт использует GNU make, то установите `USES= gmake`. - -.Переменные для портов, использующих gmake -[cols="1,1", frame="none", options="header"] -|=== -| Переменная -| Значение +Существует несколько различных реализаций `make`. Переносимому программному обеспечению часто требуется конкретная реализация, например GNU `make`, известная в FreeBSD как `gmake`. -|`USES= gmake` -|Для сборки порта требуется `gmake`. +Если порт использует GNU make, добавьте `gmake` в `USES`. -|`GMAKE` -|Полный путь к команде `gmake`, если отсутствует в `PATH`. -|=== +`MAKE_CMD` может использоваться для ссылки на конкретную команду, настроенную параметром `USES` в [.filename]#Makefile# порта. Используйте `MAKE_CMD` только внутри [.filename]##Makefile## приложения в `WRKSRC` для вызова реализации `make`, ожидаемой портируемым программным обеспечением. Если ваш порт является приложением X, которое создает файлы [.filename]#Makefile# из [.filename]#Imakefile#, используя imake, то установите `USES= imake`. Это заставит стадию конфигурирования автоматически выполнить `xmkmf -a`. Если флаг `-a` представляет для вашего порта проблему, то установите `XMKMF=xmkmf`. Если порт использует imake, но не понимает цель `install.man`, то следует установить `NO_INSTALL_MANPAGES=yes`. @@ -213,6 +312,7 @@ IGNORE= may not be redistributed because of licensing reasons. Please visit some Если ваш порт использует сценарий `configure` для получения файлов [.filename]#Makefile# из файлов [.filename]#Makefile.in#, то установите `GNU_CONFIGURE=yes`. Если вы хотите дать дополнительные параметры сценарию `configure` (аргументом по умолчанию является `--prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH} --mandir=${MANPREFIX}/man --build=${CONFIGURE_TARGET}`), установите эти параметры в `CONFIGURE_ARGS`. Дополнительные переменные окружения можно передать, используя переменную `CONFIGURE_ENV`. +[[using-configure-variables]] .Переменные для портов, использующих `configure` [cols="1,1", frame="none", options="header"] |=== @@ -238,8 +338,9 @@ IGNORE= may not be redistributed because of licensing reasons. Please visit some [[using-cmake]] === Использование `cmake` -Если порт использует CMake, определите `USES= cmake` или `USES= cmake:outsource` для построения во внешнем каталоге (см. ниже). +Если порт использует CMake, определите `USES= cmake`. +[[using-cmake-variables]] .Переменные для портов, использующих `cmake` [cols="1,1", frame="none", options="header"] |=== @@ -247,27 +348,33 @@ IGNORE= may not be redistributed because of licensing reasons. Please visit some | Значение |`CMAKE_ARGS` -|Специфичные для порта флаги CMake, передаваемые `cmake`. +|Специфичные для порта флаги CMake, передаваемые в бинарный файл `cmake`. -|`CMAKE_BUILD_TYPE` -|Тип построения (предопределённые профили построения CMake). По умолчанию `Release`, `Debug` при использовании `WITH_DEBUG`. +|`CMAKE_ON` +|Для каждой записи в `CMAKE_ON` добавляется булево значение "включено" в +`CMAKE_ARGS`. См. crossref:special[using-cmake-example2,`CMAKE_ON` и `CMAKE_OFF`]. -|`CMAKE_ENV` -|Переменные окружения для передачи `cmake`. По умолчанию `${CONFIGURE_ENV}`. +|`CMAKE_OFF` +|Для каждой записи в `CMAKE_OFF` в `CMAKE_ARGS` добавляется отключенное булево +значение. См. crossref:special[using-cmake-example2,`CMAKE_ON` и `CMAKE_OFF`]. + +|`CMAKE_BUILD_TYPE` +|Тип сборки (предопределённые профили сборки CMake). По умолчанию `Release`, или `Debug`, если установлен `WITH_DEBUG`. |`CMAKE_SOURCE_PATH` -|Путь к каталогу с исходным кодом. По умолчанию `${WRKSRC}`. +|Путь к исходному каталогу. По умолчанию `${WRKSRC}`. + +|`CONFIGURE_ENV` +|Дополнительные переменные окружения, которые должны быть установлены для бинарного файла `cmake`. |=== -.Переменные построения `cmake`, устанавливаемые пользователем +[[using-cmake-user-variables]] +.Переменные, которые пользователи могут определить для сборок `cmake` [cols="1,1", frame="none", options="header"] |=== | Переменная | Значение -|`CMAKE_VERBOSE` -|Разрешает подробный вывод сообщений при построении. Значение по умолчанию не задано, если не заданы `BATCH` или `PACKAGE_BUILDING`. - |`CMAKE_NOCOLOR` |Запрещает цветной вывод сообщений при построении. Значение по умолчанию не задано, если не заданы `BATCH` или `PACKAGE_BUILDING`. |=== @@ -284,179 +391,765 @@ CMake поддерживает следующие профили построе [.programlisting] .... -USES= cmake:outsource +USES= cmake CMAKE_SOURCE_PATH= ${WRKSRC}/subproject .... ==== +[[using-cmake-example2]] +.`CMAKE_ON` и `CMAKE_OFF` +[example] +==== +При добавлении логических значений в `CMAKE_ARGS` проще использовать переменные `CMAKE_ON` и `CMAKE_OFF` вместо этого. Это: + +[.programlisting] +.... +CMAKE_ON= VAR1 VAR2 +CMAKE_OFF= VAR3 +.... + +Эквивалентно: + +[.programlisting] +.... +CMAKE_ARGS= -DVAR1:BOOL=TRUE -DVAR2:BOOL=TRUE -DVAR3:BOOL=FALSE +.... + +[IMPORTANT] +====== +Это относится только к значениям по умолчанию в `CMAKE_ARGS`. Вспомогательные функции, описанные в crossref:makefiles[options-cmake_bool,`OPT_CMAKE_BOOL` и `OPT_CMAKE_BOOL_OFF`], используют ту же семантику, но для опциональных значений. +====== + +==== + [[using-scons]] === Использование `scons` -Если ваш порт использует SCons, определите `USE_SCONS=yes`. +Если порт использует SCons, определите `USES=scons`. -.Переменные для портов, использующих `scons` -[cols="1,1", frame="none", options="header"] +Чтобы сторонний [.filename]#SConstruct# учитывал все, что передается в SCons через окружение (то есть, что наиболее важно, `CC/CXX/CFLAGS/CXXFLAGS`), исправьте [.filename]#SConstruct#, чтобы сборка `Environment` создавалась следующим образом: + +[.programlisting] +.... +env = Environment(**ARGUMENTS) +.... + +Он может быть изменён с помощью `env.Append` и `env.Replace`. + +[[using-cargo]] +=== Сборка приложений на Rust с помощью `cargo` + +Для портов, использующих Cargo, определите `USES=cargo`. + +[[using-cargo-user-variables]] +.Переменные, которые пользователи могут определить для сборок `cargo` +[cols="1,1,1", frame="none", options="header"] |=== | Переменная -| Значение +| По умолчанию +| Описание + +|`CARGO_CRATES` +| +|Список ящиков (crates), от которых зависит порт. Каждая запись должна быть в формате `имя_ящика-семвер`, например, `libc-0.2.40`. Поддерживающие порт могут сгенерировать этот список из файла [.filename]#Cargo.lock# с помощью команды `make cargo-crates`. Вручную обновлять версии ящиков возможно, но следует учитывать транзитивные зависимости. +Если список, сгенерированный `make cargo-crates`, слишком велик, его можно разместить в файле `Makefile.crates` в корневом каталоге порта. +Если такой файл присутствует, фреймворк портов автоматически загружает его. +Это помогает сохранять основной Makefile порта в удобном для работы размере. + +|`CARGO_FEATURES` +| +|Список функций приложения для сборки (список через пробел). Чтобы отключить все функции по умолчанию, добавьте специальный токен `--no-default-features` в `CARGO_FEATURES`. Вручную передавать его в `CARGO_BUILD_ARGS`, `CARGO_INSTALL_ARGS` и `CARGO_TEST_ARGS` не требуется. + +|`CARGO_CARGOTOML` +|`${WRKSRC}/Cargo.toml` +|Путь к файлу [.filename]#Cargo.toml#, который следует использовать. + +|`CARGO_CARGOLOCK` +|`${WRKSRC}/Cargo.lock` +|Путь к файлу [.filename]#Cargo.lock#, используемому для `make cargo-crates`. Можно указать более одного файла блокировки, если это необходимо. + +|`CARGO_ENV` +| +|Список переменных окружения, передаваемых в Cargo, аналогично `MAKE_ENV`. -|`SCONS_ARGS` -|Специфичные для порта флаги SCons, передаваемые окружению SCons. +|`RUSTFLAGS` +| +|Флаги для передачи компилятору Rust. -|`SCONS_BUILDENV` -|Переменные для установки в системном окружении. +|`CARGO_CONFIGURE` +|`yes` +|Используйте стандартный `do-configure`. -|`SCONS_ENV` -|Переменные для установки в окружении SCons. +|`CARGO_UPDATE_ARGS` +| +|Дополнительные аргументы для передачи Cargo во время фазы настройки. Допустимые аргументы можно посмотреть с помощью `cargo update --help`. -|`SCONS_TARGET` -|Последний параметр для передачи SCons, похожий на `MAKE_TARGET`. +|`CARGO_BUILDDEP` +|`yes` +|Добавить зависимость сборки на package:lang/rust[]. + +|`CARGO_CARGO_BIN` +|`${LOCALBASE}/bin/cargo` +|Расположение бинарного файла `cargo`. + +|`CARGO_BUILD` +|`yes` +|Используйте значение по умолчанию `do-build`. + +|`CARGO_BUILD_ARGS` +| +|Дополнительные аргументы для передачи Cargo во время фазы сборки. Допустимые аргументы можно посмотреть с помощью `cargo build --help`. + +|`CARGO_INSTALL` +|`yes` +|Используйте настройку `do-install` по умолчанию. + +|`CARGO_INSTALL_ARGS` +| +|Дополнительные аргументы для передачи Cargo во время фазы установки. Допустимые аргументы можно посмотреть с помощью `cargo install --help`. + +|`CARGO_INSTALL_PATH` +|`.` +|Путь к пакету для установки. Этот аргумент передается в `cargo install` через параметр `--path`. Если указано несколько путей, `cargo install` запускается несколько раз. + +|`CARGO_TEST` +|`yes` +|Используйте значение по умолчанию `do-test`. + +|`CARGO_TEST_ARGS` +| +|Дополнительные аргументы для передачи Cargo во время тестовой фазы. Допустимые аргументы можно посмотреть с помощью `cargo test --help`. + +|`CARGO_TARGET_DIR` +|`${WRKDIR}/target` +|Расположение выходного каталога cargo. + +|`CARGO_DIST_SUBDIR` +|[.filename]#rust/crates# +|Каталог относительно `DISTDIR`, в котором будут храниться файлы дистрибутивов пакетов (crates). + +|`CARGO_VENDOR_DIR` +|`${WRKSRC}/cargo-crates` +|Расположение каталога сторонних поставщиков ПО, в который будут извлечены все крейты. Старайтесь держать его в пределах `PATCH_WRKSRC`, чтобы упростить применение патчей. + +|`CARGO_USE_GITHUB` +|`no` +|Включить загрузку крейтов, привязанных к определённым коммитам Git на GitHub, с помощью `GH_TUPLE`. Это попытается исправить все файлы [.filename]#Cargo.toml# в `WRKDIR`, чтобы они ссылались на автономные источники вместо загрузки из репозитория Git во время сборки. + +|`CARGO_USE_GITLAB` +|`no` +|То же, что и `CARGO_USE_GITHUB`, но для экземпляров GitLab и `GL_TUPLE`. |=== -Для того, чтобы сторонний [.filename]#SConstruct# соответствовал всему, что передается SCons в переменной `SCONS_ENV` (самое главное, это `CC/CXX/CFLAGS/CXXFLAGS`), примените патч к [.filename]#SConstruct#, так чтобы переменная построения `Environment` выглядела следующим образом: +[[cargo-ex1]] +.Создание порта для простого приложения на Rust +[example] +==== +Создание порта на основе Cargo — это процесс из трёх этапов. Сначала необходимо предоставить шаблон портов, который загружает дистрибутивный файл приложения: [.programlisting] .... -env = Environment(**ARGUMENTS) +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> .... -В дальнейшем ее можно изменить при помощи `env.Append` и `env.Replace`. +Сгенерировать первоначальный [.filename]#distinfo#: -[[using-autotools]] -== Использование GNU Autotools +[source, shell] +.... +% 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 +.... -[[using-autotools-introduction]] -=== Введение +Теперь файл дистрибутива готов к использованию, и мы можем продолжить, извлекая зависимости пакета из встроенного файла [.filename]#Cargo.lock#: -Различные инструменты GNU autotools предоставляют механизм абстракции для построения частей программного обеспечения на широком наборе операционных систем и аппаратных архитектур. Внутри Коллекции Портов отдельный порт может использовать эти инструменты при помощи простых конструкций: +[source, shell] +.... +% 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: [.programlisting] .... -USE_AUTOTOOLS= tool:version[:operation] ... +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> +.... + +[.filename]#distinfo# необходимо перегенерировать, чтобы включить все дистрибутивные файлы крейтов: + +[source, shell] +.... +% 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/. +[...] .... -К моменту написания _tool_ может быть одним из `libtool`, `libltdl`, `autoconf`, `autoheader`, `automake` или `aclocal`. +Порт теперь готов к тестовой сборке и дальнейшим настройкам, таким как создание plist, написание описания, добавление информации о лицензии, опций и т.д., как обычно. + +Если вы не тестируете свой порт в чистой среде, например, с использованием poudriere, не забудьте выполнить `make clean` перед любым тестированием. +==== + +[[cargo-ex2]] +.Включение дополнительных возможностей приложений +[example] +==== +Некоторые приложения определяют дополнительные возможности в своем [.filename]#Cargo.toml#. Их можно включить при компиляции, установив `CARGO_FEATURES` в порте. -_version_ указывает конкретную версию используемого инструмента (смотрите `devel/{automake,autoconf,libtool}[0-9]+` для получения действительных версий). +Здесь мы включаем функции `json` и `yaml` в Tokei: -_operation_ является необязательным расширением и указывает на способ использования инструмента. +[.programlisting] +.... +CARGO_FEATURES= json yaml +.... -Одновременно может быть указано несколько инструментов, добавляя их все на одной строке или используя конструкцию Makefile `+=`. +==== -В заключение, существует специальный инструмент по называнию `autotools`, который является удобной функцией при установке всех доступных версий autotools для возможности проведения кросс-разработки. Это также может быть достигнуто путем установки порта `devel/autotools`. +[[cargo-ex4]] +.Кодирование характеристик приложений как параметров порта +[example] +==== +Пример раздела `[features]` в [.filename]#Cargo.toml# может выглядеть так: -[[using-libtool]] -=== `libtool` +[.programlisting] +.... +[features] +pulseaudio_backend = ["librespot-playback/pulseaudio-backend"] +portaudio_backend = ["librespot-playback/portaudio-backend"] +default = ["pulseaudio_backend"] +.... -Динамические библиотеки, использующие инфраструктуру построения GNU, обычно используют libtool для настройки компиляции и установки динамических библиотек в соответствии с особенностями данной операционной системы. В типичной практике используется копирование встроенного в приложение `libtool`. Если вам нужно использовать внешнюю команду `libtool`, то вы можете использовать версию, поставляемую Коллекцией Портов: +`pulseaudio_backend` — это функция по умолчанию. Она всегда включена, если мы явно не отключим функции по умолчанию, добавив `--no-default-features` в `CARGO_FEATURES`. Здесь мы превращаем функции `portaudio_backend` и `pulseaudio_backend` в опции порта: [.programlisting] .... -USE_AUTOTOOLS= libtool:version[:env] +CARGO_FEATURES= --no-default-features + +OPTIONS_DEFINE= PORTAUDIO PULSEAUDIO + +PORTAUDIO_VARS= CARGO_FEATURES+=portaudio_backend +PULSEAUDIO_VARS= CARGO_FEATURES+=pulseaudio_backend .... -При отсутствии дополнительных операций, `libtool:version` сообщает инфраструктуре построения о применении патча к сценарию configure с установленной в системе копией `libtool`. Означает использование `GNU_CONFIGURE`. Более того, некоторые переменные make и оболочки shell будут назначены для дальнейшего использования этим портом. Подробности смотрите в [.filename]#bsd.autotools.mk#. +==== -При использовании операции `:env` будет настроено только окружение. +[[cargo-ex3]] +.Перечисление лицензий крейтов +[example] +==== +Крейты имеют собственные лицензии. Важно знать, какие они, при добавлении блока `LICENSE` в порт (см. crossref:makefiles[licenses,Лицензии]). Вспомогательная цель `cargo-crates-licenses` попытается перечислить все лицензии всех ящиков, определённых в `CARGO_CRATES`. -Наконец, `LIBTOOLFLAGS` и `LIBTOOLFILES` можно установить по желанию, чтобы переопределить наиболее вероятные аргументы для `libtool` и файлы, предназначенные для изменения. Большинству портов это скорее всего не понадобится. Для дальнейших подробностей смотрите [.filename]#bsd.autotools.mk#. +[source, shell] +.... +% 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 +[...] +.... -[[using-libltdl]] -=== `libltdl` +[NOTE] +====== +Названия лицензий, которые выводит `make cargo-crates-licenses`, являются SPDX 2.1-совместимыми лицензионными выражениями, которые не совпадают с названиями лицензий, определёнными в фреймворке портов. Их необходимо перевести в названия из crossref:makefiles[licenses-license-list,Списка предопределённых лицензий]. +====== -Некоторые порты задействуют пакет с библиотекой `libltdl`, которая является частью комплекта `libtool`. Использование этой библиотеки не вызывает автоматическое использование самой `libtool`, и, таким образом, обеспечивается отдельная конструкция. +==== + +[[using-meson]] +=== Использование `meson` + +Для портов, использующих Meson, определите `USES=meson`. + +[[using-meson-variables]] +.Переменные для портов, использующих `meson` +[cols="1,1", frame="none", options="header"] +|=== +| Переменная +| Описание + +|`MESON_ARGS` +|Порт-специфичные флаги Meson, передаваемые в бинарный файл `meson`. + +|`MESON_BUILD_DIR` +|Путь к директории сборки относительно `WRKSRC`. По умолчанию — `_build`. +|=== + +[[using-meson-example]] +.Пример `USES=meson` +[example] +==== +Этот фрагмент демонстрирует использование Meson для порта. + +[.programlisting] +.... +USES= meson +MESON_ARGS= -Dfoo=enabled +.... + +==== + +[[using-go]] +=== Создание приложений на Go + +Для портов, использующих Go, определите `USES=go`. Обратитесь к crossref:uses[uses-go,`go`] для получения списка переменных, которые можно задать для управления процессом сборки. + +[[go-ex1]] +.Создание порта для приложения на основе модулей Go +[example] +==== +В большинстве случаев достаточно установить переменную `GO_MODULE` в значение, указанное директивой `module` в `go.mod`: + +[.programlisting] +.... +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 — это процесс из пяти этапов. Сначала необходимо предоставить шаблон портов, который загружает дистрибутивный файл приложения: + +[.programlisting] +.... +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> +.... + +Сгенерировать первоначальный [.filename]#distinfo#: + +[source, shell] +.... +% 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. Этот шаг требует наличия установленного пакета package:ports-mgmt/modules2tuple[]: + +[source, shell] +.... +% 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: + +[.programlisting] +.... +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> +.... + +[.filename]#distinfo# необходимо обновить, чтобы включить все дистрибутивные файлы: + +[source, shell] +.... +% 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` перед любым тестированием. +==== + +[[go-ex2]] +.Установка имени выходного бинарного файла или пути установки +[example] +==== +Некоторые порты требуют установки результирующего бинарного файла под другим именем или в путь, отличный от стандартного `${PREFIX}/bin`. Это можно сделать с помощью синтаксиса кортежа `GO_TARGET`, например: + +[.programlisting] +.... +GO_TARGET= ./cmd/ipfs:ipfs-go +.... + +установит бинарный файл `ipfs` как `${PREFIX}/bin/ipfs-go` и + +[.programlisting] +.... +GO_TARGET= ./dnscrypt-proxy:${PREFIX}/sbin/dnscrypt-proxy +.... + +установит `dnscrypt-proxy` в `${PREFIX}/sbin`. +==== + +[[using-cabal]] +=== Построение приложений на Haskell с помощью `cabal` + +Для портов, использующих Cabal, система сборки определяет `USES=cabal`. Обратитесь к crossref:uses[uses-cabal,`cabal`] для получения списка переменных, которые можно задать для управления процессом сборки. + +[[cabal-ex1]] +.Создание порта для приложения Haskell с Hackage +[example] +==== +При подготовке порта Haskell Cabal требуются программы package:devel/hs-cabal-install[] и package:ports-mgmt/hs-cabal2tuple[], поэтому убедитесь, что они установлены заранее. Сначала необходимо определить общие переменные портов, которые позволяют cabal-install загрузить файл дистрибутива пакета: [.programlisting] .... -USE_AUTOTOOLS= libltdl:version +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`: + +[source, shell] +.... +% 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/ .... -Всё, что в настоящее время она делает, это добавление `LIB_DEPENDS` для подходящего порта `libltdl`, потому она предоставляется как удобная функция для помощи в устранении всяких зависимостей от портов autotools вне инфраструктуры `USE_AUTOTOOLS`. Для этого инструмента не существует необязательных операций. +Теперь, когда у нас есть файл описания пакета ShellCheck.cabal в `${WRKSRC}`, мы можем использовать `cabal-configure` для создания плана сборки: -[[using-autoconf]] -=== `autoconf` и `autoheader` +[source, shell] +.... +% 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) +[...] +.... -Вместо сценария configure некоторые порты содержат шаблон autoconf в файле [.filename]#configure.ac#. Вы можете использовать следующие присвоения, чтобы позволить `autoconf` создать сценарий configure, а `autoheader` создать заголовки шаблона для использования в сценарии configure. +После завершения можно сгенерировать список необходимых зависимостей: + +[source, shell] +.... +% make make-use-cabal +USE_CABAL= QuickCheck-2.12.6.1 \ + hashable-1.3.0.0 \ + integer-logarithms-1.0.3 \ +[...] +.... + +Пакеты Haskell могут содержать ревизии, как и порты FreeBSD. Ревизии могут затрагивать только файлы [.filename]#.cabal#. Обратите внимание на дополнительные номера версий после символа `_`. Замените старый список `USE_CABAL` на вновь сгенерированный. + +Наконец, файл [.filename]#distinfo# необходимо перегенерировать, чтобы он содержал все файлы дистрибутива: + +[source, shell] +.... +% 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`. + +[[cabal-ex2]] +.Обработка файлов данных в порте Haskell +[example] +==== +`devel/hs-profiteur` — это приложение на Haskell, которое генерирует одностраничный HTML с некоторым содержимым. [.programlisting] .... -USE_AUTOTOOLS= autoconf:version[:env] +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`: [.programlisting] .... -USE_AUTOTOOLS= autoheader:version +[...] + +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`: + +[.programlisting] .... +[...] -которые также подразумевают использование `autoconf:version`. +CABAL_WRAPPER_SCRIPTS= ${CABAL_EXECUTABLES} +profiteur_DATADIR_VARS= js-jquery -Аналогично команде `libtool` включение необязательной операции `:env` всего лишь настраивает окружение для дальнейшего использования. Без этого выполняется наложение патчей и переконфигурирование порта. +.include <bsd.port.mk> +.... -Дополнительные необязательные переменные `AUTOCONF_ARGS` и `AUTOHEADER_ARGS` можно переопределить в [.filename]#Makefile# порта, если указано явным образом. Как и с эквивалентами `libtool`, большинству портов это вряд ли понадобится. +Теперь порт установит непосредственно бинарный файл в `libexec/cabal/profiteur`, а скрипт — в `bin/profiteur`. -[[using-automake]] -=== `automake` и `aclocal` +==== + +Не существует простого способа определить подходящее значение для параметра `FOO_DATADIR_VARS`, кроме как запустить программу и проверить, что всё работает. К счастью, необходимость использовать `FOO_DATADIR_VARS` возникает очень редко. + +Еще один крайний случай при переносе сложных программ на Haskell — наличие зависимостей от систем контроля версий (VCS) в файле `cabal.project`. + +[[cabal-ex3]] +.Портирование приложений Haskell с зависимостями от VCS +[example] +==== + +`net-p2p/cardano-node` — это чрезвычайно сложное программное обеспечение. В его `cabal.project` содержится множество блоков, подобных этому: + +[.programlisting] +.... +[...] +source-repository-package + type: git + location: https://github.com/input-output-hk/cardano-crypto + tag: f73079303f663e028288f9f4a9e08bcca39a923e +[...] +.... -Некоторые пакеты содержат только файлы [.filename]#Makefile.am#. Они должны быть преобразованы в файлы [.filename]#Makefile.in# с использованием automake и дальнейшей обработкой `configure` для получения настоящего [.filename]#Makefile#. +Зависимости типа `source-repository-package` автоматически подтягиваются `cabal` в процессе сборки. К сожалению, это приводит к использованию сети после этапа `fetch`, что запрещено в рамках системы портов. Эти исходники необходимо указать в Makefile порта. Вспомогательная цель `make-use-cabal` может упростить работу с пакетами, размещёнными на GitHub. Запуск этой цели после стандартных `cabal-extract` и `cabal-configure` позволит получить не только параметр `USE_CABAL`, но и `GH_TUPLE`: -Аналогично, иногда пакеты не поставляются с вложенными файлами [.filename]#aclocal.m4#, снова требуемых для построения программного обеспечения. Их можно получить командой `aclocal`, которая просматривает [.filename]#configure.ac# или [.filename]#configure.in#. +[source, shell] +.... +% 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 \ + [...] +.... -`aclocal` имеет похожую связь с `automake`, как у `autoheader` с `autoconf`, что описано в предыдущей главе. `aclocal` подразумевает использование `automake`, таким образом, мы имеем: +Может быть полезно отделить элементы `GH_TUPLE`, поступающие из `make-use-cabal`, от остальных, чтобы упростить обновление порта: [.programlisting] .... -USE_AUTOTOOLS= automake:version[:env] +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-портов с зависимостями от систем контроля версий временно требует следующего обходного решения: [.programlisting] .... -USE_AUTOTOOLS= aclocal:version +BINARY_ALIAS= git=true .... -которые также подразумевают использование `automake:version`. +==== -Также как и для `libtool` и `autoconf`, подключение необязательной операции `:env` всего лишь устанавливает окружение для дальнейшего пользования. Без этого выполняется реконфигурирование этого порта. +[[using-autotools]] +== Использование GNU Autotools -Как и в случае с `autoconf` и `autoheader`, обе команды `automake` и `aclocal` соответственно имеют необязательные переменные `AUTOMAKE_ARGS` и `ACLOCAL_ARGS`, которые при необходимости можно переопределить в [.filename]#Makefile# порта. +Если порту требуется какое-либо программное обеспечение GNU Autotools, добавьте `USES=autoreconf`. Подробнее см. в crossref:uses[uses-autoreconf,`autoreconf`]. [[using-gettext]] == Использование GNU `gettext` -=== Простой вариант использования +[[using-gettext-basic]] +=== Простые варианты использования -Если для вашего порта требуется `gettext`, добавьте `USES= gettext`, и ваш порт унаследует зависимость от package:devel/gettext[]. crossref:makefiles[uses-makefiles, `USES`] содержит перечень других значений для использования `gettext`. +Если порт требует `gettext`, установите `USES=gettext`, и порт унаследует зависимость от [.filename]#libintl.so# из пакета package:devel/gettext[]. Другие значения для использования `gettext` перечислены в crossref:uses[uses-gettext,`USES=gettext`]. -Довольно распространенным случаем является использование в порте `gettext` и `configure`. Как правило, GNU `configure` способен находить `gettext` автоматически. Если он все же не сможет это сделать, то подсказки для размещения `gettext` можно передать через переменные окружения `CPPFLAGS` и `LDFLAGS`: +Довольно распространённый случай — порт, использующий `gettext` и `configure`. Обычно GNU `configure` должен автоматически находить `gettext`. [.programlisting] .... USES= gettext -CPPFLAGS+= -I${LOCALBASE}/include -LDFLAGS+= -L${LOCALBASE}/lib - GNU_CONFIGURE= yes .... -Конечно же, этот код можно записать в более компактном виде, если передавать флаги в `configure` не требуется: +Если он не сработает, можно указать расположение `gettext` через `CPPFLAGS` и `LDFLAGS`, используя `localbase` следующим образом: [.programlisting] .... -USES= gettext +USES= gettext localbase:ldflags GNU_CONFIGURE= yes .... +[[using-gettext-optional]] === Оптимальное использование Некоторые программные продукты позволяют отключать NLS, к примеру, передавая параметр `--disable-nls` сценарию `configure`. В этом случае ваш порт должен использовать `gettext`, в зависимости от значения `NLS`. Для портов небольшой или средней сложности вы можете полагаться на следующую идиому: [.programlisting] .... -GNU_CONFIGURE= yes +GNU_CONFIGURE= yes + +OPTIONS_DEFINE= NLS +OPTIONS_SUB= yes + +NLS_USES= gettext +NLS_CONFIGURE_ENABLE= nls + +.include <bsd.port.mk> +.... + +Или используя старый способ с опциями: + +[.programlisting] +.... +GNU_CONFIGURE= yes + +OPTIONS_DEFINE= NLS .include <bsd.port.options.mk> @@ -471,7 +1164,7 @@ PLIST_SUB+= NLS="@comment " .include <bsd.port.mk> .... -Следующий пункт в вашем списке дел разобраться, чтобы файлы каталога сообщения включались в список упаковки по условию. Часть, входящая в [.filename]#Makefile#, уже обеспечена этой идиомой. Остальное объясняется в главе <<plist-sub,продвинутые практики [.filename]#pkg-plist#>>. Вкратце, каждое вхождение `%%NLS%%` в [.filename]#pkg-plist# будет заменено на "`@comment`", если NLS выключен, или пустой строкой, если включен. В результате строки, предваряемые `%%NLS%%`, станут комментариями в итоговом листе упаковки, если NLS выключен; иначе, префикс будет просто удален. Всё, что вам нужно, это вставить `%%NLS%%` перед каждым путем к файлу каталога сообщений в [.filename]#pkg-plist#. Например: +Следующий пункт в списке задач — организовать условное включение файлов каталогов сообщений в упаковочный список. Часть, связанная с [.filename]#Makefile#, уже предусмотрена идиомой. Это объясняется в разделе crossref:plist[plist-sub,расширенные практики работы с [.filename]#pkg-plist#]. Вкратце, каждое вхождение `%%NLS%%` в [.filename]#pkg-plist# будет заменено на "`@comment `", если NLS отключен, или на пустую строку, если NLS включен. Следовательно, строки с префиксом `%%NLS%%` станут обычными комментариями в итоговом упаковочном списке, если NLS выключен; в противном случае префикс будет просто удален. Затем вставьте `%%NLS%%` перед каждым путем к файлу каталога сообщений в [.filename]#pkg-plist#. Например: [.programlisting] .... @@ -479,8 +1172,9 @@ PLIST_SUB+= NLS="@comment " %%NLS%%share/locale/no/LC_MESSAGES/foobar.mo .... -В особо сложных случаях вам понадобиться использовать более продвинутые техники, чем данный рецепт, такие как <<plist-dynamic,динамические списки упаковки>>. +В особо сложных случаях вам понадобиться использовать более продвинутые техники, чем данный рецепт, такие как crossref:plist[plist-dynamic,динамические списки упаковки]. +[[using-gettext-catalog-directories]] === Управление каталогами сообщений Существует момент, который следует учитывать при установке файлов каталогов сообщений. Целевые каталоги для размещения, расположенные под [.filename]#LOCALBASE/shared/locale#, редко когда должны создаваться и удаляться портом. Для наиболее популярных языков имеются собственные каталоги, перечисленные в [.filename]#PORTSDIR/Templates/BSD.local.dist#. Каталоги для множества других языков управляются с помощью порта package:devel/gettext[]. Обратите внимание на его [.filename]#pkg-plist# и посмотрите, куда данный порт собирается установить файлы каталогов сообщений для единственного в своем роде языка. @@ -488,45 +1182,46 @@ PLIST_SUB+= NLS="@comment " [[using-perl]] == Использование Perl -Если `MASTER_SITES` установлена в значение `MASTER_SITE_PERL_CPAN`, то предпочтительным значением `MASTER_SITE_SUBDIR` является имя иерархии верхнего уровня. Например, рекомендуемым значением для `p5-Module-Name` является `Module`. Иерархию верхнего уровня можно посмотреть на сайте http://cpan.org/modules/by-module/[cpan.org]. Это поддерживает порт в рабочем состоянии при изменении модуля автором. +Если `MASTER_SITES` установлена в значение `CPAN`, то правильная поддиректория выбирается автоматически. Если подкаталог по умолчанию указан неверно, можно использовать `CPAN/Module` для его изменения. Также можно установить `MASTER_SITES` в старое значение `MASTER_SITE_PERL_CPAN`, тогда предпочтительным значением `MASTER_SITE_SUBDIR` будет имя иерархии выше уровнем. Например, рекомендуемое значение для `p5-Module-Name` - `Module`. Иерархию верхнего уровня можно посмотреть на https://cpan.org/modules/by-module/[cpan.org]. Это гарантирует работоспособность порта при смене автора модуля. -Исключением этого правила является отсутствие соответствующего каталога или файла с дистрибутивом в этом каталоге. В качестве `MASTER_SITE_SUBDIR` в этом случае разрешается использовать id автора. +Исключением этого правила является отсутствие соответствующего каталога или файла с дистрибутивом в этом каталоге. В качестве `MASTER_SITE_SUBDIR` в этом случае разрешается использовать id автора. Можно использовать макрос `CPAN:AUTHOR`, который будет преобразован в хешированный каталог автора. Например, `CPAN:AUTHOR` преобразуется в `authors/id/A/AU/AUTHOR`. -В качестве значения все из настраиваемых knobs ниже принимают `YES` или строку с версией вида `5.8.0+`. `YES` означает, что данный порт можно использовать с любой из поддерживаемых версий Perl. Если порт работает только с некоторыми версиями Perl, то это можно обозначить при помощи строки с версией, указывающей на минимальную версию (пример: `5.7.3+`), максимальную версию (пример: `5.8.0-`) или точную версию (пример: `5.8.3`). +Когда порту требуется поддержка Perl, он должен установить `USES=perl5` с опциональным `USE_PERL5`, как описано в crossref:uses[uses-perl5,описание USES для perl5]. -.Переменные для портов, использующих Perl +[[using-perl-variables]] +.Переменные (только для чтения) для портов, использующих Perl [cols="1,1", frame="none", options="header"] |=== -| Переменная +| Переменные (только для чтения) | Значение -|`USE_PERL5` -|Perl 5 используется для построения и работы. +|`PERL` +|Полный путь к интерпретатору Perl 5, будь то системный или установленный из порта, но без номера версии. Используйте это, когда программному обеспечению требуется путь к интерпретатору Perl. Для замены строк "``#!``" в скриптах используйте crossref:uses[uses-shebangfix,`shebangfix`]. -|`USE_PERL5_BUILD` -|Perl 5 используется для построения. +|`PERL_VERSION` +|Полная версия Perl установлена (например, `5.8.9`). -|`USE_PERL5_RUN` -|Perl 5 используется во время работы. +|`PERL_LEVEL` +|Установленная версия Perl в виде целого числа формата `MNNNPP` (например, `500809`). -|`PERL` -|Полный путь к интерпретатору Perl 5, либо в системе, либо установленному из портов, но без номера версии. Используйте это, если вам нужно заменить строки "`#!`" в скриптах. +|`PERL_ARCH` +|Где Perl хранит архитектурно-зависимые библиотеки. По умолчанию: `${ARCH}-freebsd`. -|`PERL_CONFIGURE` -|Конфигурация при помощи MakeMaker языка Perl. Влечёт `USE_PERL5`. +|`PERL_PORT` +|Имя порта Perl, который установлен (например, `perl5`). -|`PERL_MODBUILD` -|Конфигурация, построение и установка с использованием Module::Build. Влечёт `PERL_CONFIGURE`. +|`SITE_PERL` +|Имя каталога, в котором размещаются специфичные для сайта пакеты Perl. Это значение добавляется в `PLIST_SUB`. |=== [NOTE] ==== -Порты для модулей Perl, которые не имеют официального вебсайта, должны указывать `cpan.org` в строке WWW в файле [.filename]#pkg-descr#. Предпочтительная форма URL `http://search.cpan.org/dist/Module-Name/` (включая завершающий слэш). +Порты Perl-модулей, у которых нет официального сайта, должны ссылаться на `cpan.org` в строке WWW файла [.filename]#Makefile#. Предпочтительный формат URL: `https://search.cpan.org/dist/Module-Name/` (включая завершающий слеш). ==== [NOTE] ==== -Не используйте `${SITE_PERL}` в объявлении зависимостей. Использование этой конструкции подразумевает наличие подключенного [.filename]#bsd.perl.mk#, что не всегда так. Порты, зависимые от этого порта, получат неправильные зависимости, если файлы этого порта будут перемещены при последующем обновлении. Правильный способ объявления зависимостей для модулей Perl показан в примере ниже. +Не используйте `${SITE_PERL}` в объявлениях зависимостей. Это предполагает, что был включён файл [.filename]#perl5.mk#, что не всегда верно. Порты, зависящие от этого порта, будут иметь некорректные зависимости, если файлы этого порта будут перемещены во время обновления. Правильный способ объявления зависимостей модулей Perl показан в примере ниже. ==== [[use-perl-dependency-example]] @@ -535,125 +1230,199 @@ PLIST_SUB+= NLS="@comment " ==== [.programlisting] .... -p5-IO-Tee>=0.64:${PORTSDIR}/devel/p5-IO-Tee +p5-IO-Tee>=0.64:devel/p5-IO-Tee .... ==== -Для портов Perl, которые устанавливают страницы справочника, в [.filename]#pkg-plist# можно использовать макрос `PERL5_MANx` (где _x_ принимает значение от `1` до `9`). Например, +Для портов Perl, которые устанавливают страницы руководства, макросы `PERL5_MAN3` и `PERL5_MAN1` могут использоваться внутри [.filename]#pkg-plist#. Например, [.programlisting] .... +lib/perl5/5.14/man/man1/event.1.gz lib/perl5/5.14/man/man3/AnyEvent::I3.3.gz .... -можно заменить на +может быть заменено на [.programlisting] .... +%%PERL5_MAN1%%/event.1.gz %%PERL5_MAN3%%/AnyEvent::I3.3.gz .... +[NOTE] +==== +Для других разделов (_x_ в `2` и `4`–`9`) макросы `PERL5_MAN_x_` отсутствуют, так как они устанавливаются в обычные каталоги. +==== + +[[use-perl-ex-build]] +.Порт, требующий Perl только для сборки +[example] +==== +Поскольку значение USE_PERL5 по умолчанию включает build и run, установите его в: + +[.programlisting] +.... +USES= perl5 +USE_PERL5= build +.... + +==== + +[[use-perl-ex-patch]] +.Порт, который также требует Perl для исправления +[example] +==== +Время от времени использования man:sed[1] для исправлений недостаточно. Когда использование man:perl[1] проще, примените: + +[.programlisting] +.... +USES= perl5 +USE_PERL5= patch build run +.... + +==== + +[[use-perl-ex-configure]] +.Модуль Perl, для сборки которого требуется `ExtUtils::MakeMaker` +[example] +==== +Большинство модулей Perl поставляются с конфигурационным скриптом [.filename]#Makefile.PL#. В этом случае установите: + +[.programlisting] +.... +USES= perl5 +USE_PERL5= configure +.... + +==== + +[[use-perl-ex-modbuild]] +.Модуль Perl, для сборки которого требуется `Module::Build` +[example] +==== +Когда модуль Perl поставляется с конфигурационным скриптом [.filename]#Build.PL#, он может требовать Module::Build, и в этом случае установите + +[.programlisting] +.... +USES= perl5 +USE_PERL5= modbuild +.... + +Если вместо этого требуется Module::Build::Tiny, установите + +[.programlisting] +.... +USES= perl5 +USE_PERL5= modbuildtiny +.... + +==== + [[using-x11]] == Использование X11 [[x11-variables]] === Компоненты X.Org -X.Org является реализацией X11, доступной в Коллекции Портов. Если ваше приложение зависит от компонентов X, установите в переменную `USE_XORG` в перечень требуемых компонентов. К настоящему времени доступными компонентами являются: - -`bigreqsproto compositeproto damageproto dmx dmxproto dri2proto evieproto fixesproto fontcacheproto fontenc fontsproto fontutil glproto ice inputproto kbproto libfs oldx pciaccess pixman printproto randrproto recordproto renderproto resourceproto scrnsaverproto sm trapproto videoproto x11 xau xaw xaw6 xaw7 xbitmaps xcmiscproto xcomposite xcursor xdamage xdmcp xevie xext xextproto xf86bigfontproto xf86dgaproto xf86driproto xf86miscproto xf86rushproto xf86vidmodeproto xfixes xfont xfontcache xft xi xinerama xineramaproto xkbfile xkbui xmu xmuu xorg-server xp xpm xprintapputil xprintutil xproto xproxymngproto xrandr xrender xres xscrnsaver xt xtrans xtrap xtst xv xvmc xxf86dga xxf86misc xxf86vm`. - -Всегда актуальный перечень можно найти в [.filename]#/usr/ports/Mk/bsd.xorg.mk#. +Реализация X11, доступная в Коллекции портов, — это X.Org. Если приложение зависит от компонентов X, добавьте `USES= xorg` и укажите необходимые компоненты в `USE_XORG`. Полный список можно найти в crossref:uses[uses-xorg,`xorg`]. -Проект Mesa является попыткой обеспечить свободную реализацию OpenGL. Вы можете указать зависимость от различных компонентов этого проекта при помощи переменной `USE_GL`. Действительные опции: `glut, glu, glw, glew, gl` и `linux`. Для обратной совместимости значение `yes` соответствует `glu`. +Проект Mesa — это инициатива по предоставлению свободной реализации OpenGL. Чтобы указать зависимость от различных компонентов этого проекта, используйте `USES=gl` и `USE_GL`. См. crossref:uses[uses-gl,`gl`] для полного списка доступных компонентов. Для обратной совместимости значение `yes` соответствует `glu`. [[use-xorg-example]] -.Пример для USE_XORG +.Пример `USE_XORG` [example] ==== [.programlisting] .... -USE_XORG= xrender xft xkbfile xt xaw +USES= gl xorg USE_GL= glu +USE_XORG= xrender xft xkbfile xt xaw .... ==== +[[using-xorg-variables]] .Переменные для портов, использующих X [cols="1,1", frame="none"] |=== |`USES= imake` -|Используется `imake`. +|Порт использует `imake`. |`XMKMF` -|Задаёт маршрут до `xmkmf`, если он отсутствует в `PATH`. По умолчанию это `xmkmf -a`. +|Установить путь к `xmkmf`, если он отсутствует в `PATH`. По умолчанию: `xmkmf -a`. |=== [[using-x11-vars]] -.Использование переменных X11 в порте +.Использование переменных, связанных с X11 [example] ==== [.programlisting] .... -# Использовать некоторые библиотеки X11 +# Use some X11 libraries +USES= xorg USE_XORG= x11 xpm .... ==== -[[porting-motif]] -=== Порты, которым требуется Motif +[[x11-motif]] +=== Порты, требующие Motif -Если вашему порту требуется Motif, задайте переменную `USES= motif` в файле [.filename]#Makefile#. Реализация Motif, используемая по умолчанию, находится в package:x11-toolkits/open-motif[]. Пользователи вместо этого могут выбрать package:x11-toolkits/lesstif[] через установку переменной `WANT_LESSTIF`. +Если порт требует библиотеку Motif, определите `USES= motif` в [.filename]#Makefile#. Реализация Motif по умолчанию — это package:x11-toolkits/open-motif[]. Пользователи могут выбрать package:x11-toolkits/lesstif[] вместо этого, установив `WANT_LESSTIF` в своём [.filename]#make.conf#. Аналогично package:x11-toolkits/open-motif-devel[] можно выбрать, установив `WANT_OPEN_MOTIF_DEVEL` в [.filename]#make.conf#. -Переменная `MOTIFLIB` будет установлена в [.filename]#bsd.port.mk#, чтобы ссылаться на соответствующую библиотеку Motif. Пожалуйста, измените исходные тексты вашего порта на использование `${MOTIFLIB}` везде, где упоминается библиотека Motif, в первоначальном [.filename]#Makefile# или [.filename]#Imakefile#. +`MOTIFLIB` будет установлен в файле [.filename]#motif.mk# для ссылки на соответствующую библиотеку Motif. Пожалуйста, исправьте исходный код порта, чтобы использовать `${MOTIFLIB}` везде, где библиотека Motif упоминается в оригинальном [.filename]#Makefile# или [.filename]#Imakefile#. -Существует два общих случая: +Есть два распространённых случая: -* Если порт обращается к библиотеке Motif как `-lXm` в своих файлах [.filename]#Makefile# или [.filename]#Imakefile#, просто подставьте вместо этих обращений `${MOTIFLIB}`. -* Если порт использует `XmClientLibs` в своем файле [.filename]#Imakefile#, измените это обращение на `${MOTIFLIB} ${XTOOLLIB} ${XLIB}`. +* Если порт ссылается на библиотеку Motif как `-lXm` в своем [.filename]#Makefile# или [.filename]#Imakefile#, замените это на `${MOTIFLIB}`. +* Если порт использует `XmClientLibs` в своем [.filename]#Imakefile#, замените это на `${MOTIFLIB} ${XTOOLLIB} ${XLIB}`. -Заметьте, что переменная `MOTIFLIB` (как правило) раскрывается в `-L/usr/local/lib -lXm` или `/usr/local/lib/libXm.a`, так что нет нужды впереди добавлять `-L` или `-l`. +Обратите внимание, что `MOTIFLIB` (обычно) раскрывается в `-L/usr/local/lib -lXm -lXp` или `/usr/local/lib/libXm.a`, поэтому нет необходимости добавлять `-L` или `-l` перед этим. -=== Шрифты для X11 +[[x11-fonts]] +=== Шрифты X11 -Если ваш порт устанавливает шрифты для X Window System, поместите их в каталог [.filename]#LOCALBASE/lib/X11/fonts/local#. +Если порт устанавливает шрифты для X Window System, поместите их в [.filename]#LOCALBASE/lib/X11/fonts/local#. -=== Получение поддельного `DISPLAY`, используя Xvfb +[[x11-fake-display]] +=== Получение поддельного `DISPLAY` с помощью Xvfb -Некоторые приложения для успешной компиляции требуют наличие работающего дисплея X11. Это создает проблему для машин, которые работают в режиме headless. При использовании следующего канонического хака инфраструктура построения запустит сервер X в виртуальном фреймбуфере. Затем переменная работающего `DISPLAY` передается при построении. +Некоторые приложения требуют рабочего дисплея X11 для успешной компиляции. Это создаёт проблему для машин, работающих без монитора. При использовании этой переменной инфраструктура сборки запустит виртуальный X-сервер с буфером кадров. Рабочий `DISPLAY` затем передаётся в процесс сборки. См. crossref:uses[uses-display,`USES=display`] для возможных аргументов. [.programlisting] .... USES= display .... + [[desktop-entries]] -=== Элементы рабочего стола +=== Desktop Entries (пункты рабочего стола) -Элементы рабочего стола (http://standards.freedesktop.org/desktop-entry-spec/latest/[стандарта Freedesktop]) предоставляют способ автоматической настройки функций рабочего стола при установке новой программы, не требуя вмешательства пользователя. Например, новые программы автоматически отображаются в меню приложений совместимых окружений рабочего стола. Элементы рабочего стола изначально появились в окружении рабочего стола GNOME, но в настоящее время являются стандартом и также работают с KDE и Xfce. Такая небольшая автоматизация предоставляет реальное удобство для пользователя, и посему элементы рабочего стола приветствуются в приложениях, которые можно использовать в окружении рабочего стола. +Desktop entries (https://standards.freedesktop.org/desktop-entry-spec/latest/[стандарт Freedesktop]) предоставляют способ автоматической настройки функций рабочего стола при установке новой программы без вмешательства пользователя. Например, вновь установленные программы автоматически появляются в меню приложений совместимых сред рабочего стола. Desktop entries появились в среде GNOME, но теперь стали стандартом и также работают с KDE и Xfce. Эта автоматизация приносит реальную пользу пользователю, поэтому Desktop entries рекомендуются для приложений, которые могут использоваться в среде рабочего стола. +[[desktop-entries-predefined]] ==== Использование предопределенных файлов [.filename]#.desktop# -Порты, включающие предопределенные файлы [.filename]#*.desktop#, должны включать эти файлы в [.filename]#pkg-plist# и устанавливать их в каталог [.filename]#$LOCALBASE/shared/applications#. Для установки этих файлов используется <<install-macros,макрос `INSTALL_DATA`>>. +Порты, включающие предопределённые файлы [.filename]#*.desktop#, должны добавлять эти файлы в [.filename]#pkg-plist# и устанавливать их в директорию [.filename]#$LOCALBASE/share/applications#. Для установки таких файлов полезен макрос crossref:makefiles[install-macros,`INSTALL_DATA`]. [[updating-desktop-database]] ==== Обновление базы данных рабочего стола -Если в файле порта [.filename]#portname.desktop# имеется запись MimeType, то база данных рабочего стола олжна быть обновлена после установки и удаления. Для этого укажите `USES`= desktop-file-utils. +Если порт имеет запись MimeType в файле [.filename]#portname.desktop#, базу данных рабочего стола необходимо обновить после установки и удаления. Для этого определите `USES`= desktop-file-utils. [[desktop-entries-macro]] -==== Создание элементов рабочего стола с использованием `DESKTOP_ENTRIES` +==== Создание Desktop Entries с помощью `DESKTOP_ENTRIES` -Элементы рабочего стола можно легко создавать для приложений, используя переменную `DESKTOP_ENTRIES`. Будет автоматически создан, установлен и добавлен в [.filename]#pkg-plist# файл с названием [.filename]#name.desktop#. Синтаксис: +Desktop Entries могут быть легко созданы для приложений с использованием `DESKTOP_ENTRIES`. Файл с именем [.filename]#name.desktop# будет создан, установлен и автоматически добавлен в [.filename]#pkg-plist#. Синтаксис следующий: [.programlisting] .... DESKTOP_ENTRIES= "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify .... -Перечень возможных категорий доступен на http://standards.freedesktop.org/menu-spec/latest/apa.html[вебсайте Freedesktop]. `StartupNotify` отобразит, поддерживает ли приложение _уведомления о запуске_. Как правило, это графический индикатор часы вместо указателя мыши, меню или панель, которые уведомляют пользователя о загрузке программы. Программа, поддерживающая уведомления о запуске, очистит этот индикатор после запуска. Программы, несовместимые с уведомлениями о запуске, не будут очищать индикатор (возможно, вызывая путаницу и приводя пользователей в бешенство), и поэтому должны иметь `StartupNotify` в выключенном состоянии `false`; тогда индикатор не будет отображаться совсем. +Список возможных категорий доступен на https://standards.freedesktop.org/menu-spec/latest/apa.html[сайте Freedesktop]. `StartupNotify` указывает, совместимо ли приложение с _уведомлениями о запуске_. Обычно это графический индикатор, например, часы, который появляется у указателя мыши, в меню или на панели, чтобы дать пользователю понять, что программа запускается. Программа, совместимая с уведомлениями о запуске, очищает индикатор после своего старта. Программы, не совместимые с уведомлениями о запуске, никогда не очищают индикатор (что может сбивать с толку и раздражать пользователя), и у них должен быть установлен параметр `StartupNotify` в значение `false`, чтобы индикатор вообще не отображался. Пример: @@ -665,163 +1434,803 @@ DESKTOP_ENTRIES= "ToME" "Roguelike game based on JRR Tolkien's work" \ false .... +`DESKTOP_ENTRIES` устанавливаются в директорию, указанную переменной `DESKTOPDIR`. По умолчанию `DESKTOPDIR` имеет значение [.filename]#${PREFIX}/share/applications# + + [[using-gnome]] == Использование GNOME -Для задания того, какие компоненты GNOME использует конкретный порт, проект FreeBSD/GNOME использует собственный набор переменных. На странице проекта FreeBSD/GNOME размещён http://www.FreeBSD.org/gnome/docs/porting/[ исчерпывающий список этих переменных]. +[[using-gnome-introduction]] +=== Введение -[[using-qt]] -== Использование Qt +Эта глава объясняет фреймворк GNOME, используемый в портах. Фреймворк можно условно разделить на базовые компоненты, компоненты рабочего стола GNOME и несколько специальных макросов, упрощающих работу сопровождающих портов. -[[qt-common]] -=== Порты, для которых требуется Qt +[[use-gnome]] +=== Использование `USE_GNOME` -.Переменные для портов, использующих Qt -[cols="1,1", frame="none"] +Добавление этой переменной в порт позволяет использовать макросы и компоненты, определённые в [.filename]#bsd.gnome.mk#. Код в [.filename]#bsd.gnome.mk# добавляет необходимые зависимости для сборки, выполнения или библиотеки, а также обработку специальных файлов. Приложения GNOME в FreeBSD используют инфраструктуру `USE_GNOME`. Включите все необходимые компоненты в виде списка, разделённого пробелами. Компоненты `USE_GNOME` разделены на следующие виртуальные списки: основные компоненты, компоненты GNOME 3 и устаревшие компоненты. Если порту требуются только библиотеки GTK3, это кратчайший способ определить это: + +[.programlisting] +.... +USE_GNOME= gtk30 +.... + +`USE_GNOME` компоненты автоматически добавляют необходимые им зависимости. Подробный список всех компонентов `USE_GNOME`, а также информацию о том, какие другие компоненты они подразумевают и их зависимости, можно найти в crossref:special[gnome-components, Компоненты GNOME]. + +Вот пример [.filename]#Makefile# для порта GNOME, в котором используются многие методы, описанные в этом документе. Пожалуйста, используйте его в качестве руководства при создании новых портов. + +[.programlisting] +.... +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> +.... + +[NOTE] +==== +Макрос `USE_GNOME` без аргументов не добавляет никаких зависимостей к порту. `USE_GNOME` не может быть установлен после [.filename]#bsd.port.pre.mk#. +==== + +[[using-gnome-variables]] +=== Переменные + +Этот раздел объясняет, какие макросы доступны и как они используются. Как, например, в приведённом выше примере. В crossref:special[gnome-components, Компоненты GNOME] содержится более подробное объяснение. Для использования этих макросов необходимо установить `USE_GNOME`. + +`GLIB_SCHEMAS`:: +Список всех файлов схем glib, которые устанавливает порт. Макрос добавит файлы в plist порта и обработает регистрацию этих файлов при установке и удалении. ++ +Файлы схем glib написаны в XML и имеют расширение [.filename]#gschema.xml#. Они устанавливаются в директорию [.filename]#share/glib-2.0/schemas/#. Эти файлы схем содержат все настройки конфигурации приложений со значениями по умолчанию. Фактическая база данных, используемая приложениями, создаётся с помощью glib-compile-schema, которая запускается макросом `GLIB_SCHEMAS`. ++ +[.programlisting] +.... +GLIB_SCHEMAS=foo.gschema.xml +.... ++ +[NOTE] +==== +Не добавляйте схемы glib в файл [.filename]#pkg-plist#. Если они указаны в [.filename]#pkg-plist#, они не будут зарегистрированы, и приложения могут работать некорректно. +==== + +`GCONF_SCHEMAS`:: +Перечислите все файлы схем gconf. Макрос добавит файлы схем в plist порта и обеспечит их регистрацию при установке и удалении. ++ +GConf — это база данных на основе XML, которую используют практически все приложения GNOME для хранения своих настроек. Эти файлы устанавливаются в директорию [.filename]#etc/gconf/schemas#. Эта база данных определяется установленными файлами схем, которые используются для генерации ключевых файлов [.filename]#%gconf.xml#. Для каждого файла схемы, устанавливаемого портом, должна быть запись в [.filename]#Makefile#: ++ +[.programlisting] +.... +GCONF_SCHEMAS=my_app.schemas my_app2.schemas my_app3.schemas +.... ++ +[NOTE] +==== +Схемы Gconf перечислены в макросе `GCONF_SCHEMAS`, а не в файле [.filename]#pkg-plist#. Если они указаны в [.filename]#pkg-plist#, они не будут зарегистрированы, и приложения могут работать некорректно. +==== + +`INSTALLS_OMF`:: +Файлы Open Source Metadata Framework (OMF) часто используются приложениями GNOME 2. Эти файлы содержат информацию о файлах справки приложений и требуют специальной обработки с помощью ScrollKeeper/rarian. Для правильной регистрации файлов OMF при установке приложений GNOME из пакетов убедитесь, что файлы `omf` указаны в `pkg-plist` и что в [.filename]#Makefile# порта определено `INSTALLS_OMF`: ++ +[.programlisting] +.... +INSTALLS_OMF=yes +.... ++ +При установке [.filename]#bsd.gnome.mk# автоматически сканирует [.filename]#pkg-plist# и добавляет соответствующие директивы `@exec` и `@unexec` для каждого файла [.filename]#.omf#, который необходимо отслеживать в базе данных регистрации OMF. + +[[gnome-components]] +== Компоненты GNOME + +Для получения дополнительной помощи с портом GNOME, ознакомьтесь с некоторыми из link:https://ports.FreeBSD.org[существующих портов] в качестве примеров. На странице link:https://www.FreeBSD.org/gnome/[FreeBSD GNOME] указана контактная информация, если требуется дополнительная помощь. Компоненты разделены на используемые в настоящее время компоненты GNOME и устаревшие компоненты. Если компонент поддерживает аргументы, они перечислены в скобках в описании. Первый аргумент является значением по умолчанию. "Both" указывается, если компонент по умолчанию добавляется как в зависимости для сборки, так и для выполнения. + +[[gnome-components-list]] +.Компоненты GNOME +[cols="1,1,1", options="header"] |=== -|`USE_QT4` -|Указывает инструменты и библиотеки в качестве зависимостей для портов, которые используют Qt 4. Для получения подробностей смотрите <<qt4-components,выбор компонентов Qt 4>>. +| Компонент +| Связанная программа +| Описание -|`QT_PREFIX` -|Устанавливается в значение, содержащее путь к установленному Qt (переменная только для чтения). +|`atk` +|accessibility/atk +|Инструментарий доступности (ATK) -|`MOC` -|Устанавливается в значение, содержащее путь к `moc` (переменная только для чтения). По умолчанию устанавливается в соответствии со значением `USE_QT_VER`. +|`atkmm` +|accessibility/atkmm +|C++ интерфейс для atk + +|`cairo` +|graphics/cairo +|Векторная графическая библиотека с поддержкой вывода на различные устройства -|`QTCPPFLAGS` -|Дополнительные флаги компилятора для инструментального пакета Qt, передаваемые через переменную `CONFIGURE_ENV`. По умолчанию устанавливается в соответствии со значением `USE_QT_VER`. +|`cairomm` +|graphics/cairomm +|C++ интерфейс для cairo -|`QTCFGLIBS` -|Дополнительные флаги компоновки для инструментального пакета Qt, передаваемые через переменную `CONFIGURE_ENV`. По умолчанию устанавливается в соответствии со значением `USE_QT_VER`. +|`dconf` +|devel/dconf +|Система базы данных конфигурации (both, build, run) -|`QTNONSTANDARD` -|Подавляет изменение `CONFIGURE_ENV`, `CONFIGURE_ARGS`, `CPPFLAGS` и `MAKE_ENV`. +|`evolutiondataserver3` +|databases/evolution-data-server +|Бэкенды данных для интегрированного почтового клиента/PIM Evolution + +|`gdkpixbuf2` +|graphics/gdk-pixbuf2 +|Графическая библиотека для GTK+ + +|`glib20` +|devel/glib20 +|Основная библиотека GNOME `glib20` + +|`glibmm` +|devel/glibmm +|C++ интерфейс для glib20 + +|`gnomecontrolcenter3` +|sysutils/gnome-control-center +|Центр управления GNOME 3 + +|`gnomedesktop3` +|x11/gnome-desktop +|Библиотека пользовательского интерфейса рабочего стола GNOME 3 + +|`gsound` +|audio/gsound +|Библиотека GObject для воспроизведения системных звуков (both, build, run) + +|`gtk-update-icon-cache` +|graphics/gtk-update-icon-cache +|Утилита `gtk-update-icon-cache` из набора инструментов `Gtk+` + +|`gtk20` +|x11-toolkits/gtk20 +|Набор инструментов Gtk+ 2 + +|`gtk30` +|x11-toolkits/gtk30 +|Набор инструментов Gtk+ 3 + +|`gtkmm20` +|x11-toolkits/gtkmm20 +|C++ интерфейс 2.0 для инструментария gtk20 + +|`gtkmm24` +|x11-toolkits/gtkmm24 +|C++ интерфейс 2.4 для инструментария gtk20 + +|`gtkmm30` +|x11-toolkits/gtkmm30 +|C++ интерфейс 3.0 для набора инструментов gtk30 + +|`gtksourceview2` +|x11-toolkits/gtksourceview2 +|Виджет, добавляющий подсветку синтаксиса в GtkTextView + +|`gtksourceview3` +|x11-toolkits/gtksourceview3 +|Текстовая виджет, добавляющая подсветку синтаксиса к виджету GtkTextView + +|`gtksourceviewmm3` +|x11-toolkits/gtksourceviewmm3 +|C++ интерфейс для библиотеки gtksourceview3 + +|`gvfs` +|devel/gvfs +|Виртуальная файловая система GNOME + +|`intltool` +|textproc/intltool +|Инструмент для интернационализации (см. также intlhack) + +|`introspection` +|devel/gobject-introspection +|Базовые привязки (биндинги) интроспекции и инструменты для генерации привязок интроспекции. В большинстве случаев достаточно `:build`, `:both`/`:run` нужны только для приложений, использующих привязки интроспекции. (both, build, run) + +|`libgda5` +|databases/libgda5 +|Обеспечивает единообразный доступ к различным типам источников данных + +|`libgda5-ui` +|databases/libgda5-ui +|Библиотека пользовательского интерфейса из библиотеки libgda5 + +|`libgdamm5` +|databases/libgdamm5 +|привязки C++ для библиотеки libgda5 + +|`libgsf` +|devel/libgsf +|Расширяемая абстракция ввода-вывода для работы со структурированными форматами файлов + +|`librsvg2` +|graphics/librsvg2 +|Библиотека для разбора и отображения SVG-файлов векторной графики + +|`libsigc++20` +|devel/libsigc++20 +|Фреймворк обратных вызовов для C++ + +|`libxml++26` +|textproc/libxml++26 +|C++ привязки для библиотеки libxml2 + +|`libxml2` +|textproc/libxml2 +|Библиотека парсера XML (both, build, run) + +|`libxslt` +|textproc/libxslt +|Библиотека XSLT (сборка, выполнение) + +|`metacity` +|x11-wm/metacity +|Менеджер окон из GNOME + +|`nautilus3` +|x11-fm/nautilus +|GNOME файловый менеджер + +|`pango` +|x11-toolkits/pango +|Открытый фреймворк для разметки и отображения интернационализированного текста + +|`pangomm` +|x11-toolkits/pangomm +|C++ интерфейс для библиотеки pango + +|`py3gobject3` +|devel/py3-gobject3 +|Python 3, интерфейс GObject 3.0 + +|`pygobject3` +|devel/py-gobject3 +|Python 2, интерфейс GObject 3.0 + +|`vte3` +|x11-toolkits/vte3 +|Виджет терминала с улучшенной поддержкой доступности и интернационализации (I18N) |=== -.Дополнительные переменные для портов, использующих Qt 4.x -[cols="1,1", frame="none"] +[[gnome-components-macro]] +.Компоненты макросов GNOME +[cols="1,1", options="header"] |=== -|`UIC` -|Устанавливает путь к `uic` (переменная только для чтения). +| Компонент +| Описание -|`QMAKE` -|Устанавливает путь к `qmake` (переменная только для чтения). +|`gnomeprefix` +|Предоставляет `configure` некоторые стандартные расположения. -|`QMAKESPEC` -|Устанавливает путь к конфигурационному файлу для `qmake` (переменная только для чтения). +|`intlhack` +|То же, что и `intltool`, но с патчами для гарантии использования [.filename]#share/locale/#. Используйте только в случае, когда одного `intltool` недостаточно. -|`QMAKEFLAGS` -|Дополнительные флаги для `qmake`. +|`referencehack` +|Этот макрос предназначен для помощи в разделении API или справочной документации на собственный порт. +|=== -|`QT_INCDIR` -|Устанавливает каталоги для заголовков Qt 4 (переменная только для чтения). +[[gnome-components-legacy]] +.Компоненты GNOME Legacy +[cols="1,1,1", options="header"] +|=== +| Компонент +| Связанная программа +| Описание -|`QT_LIBDIR` -|Устанавливает путь к библиотекам Qt 4 (переменная только для чтения). +|`atspi` +|accessibility/at-spi +|Интерфейс поставщика услуг вспомогательных технологий (AT-SPI) + +|`esound` +|audio/esound +|Пакет звука Enlightenment + +|`gal2` +|x11-toolkits/gal2 +|Коллекция виджетов, взятых из GNOME 2 gnumeric + +|`gconf2` +|devel/gconf2 +|Система базы данных конфигурации для GNOME 2 + +|`gconfmm26` +|devel/gconfmm26 +|C++ привязки C++ для gconf2 + +|`gdkpixbuf` +|graphics/gdk-pixbuf +|Графическая библиотека для GTK+ + +|`glib12` +|devel/glib12 +|Библиотека ядра glib 1.2 + +|`gnomedocutils` +|textproc/gnome-doc-utils +|Утилиты документации GNOME + +|`gnomemimedata` +|misc/gnome-mime-data +|База данных MIME и приложений для GNOME 2 + +|`gnomesharp20` +|x11-toolkits/gnome-sharp20 +|Интерфейсы GNOME 2 для среды выполнения .NET + +|`gnomespeech` +|accessibility/gnome-speech +|GNOME 2 API преобразования текста в речь + +|`gnomevfs2` +|devel/gnome-vfs +|Виртуальная файловая система GNOME 2 + +|`gtk12` +|x11-toolkits/gtk12 +|Набор инструментов Gtk+ 1.2 + +|`gtkhtml3` +|www/gtkhtml3 +|Облегченный движок для отображения/печати/редактирования HTML + +|`gtkhtml4` +|www/gtkhtml4 +|Облегченный движок для отображения/печати/редактирования HTML + +|`gtksharp20` +|x11-toolkits/gtk-sharp20 +|Интерфейсы GTK+ и GNOME 2 для среды выполнения .NET + +|`gtksourceview` +|x11-toolkits/gtksourceview +|Виджет, добавляющий подсветку синтаксиса в GtkTextView + +|`libartgpl2` +|graphics/libart_lgpl +|Библиотека для высокопроизводительной 2D графики + +|`libbonobo` +|devel/libbonobo +|Система компонентов и составных документов для GNOME 2 + +|`libbonoboui` +|x11-toolkits/libbonoboui +|Интерфейс для libbonobo в GNOME 2 + +|`libgda4` +|databases/libgda4 +|Обеспечивает единообразный доступ к различным типам источников данных + +|`libglade2` +|devel/libglade2 +|Библиотека glade для GNOME 2 + +|`libgnome` +|x11/libgnome +|Библиотеки для GNOME 2, GNU окружения рабочего стола + +|`libgnomecanvas` +|graphics/libgnomecanvas +|Графическая библиотека для GNOME 2 + +|`libgnomekbd` +|x11/libgnomekbd +|Динамическая библиотека клавиатуры GNOME 2 + +|`libgnomeprint` +|print/libgnomeprint +|Библиотека поддержки печати Gnome 2 + +|`libgnomeprintui` +|x11-toolkits/libgnomeprintui +|Библиотека поддержки печати Gnome 2 + +|`libgnomeui` +|x11-toolkits/libgnomeui +|Библиотеки для графического интерфейса GNOME 2, среды рабочего стола GNU + +|`libgtkhtml` +|www/libgtkhtml +|Облегченный движок для отображения/печати/редактирования HTML + +|`libgtksourceviewmm` +|x11-toolkits/libgtksourceviewmm +|C++ интерфейс GtkSourceView + +|`libidl` +|devel/libIDL +|Библиотека для создания деревьев файлов CORBA IDL + +|`libsigc++12` +|devel/libsigc++12 +|Фреймворк обратных вызовов для C++ + +|`libwnck` +|x11-toolkits/libwnck +|Библиотека, используемая для написания пейджеров и списков задач -|`QT_PLUGINDIRC` -|Устанавливает путь к плагинам Qt 4 (переменная только для чтения). +|`libwnck3` +|x11-toolkits/libwnck3 +|Библиотека, используемая для написания пейджеров и списков задач + +|`orbit2` +|devel/ORBit2 +|Высокопроизводительный CORBA ORB с поддержкой языка C + +|`pygnome2` +|x11-toolkits/py-gnome2 +|Интерфейс Python для GNOME 2 + +|`pygobject` +|devel/py-gobject +|Python 2, интерфейс GObject 2.0 + +|`pygtk2` +|x11-toolkits/py-gtk2 +|Набор интерфейсов Python для GTK+ + +|`pygtksourceview` +|x11-toolkits/py-gtksourceview +|Интерфейс Python для GtkSourceView 2 + +|`vte` +|x11-toolkits/vte +|Виджет терминала с улучшенной поддержкой доступности и интернационализации (I18N) |=== -При заданной переменной `USE_QT4` применяются следующие настройки: +[[gnome-components-deprecated]] +.Устаревшие компоненты: не использовать +[cols="1,1", options="header"] +|=== +| Компонент +| Описание -[.programlisting] -.... -CONFIGURE_ARGS+= --with-qt-includes=${QT_INCDIR} \ - --with-qt-libraries=${QT_LIBDIR} \ - --with-extra-libs=${LOCALBASE}/lib \ - --with-extra-includes=${LOCALBASE}/include -CONFIGURE_ENV+= MOC="${MOC}" UIC="${UIC}" LIBS="${QTCFGLIBS}" \ - QMAKE="${QMAKE}" QMAKESPEC="${QMAKESPEC}" QTDIR="${QT_PREFIX}" -MAKE_ENV+= QMAKESPEC="${QMAKESPEC}" +|`pangox-compat` +|pangox-compat устарел и был отделён от пакета pango. +|=== -PLIST_SUB+= QT_INCDIR_REL=${QT_INCDIR_REL} \ - QT_LIBDIR_REL=${QT_LIBDIR_REL} \ - QT_PLUGINDIR_REL=${QT_PLUGINDIR_REL} -.... +[[using-qt]] +== Использование Qt + +[NOTE] +==== +Для портов, которые являются частью самого Qt, см. crossref:uses[uses-qt-dist,`qt-dist`]. +==== + +[[qt-common]] +=== Порты, требующие Qt + +Коллекция портов поддерживает Qt 5 и Qt 6 с помощью `USES+=qt:5` и `USES+=qt:6` соответственно. Установите `USE_QT` в список необходимых компонентов Qt (libraries, tools, plugins - библиотеки, инструменты, плагины). + +Фреймворк Qt экспортирует ряд переменных, которые могут использоваться портами, некоторые из них перечислены ниже: + +[[using-qt-variables]] +.Переменные, предоставляемые портам, использующим Qt +[cols="1,1", frame="none"] +|=== +|`QMAKE` +|Полный путь к исполняемому файлу `qmake`. + +|`LRELEASE` +|Полный путь к утилите `lrelease`. + +|`MOC` +|Полный путь к `moc`. + +|`RCC` +|Полный путь к `rcc`. + +|`UIC` +|Полный путь к `uic`. + +|`QT_INCDIR` +|Каталог включаемых файлов Qt. + +|`QT_LIBDIR` +|Путь к библиотекам Qt. + +|`QT_PLUGINDIR` +|Путь к плагинам Qt. +|=== -[[qt4-components]] +[[qt-components]] === Выбор компонентов -В переменной `USE_QT4` должны указываться зависимости от отдельных инструментов и библиотек Qt 4. К каждому компоненту можно добавить суффикс, `_build` или `_run`, отражающий, когда должна быть применена зависимость, во время сборки или выполнения, соответственно. Если суффикс отсутствует, зависимость от компонента будет и для времени сборки, и для времени выполнения. Обычно, компоненты библиотек должны указываться без суффиксов, компоненты инструментов - с суффиксом `_build`, а компоненты плагинов - с суффиксом `_run`. Наиболее общие используемые компоненты перечислены ниже (все доступные компоненты перечислены в `_USE_QT4_ALL` в файле [.filename]#/usr/ports/Mk/bsd.qt.mk#): +Отдельные зависимости инструментов и библиотек Qt должны быть указаны в `USE_QT`. Каждый компонент может иметь суффикс `_build` или `_run`, указывающий, требуется ли компонент во время сборки или выполнения. Если суффикс отсутствует, компонент будет требоваться как во время сборки, так и во время выполнения. Обычно компоненты библиотек указываются без суффикса, компоненты инструментов чаще всего указываются с суффиксом `_build`, а компоненты плагинов — с суффиксом `_run`. Наиболее часто используемые компоненты перечислены ниже (все доступные компоненты перечислены в `_USE_QT_ALL`, которая формируется из `_USE_QT_COMMON` и `_USE_QT[56]_ONLY` в [.filename]#/usr/ports/Mk/Uses/qt.mk#): -.Доступные библиотечные компоненты Qt 4 +[[using-qt-library-list]] +.Доступные компоненты библиотеки Qt [cols="1,1", frame="none", options="header"] |=== -| Название +| Имя | Описание -|`corelib` -|основная библиотека (можно опустить, если порт не использует ничего, кроме `corelib`) +|`3d` +|Модуль Qt3D + +|`5compat` +|Модуль совместимости Qt 5 для Qt 6 + +|`assistant` +|Браузер документации Qt 5 + +|`base` +|Модуль Qt 6 base + +|`canvas3d` +|Модуль Qt canvas3d + +|`charts` +|Модуль Qt 5 charts + +|`concurrent` +|Модуль многопоточности Qt + +|`connectivity` +|Модуль Qt для подключения (Bluetooth/NFC) + +|`core` +|Ядро Qt, неграфический модуль + +|`datavis3d` +|Модуль визуализации 3D данных Qt 5 + +|`dbus` +|Модуль межпроцессного взаимодействия Qt D-Bus + +|`declarative` +|Декларативный фреймворк Qt для динамических пользовательских интерфейсов + +|`designer` +|Интерфейсный конструктор Qt 5 для графического пользовательского интерфейса + +|`diag` +|Инструмент для сбора диагностической информации о Qt и его окружении + +|`doc` +|Документация Qt 5 + +|`examples` +|Исходный код примеров Qt 5 + +|`gamepad` +|Модуль Qt 5 Gamepad + +|`graphicaleffects` +|Графические эффекты Qt Quick |`gui` -|библиотека графического пользовательского интерфейса +|Модуль графического интерфейса Qt + +|`help` +|Модуль интеграции справки Qt в режиме онлайн + +|`l10n` +|Локализованные сообщения Qt + +|`languageserver` +|Реализация протокола Language Server Protocol в Qt 6 + +|`linguist` +|Инструмент перевода Qt 5 + +|`location` +|Модуль Qt Location + +|`lottie` +|Qt 6 QML API для отрисовки графики и анимаций + +|`multimedia` +|Модуль поддержки аудио, видео, радио и камеры Qt |`network` -|сетевая библиотека +|Сетевой модуль Qt + +|`networkauth` +|Модуль сетевой аутентификации Qt |`opengl` -|библиотека OpenGL +|Модуль поддержки OpenGL, совместимый с Qt 5 + +|`paths` +|Клиент командной строки для QStandardPaths + +|`phonon4` +|Мультимедийный фреймворк KDE + +|`pixeltool` +|Увеличитель экрана Qt 5 + +|`plugininfo` +|Дампер метаданных плагинов Qt 5 + +|`positioning` +|Qt 6 API позиционирования из источников, таких как спутники, Wi-Fi или текстовые файлы. + +|`printsupport` +|Модуль поддержки печати Qt + +|`qdbus` +|Интерфейс командной строки Qt для D-Bus + +|`qdbusviewer` +|Графический интерфейс Qt 5 для D-Bus + +|`qdoc` +|Генератор документации Qt -|`qt3support` -|библиотека совместимости с Qt 3 +|`qdoc-data` +|Файлы конфигурации QDoc -|`qtestlib` -|библиотека модульного тестирования +|`qev` +|Инструмент для интроспекции событий Qt QWidget + +|`qmake` +|Генератор Makefile Qt + +|`quickcontrols` +|Набор элементов управления для создания полных интерфейсов в Qt Quick + +|`quickcontrols2` +|Набор элементов управления для создания полных интерфейсов в Qt Quick + +|`remoteobjects` +|Модуль Qt 5 SXCML |`script` -|библиотека сценариев +|Совместимый с Qt 4 модуль для написания сценариев + +|`scripttools` +|Дополнительные компоненты Qt Script + +|`scxml` +|Модуль Qt 5 SXCML + +|`sensors` +|Модуль Qt sensors + +|`serialbus` +|Функции Qt для доступа к промышленным шинным системам + +|`serialport` +|Функции Qt для доступа к последовательным портам + +|`shadertools` +|Инструменты Qt 6 для кроссплатформенного конвейера шейдеров Qt + +|`speech` +|Доступность в Qt5 |`sql` -|библиотека SQL +|Модуль интеграции с базой данных Qt SQL + +|`sql-ibase` +|Плагин Qt баз данных InterBase/Firebird + +|`sql-mysql` +|Плагин Qt базы данных MySQL + +|`sql-odbc` +|Плагин Qt ODBC + +|`sql-pgsql` +|Плагин Qt базы данных PostgreSQL + +|`sql-sqlite2` +|Плагин Qt базы данных SQLite 2 + +|`sql-sqlite3` +|Плагин Qt базы данных SQLite 3 + +|`sql-tds` +|Плагин Qt для подключение к базам данных по протоколу TDS + +|`svg` +|Модуль поддержки SVG в Qt + +|`testlib` +|Модуль тестирования Qt + +|`tools` +|Различные инструменты Qt 6 + +|`translations` +|Модуль перевода Qt 6 + +|`uiplugin` +|Интерфейс плагина пользовательского виджета Qt для Qt Designer + +|`uitools` +|Модуль поддержки форм пользовательского интерфейса Qt Designer + +|`virtualkeyboard` +|Модуль виртуальной клавиатуры Qt 5 + +|`wayland` +|Оболочка Qt 5 для Wayland + +|`webchannel` +|Библиотека Qt 5 для интеграции C++/QML с клиентами на HTML/js + +|`webengine` +|Библиотека Qt 5 для отображения веб-содержимого + +|`webkit` +|QtWebKit с более современной кодовой базой WebKit + +|`websockets` +|Реализация протокола WebSocket на Qt + +|`websockets-qml` +|Реализация протокола WebSocket на Qt (привязки QML) + +|`webview` +|Компонент Qt для отображения веб-содержимого + +|`widgets` +|Модуль виджетов Qt C++ + +|`x11extras` +|Платформо-специфичные возможности Qt для систем на основе X11 |`xml` -|библиотека XML +|Реализации SAX и DOM в Qt + +|`xmlpatterns` +|Поддержка Qt для XPath, XQuery, XSLT и XML Schema |=== -Вы можете определить, от каких библиотек зависит приложение, запустив `ldd` на основной исполняемый файл после успешной компиляции. +Чтобы определить библиотеки, от которых зависит приложение, выполните `ldd` для основного исполняемого файла после успешной компиляции. -.Доступные компоненты инструментов Qt 4 +[[using-qt-tools-list]] +.Доступные компоненты инструментов Qt [cols="1,1", frame="none", options="header"] |=== -| Название +| Имя | Описание -|`moc` -|мета-объектный компилятор (нужен при построении почти для каждого приложения Qt) - -|`qmake` -|генератор Makefile / утилита построения +|`buildtools` +|инструменты сборки (`moc`, `rcc`), необходимые практически для любого приложения Qt. -|`rcc` -|компилятор ресурсов (нужен, если приложение идет вместе с файлами [.filename]#*.rc# или [.filename]#*.qrc#) +|`linguisttools` +|инструменты локализации: `lrelease`, `lupdate` -|`uic` -|компилятор пользовательского интерфейса (нужен, если приложение идет вместе с файлами [.filename]#*.ui#, созданными при помощи Qt Designer, - на практике каждое приложение Qt с GUI) +|`qmake` +|Генератор Makefile/утилита сборки |=== -.Доступные компоненты плагинов Qt 4 +[[using-qt-plugins-list]] +.Доступные компоненты плагинов Qt [cols="1,1", frame="none", options="header"] |=== -| Название +| Имя | Описание -|`iconengines` -|плагин для движка иконок SVG (если приложение поставляется с иконками SVG) - |`imageformats` -|плагины для графических форматов GIF, JPEG, MNG и SVG (если приложение поставляется с графическими файлами) +|плагины для графических форматов TGA, TIFF и MNG |=== -[[qt4-components-example]] -.Выбор компонентов Qt 4 +[[qt5-components-example]] +.Выбор компонентов Qt 5 [example] ==== -В этом примере портированное приложение использует библиотеку графического пользовательского интерфейса Qt 4, основную библиотеку Qt 4, все инструменты генерации кода Qt 4 и генератор Makefile Qt 4. Поскольку библиотека `gui` подразумевает зависимость от основной библиотеки, указывать `corelib` нет необходимости. Инструменты генерации кода Qt 4 `moc`, `uic` и `rcc`, а также генератор Makefile `qmake` нужны только для времени построения, поэтому они указаны с суффиксом `_build`: +В этом примере портированное приложение использует библиотеку графического интерфейса Qt 5, основную библиотеку Qt 5, все инструменты генерации кода Qt 5 и генератор Makefile Qt 5. Поскольку библиотека `gui` подразумевает зависимость от основной библиотеки, `core` не нужно указывать. Инструменты генерации кода Qt 5 `moc`, `uic` и `rcc`, а также генератор Makefile `qmake` требуются только во время сборки, поэтому они указаны с суффиксом `_build`: [.programlisting] .... -USE_QT4= gui moc_build qmake_build rcc_build uic_build +USES= qt:5 +USE_QT= gui buildtools_build qmake_build .... ==== @@ -829,81 +2238,444 @@ USE_QT4= gui moc_build qmake_build rcc_build uic_build [[using-qmake]] === Использование `qmake` +Если приложение предоставляет файл проекта qmake ([.filename]#*.pro#), определите `USES= qmake` вместе с `USE_QT`. `USES= qmake` уже подразумевает зависимость сборки от qmake, поэтому компонент qmake может быть опущен в `USE_QT`. Подобно crossref:special[using-cmake,CMake], qmake поддерживает сборку вне исходного дерева, которую можно включить, указав аргумент `outsource` (см. crossref:special[using-qmake-example,пример `USES= qmake`]). Также см. crossref:special[using-qmake-arguments,Возможные аргументы для `USES qmake`]. + +[[using-qmake-arguments]] +.Возможные аргументы для `USES= qmake` +[cols="1,1", frame="none", options="header"] +|=== +| Переменная +| Описание + +|`no_configure` +|Не добавлять цель configure. Это подразумевается при `HAS_CONFIGURE=yes` и `GNU_CONFIGURE=yes`. Это требуется, когда сборке нужна только настройка окружения из `USES= qmake`, но в остальном она запускает `qmake` самостоятельно. + +|`no_env` +|Подавить модификацию окружения configure и make. Это требуется только когда `qmake` используется для настройки программного обеспечения и сборка не понимает окружение, установленное `USES= qmake`. + +|`norecursive` +|Не передавать аргумент `-recursive` в `qmake`. + +|`outsource` +|Выполнить сборку вне исходного кода. +|=== + +[[using-qmake-variables]] .Переменные для портов, использующих `qmake` [cols="1,1", frame="none", options="header"] |=== -| Название +| Переменная | Описание |`QMAKE_ARGS` -|Спефицичные для порта флаги QMake для передачи программе `qmake`. +|Специфичные для порта флаги qmake, передаваемые в бинарный файл `qmake`. |`QMAKE_ENV` -|Переменные окружения, устанавливаемые для программы `qmake`. По умолчанию соответствует значению `${CONFIGURE_ENV}`. +|Переменные окружения, которые должны быть установлены для бинарного файла `qmake`. По умолчанию используется `${CONFIGURE_ENV}`. -|`QMAKE_PRO` -|Название файла проекта [.filename]#.pro#. По умолчанию имеет пустое значение (с использованием автоопределения). +|`QMAKE_SOURCE_PATH` +|Путь к файлам проекта qmake ([.filename]#.pro#). По умолчанию используется `${WRKSRC}`, если запрошена сборка вне исходного кода, в противном случае оставляется пустым. |=== -Если вместе с приложением вместо [.filename]#configure# поставляется файл [.filename]#.pro#, вы можете использовать следующее: +При использовании `USES= qmake` применяются следующие настройки: [.programlisting] .... -USES= qmake -USE_QT4= qmake_build +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`. + +[[using-qmake-example]] +.Пример `USES= qmake` +[example] +==== +Этот фрагмент демонстрирует использование qmake для порта Qt 5: + +[.programlisting] +.... +USES= qmake:outsource qt:5 +USE_QT= buildtools_build .... -`USES=qmake` указывает порту на использование `qmake` в процессе конфигурации. Обратите внимание, что `USES=qmake` не подразумевает зависимость от Qt 4 `qmake`. Для этого в значении `USE_QT4` должен присутствовать компонент `qmake_build`. +==== -Приложения Qt часто пишутся в кроссплатформенной манере, и X11/Unix часто не является для них платформой разработки, что в свою очередь часто приводит к соответствующим упущенным моментам: +Приложения Qt часто разрабатываются как кроссплатформенные, и зачастую X11/Unix — не та платформа, на которой они создаются. Это, в свою очередь, приводит к определённым недоработкам, таким как: -* _Отсутствующие дополнительные пути для заголовочных файлов._ Многие приложения идут с поддержкой иконки в системном трее, но пренебрегают смотреть на наличие заголовочных файлов и/или библиотеками в каталогах X11. Вы можете сообщить `qmake`, чтобы она добавила каталоги в пути поиска заголовочных файлов и библиотек через командную строку. К примеру: +* _Отсутствуют дополнительные пути для заголовочных файлов._ Многие приложения поддерживают значки в системном трее, но не учитывают пути для заголовочных файлов и/или библиотек в каталогах X11. Чтобы добавить каталоги в пути поиска заголовочных файлов и библиотек для `qmake` через командную строку, используйте: + [.programlisting] .... -QMAKE_ARGS+= INCLUDEPATH+=${LOCALBASE}/include \ - LIBS+=-L${LOCALBASE}/lib +QMAKE_ARGS+= INCLUDEPATH+=${LOCALBASE}/include \ + LIBS+=-L${LOCALBASE}/lib .... -* _Фиктивные пути установки._ Иногда данные, такие как иконки и файлы .desktop, устанавливаются по умолчанию в каталоги, которые не просматриваются XDG-совместимыми приложениями. Примером является package:editors/texmaker[] - взгляните на [.filename]#patch-texmaker.pro# из каталога [.filename]#files# этого порта, который можно взять в качестве шаблона исправления этого непосредственно в файле проекта `qmake`. +* _Некорректные пути установки._ Иногда данные, такие как иконки или файлы .desktop, по умолчанию устанавливаются в каталоги, которые не сканируются приложениями, совместимыми с XDG. Например, package:editors/texmaker[] — посмотрите на файл [.filename]#patch-texmaker.pro# в директории [.filename]#files# этого порта, чтобы увидеть шаблон исправления этой проблемы напрямую в проектом файле `qmake`. [[using-kde]] == Использование KDE -[[kde4-variables]] -=== Задание переменных KDE 4 +[[kde5-variables]] +=== Определения переменных KDE -Если ваше приложение зависит от KDE 4.x, присвойте `USE_KDE4` список требуемых компонентов. Для переопределения типа зависимости компонента могут быть использованы суффиксы `_build` и `_run` (например, `baseapps_run`). Если суффикс не задан, будет использован тип зависимости по умолчанию. Если вы хотите использовать оба типа, добавьте компонент дважды с обоими суффиксами (например, `automoc4_build automoc4_run`). Основные наиболее используемые компоненты перечислены ниже (актуальные компоненты задокументированы в начале файла [.filename]#/usr/ports/Mk/bsd.kde4.mk#): +Если приложение зависит от KDE, установите `USES+=kde:5` и `USE_KDE` в список необходимых компонентов. Суффиксы `_build` и `_run` можно использовать для принудительного указания типа зависимости компонентов (например, `baseapps_run`). Если суффикс не задан, будет использован тип зависимости по умолчанию. Чтобы принудительно задать оба типа, добавьте компонент дважды с обоими суффиксами (например, `ecm_build ecm_run`). Доступные компоненты перечислены ниже (актуальный список компонентов также приведён в [.filename]#/usr/ports/Mk/Uses/kde.mk#): -.Доступные компоненты KDE 4 +[[using-kde-components]] +.Доступные компоненты KDE [cols="1,1", frame="none", options="header"] |=== -| Название +| Имя | Описание -|`kdehier` -|Иерархия основных каталогов KDE +|`activities` +|Среда выполнения и библиотека KF5 для организации работы в отдельных автивностях -|`kdelibs` -|KDE Developer Platform +|`activities-stats` +|KF5 статистика для активностей -|`kdeprefix` -|Если установлено, то порт будет установлен в `${KDE4_PREFIX}` вместо `${LOCALBASE}` +|`activitymanagerd` +|Системный сервис для управления активностью пользователей, отслеживания шаблонов использования -|`sharedmime` -|База данных MIME типов для портов KDE +|`akonadi` +|Хранилище данных для KDE-Pim -|`automoc4` -|automoc для пакетов Qt 4 +|`akonadicalendar` +|Интеграция Akonadi с Календарем -|`akonadi` -|Сервер хранения KDE-Pim +|`akonadiconsole` +|Консоль управления и отладки Akonadi + +|`akonadicontacts` +|Библиотеки и демоны для реализации управления контактами в Akonadi + +|`akonadiimportwizard` +|Импорт данных из других почтовых клиентов в KMail + +|`akonadimime` +|Библиотеки и демоны для реализации базовой обработки электронной почты + +|`akonadinotes` +|Библиотека KDE для доступа к хранилищам почты в формате MBox + +|`akonadisearch` +|Библиотеки и демоны для реализации поиска в Akonadi + +|`akregator` +|Читатель лент от KDE + +|`alarmcalendar` +|KDE API для будильников KAlarm + +|`apidox` +|Документация API KF5 + +|`archive` +|Библиотека KF5, предоставляющая классы для работы с форматами архивов + +|`attica` +|Библиотека API Open Collaboration Services, версия для KDE5 + +|`attica5` +|Библиотека API Open Collaboration Services, версия для KDE5 + +|`auth` +|Абстракция KF5 для системной политики и функций аутентификации + +|`baloo` +|KF5 Фреймворк для поиска и управления пользовательскими метаданными + +|`baloo-widgets` +|Библиотека BalooWidgets + +|`baloo5` +|KF5 Фреймворк для поиска и управления пользовательскими метаданными + +|`blog` +|KDE API для доступа к веб-логам + +|`bookmarks` +|Библиотека KF5 для закладок и формата XBEL + +|`breeze` +|Plasma5 artwork, стили и ресурсы для визуального стиля Breeze + +|`breeze-gtk` +|Plasma5 Breeze визуальный стиль для Gtk + +|`breeze-icons` +|Тема значков Breeze для KDE + +|`calendarcore` +|Библиотека доступа к календарю KDE + +|`calendarsupport` +|Библиотеки поддержки календарей для KDEPim + +|`calendarutils` +|Утилита KDE и пользовательские функции интерфейса для доступа к календарю + +|`codecs` +|Библиотека KF5 для работы со строками + +|`completion` +|KF5 вспомогательные средства и виджеты автодополнения текста + +|`config` +|Виджеты KF5 для диалогов настройки + +|`configwidgets` +|Виджеты KF5 для диалогов настройки + +|`contacts` +|KDE API для управления контактной информацией + +|`coreaddons` +|KF5 аддоны для QtCore + +|`crash` +|Библиотека KF5 для обработки анализа сбоев и отчётов об ошибках в приложениях + +|`dbusaddons` +|KF5 дополнения к QtDBus + +|`decoration` +|Библиотека Plasma5 для создания оформления окон + +|`designerplugin` +|Интеграция KF5 виджетов Frameworks в Qt Designer/Creator + +|`discover` +|Инструменты управления пакетами Plasma5 + +|`dnssd` +|Абстракция KF5 для системных функций DNSSD + +|`doctools` +|Генерация документации KF5 из docbook + +|`drkonqi` +|Обработчик сбоев Plasma5 + +|`ecm` +|Дополнительные модули и скрипты для CMake + +|`emoticons` +|Библиотека KF5 для преобразования эмотиконов + +|`eventviews` +|Библиотеки просмотра событий для KDEPim + +|`filemetadata` +|Библиотека KF5 для извлечения метаданных файлов + +|`frameworkintegration` +|Плагины рабочего пространства KF5 и интеграции фреймворков + +|`gapi` +|Библиотека на основе KDE для доступа к сервисам Google + +|`globalaccel` +|Библиотека KF5 для добавления поддержки глобальных сочетаний клавиш рабочего пространства + +|`grantlee-editor` +|Редактор тем Grantlee + +|`grantleetheme` +|KDE PIM grantleetheme -|`soprano` -|Фреймворк Qt 4 RDF +|`gravatar` +|Библиотека для поддержки gravatar -|`strigi` -|Поисковые даемон рабочего стола +|`guiaddons` +|KF5 аддоны для QtGui + +|`holidays` +|Библиотека KDE для календарных праздников + +|`hotkeys` +|Библиотека Plasma5 для горячих клавиш + +|`i18n` +|KF5 — расширенная инфраструктура интернационализации + +|`iconthemes` +|Библиотека KF5 для работы с иконками в приложениях + +|`identitymanagement` +|KDE pim идентификации + +|`idletime` +|Библиотека KF5 для мониторинга активности пользователей + +|`imap` +|KDE API для поддержки IMAP + +|`incidenceeditor` +|Инцидентные редакторские библиотеки для KDEPim + +|`infocenter` +|Утилита Plasma5, предоставляющая системную информацию + +|`init` +|Запускатель процессов KF5 для ускорения запуска приложений KDE + +|`itemmodels` +|Модели KF5 для системы Qt Model/View + +|`itemviews` +|KF5 виджеты-дополнения для Qt Model/View + +|`jobwidgets` +|Виджеты KF5 для отслеживания экземпляра KJob + +|`js` +|Библиотека KF5, предоставляющая интерпретатор ECMAScript + +|`jsembed` +|Библиотека KF5 для привязки объектов JavaScript к QObjects + +|`kaddressbook` +|Менеджер контактов KDE + +|`kalarm` +|Планировщик персональных сигналов тревоги + +|`kalarm` +|Планировщик персональных сигналов тревоги + +|`kate` +|Базовая структура редактора для системы KDE + +|`kcmutils` +|KF5 утилиты для работы с KCModules + +|`kde-cli-tools` +|Неинтерактивные системные инструменты Plasma5 + +|`kde-gtk-config` +|Plasma5 конфигуратор GTK2 и GTK3 + +|`kdeclarative` +|Библиотека KF5, обеспечивающая интеграцию QML и KDE Frameworks + +|`kded` +|KF5 расширяемый демон для предоставления системных сервисов + +|`kdelibs4support` +|Помощник в портировании KF5 из KDELibs4 + +|`kdepim-addons` +|Дополнения KDE PIM + +|`kdepim-apps-libs` +|Библиотеки KDE PIM, связанные с почтой + +|`kdepim-runtime5` +|Инструменты и службы KDE PIM + +|`kdeplasma-addons` +|Дополнения Plasma5 для улучшения работы с Plasma + +|`kdesu` +|Интеграция KF5 с su для повышенных привилегий + +|`kdewebkit` +|Библиотека KF5, обеспечивающая интеграцию QtWebKit + +|`kgamma5` +|Настройки гаммы монитора Plasma5 + +|`khtml` +|Механизм рендеринга KF5 KTHML + +|`kimageformats` +|Библиотека KF5, обеспечивающая поддержку дополнительных форматов изображений + +|`kio` +|Абстракция ресурсов и сетевого доступа KF5 + +|`kirigami2` +|Набор компонентов на основе QtQuick + +|`kitinerary` +|Модель данных и система извлечения информации о бронировании путешествий + +|`kmail` +|Клиент электронной почты KDE + +|`kmail` +|Клиент электронной почты KDE + +|`kmail-account-wizard` +|Мастер настройки почтового аккаунта KDE + +|`kmenuedit` +|Редактор меню Plasma5 + +|`knotes` +|Всплывающие примечания + +|`kontact` +|KDE Персональный Органайзер + +|`kontact` +|KDE Персональный Органайзер + +|`kontactinterface` +|KDE glue для встраивания KParts в Kontact + +|`korganizer` +|Программа для календаря и планирования + +|`kpimdav` +|Реализация протокола DAV с KJobs + +|`kpkpass` +|Библиотека для работы с файлами паролей Apple Wallet + +|`kross` +|KF5 мультиязыковые прикладные скрипты + +|`kscreen` +|Библиотека управления экраном Plasma5 + +|`kscreenlocker` +|Архитектура безопасной блокировки экрана Plasma5 + +|`ksmtp` +|Библиотека на основе задач для отправки электронной почты через SMTP-сервер + +|`ksshaskpass` +|Plasma5 интерфейс для ssh-add + +|`ksysguard` +|Утилита Plasma5 для отслеживания и управления запущенными процессами + +|`kwallet-pam` +|Интеграция Plasma5 KWallet с PAM + +|`kwayland-integration` +|Интеграционные плагины для рабочего стола на основе Wayland + +|`kwin` +|Менеджер окон Plasma5 + +|`kwrited` +|Демон Plasma5, ожидающий сообщения wall и write + +|`ldap` +|API доступа к LDAP для KDE |`libkcddb` |Библиотека KDE CDDB @@ -911,65 +2683,259 @@ QMAKE_ARGS+= INCLUDEPATH+=${LOCALBASE}/include \ |`libkcompactdisc` |Библиотека KDE для взаимодействия с аудио-CD -|`libkdeedu` -|Библиотеки, используемые для образовательных приложений - |`libkdcraw` -|Библиотека KDE LibRaw +|Интерфейс LibRaw для KDE + +|`libkdegames` +|Библиотеки, используемые играми KDE + +|`libkdepim` +|Библиотеки KDE PIM + +|`libkeduvocdocument` +|Библиотека для чтения и записи файлов словарей |`libkexiv2` -|Библиотека KDE Exiv2 +|Интерфейс библиотеки Exiv2 для KDE |`libkipi` -| KDE Image Plugin Interface +|Интерфейс плагинов изображений KDE -|`libkonq` -|Основная библиотека Konqueror +|`libkleo` +|Менеджер сертификатов для KDE |`libksane` -|Библиотека KDE SANE ("Scanner Access Now Easy") +|Интерфейс библиотеки SANE для KDE -|`pimlibs` -|Библиотеки KDE-Pim +|`libkscreen` +|Библиотека управления экраном Plasma5 -|`kate` -|Тектовый редактор +|`libksieve` +|Библиотеки Sieve для KDEPim + +|`libksysguard` +|Библиотека Plasma5 для отслеживания и управления запущенными процессами + +|`mailcommon` +|Общие библиотеки для KDEPim + +|`mailimporter` +|Импорт файлов mbox в KMail + +|`mailtransport` +|Библиотека KDE для управления транспортом почты |`marble` -|Виртуальный глобус +|Виртуальный глобус и мировой атлас для KDE + +|`mbox` +|Библиотека KDE для доступа к хранилищам почты в формате MBox + +|`mbox-importer` +|Импорт файлов mbox в KMail + +|`mediaplayer` +|Интерфейс плагина KF5 для функций медиаплеера + +|`messagelib` +|Библиотека для обработки сообщений + +|`milou` +|Plasma5 Plasmoid для поиска + +|`mime` +|Библиотека для обработки данных MIME + +|`newstuff` +|Библиотека KF5 для загрузки ресурсов приложений из сети + +|`notifications` +|Абстракция KF5 для системных уведомлений + +|`notifyconfig` +|Система конфигурации KF5 для KNotify |`okular` -|Универсальный просмотрщик документов +|Универсальная программа для просмотра документов KDE + +|`oxygen` +|Стиль Plasma5 Oxygen + +|`oxygen-icons5` +|Тема иконок Oxygen для KDE + +|`package` +|Библиотека KF5 для загрузки и установки пакетов + +|`parts` +|KF5 система плагинов для работы с документами + +|`people` +|Библиотека KF5, предоставляющая доступ к контактам + +|`pim-data-exporter` +|Импорт и экспорт настроек KDE PIM + +|`pimcommon` +|Общие библиотеки для KDEPim + +|`pimtextedit` +|Библиотека KDE для утилит редактирования текста, специфичных для PIM + +|`plasma-browser-integration` +|Компоненты Plasma5 для интеграции браузеров в рабочий стол + +|`plasma-desktop` +|Plasma5 рабочий стол Plasma + +|`plasma-framework` +|KF5 - среда выполнения пользовательского интерфейса на основе плагинов, используемая для создания пользовательских интерфейсов + +|`plasma-integration` +|Плагины интеграции Qt Platform Theme для рабочего окружения Plasma + +|`plasma-pa` +|Plasma5 Микшер звука Plasma Pulse + +|`plasma-sdk` +|Приложения Plasma5, полезные для разработки Plasma + +|`plasma-workspace` +|Plasma5 Рабочее пространство Plasma + +|`plasma-workspace-wallpapers` +|Обои Plasma5 + +|`plotting` +|KF5 облегченный фреймворк для построения графиков + +|`polkit-kde-agent-1` +|Демон Plasma5, предоставляющий интерфейс аутентификации polkit + +|`powerdevil` +|Инструмент Plasma5 для управления настройками энергопотребления -|`korundum` -|Привязка Ruby к KDE +|`prison` +|Интерфейс API для создания штрихкодов -|`perlkde` -|Привязка Perl к KDE +|`pty` +|Абстракция pty KF5 -|`pykde4` -|Привязка Python к KDE +|`purpose` +|Предлагает доступные действия для конкретной цели -|`pykdeuic4` -|Компилятор пользовательского интерфейса PyKDE +|`qqc2-desktop-style` +|Стиль Qt QuickControl2 для KDE -|`smokekde` -|Библиотеки KDE SMOKE +|`runner` +|KF5 параллелизованная система запросов + +|`service` +|KF5 расширенные плагины и интроспекция сервисов + +|`solid` +|Интеграция и обнаружение оборудования KF5 + +|`sonnet` +|KF5 библиотека проверки орфографии на основе плагинов + +|`syndication` +|Библиотека KDE для обработки RSS-лент + +|`syntaxhighlighting` +|Движок подсветки синтаксиса KF5 для структурированного текста и кода + +|`systemsettings` +|Настройки системы Plasma5 + +|`texteditor` +|KF5 продвинутый встраиваемый текстовый редактор + +|`textwidgets` +|KF5 расширенные виджеты для редактирования текста + +|`threadweaver` +|KF5 дополнения к QtDBus + +|`tnef` +|KDE API для обработки данных TNEF + +|`unitconversion` +|Библиотека KF5 для преобразования единиц измерения + +|`user-manager` +|Пользовательский менеджер Plasma5 + +|`wallet` +|KF5 безопасный и унифицированный контейнер для паролей пользователей + +|`wayland` +|Обёртка клиентской и серверной библиотек KF5 для библиотек Wayland + +|`widgetsaddons` +|KF5 аддоны для QtWidgets + +|`windowsystem` +|Библиотека KF5 для доступа к оконной системе + +|`xmlgui` +|KF5 настраиваемые пользователем главные окна + +|`xmlrpcclient` +|Взаимодействие KF5 с XMLRPC-сервисами |=== -Порты KDE 4.x устанавливаются в `KDE4_PREFIX`, что в настоящее время соответствует [.filename]#/usr/local/kde4#. Это достигается путем указания компонента `kdeprefix`, который определяет значение по умолчанию для `PREFIX`. Тем не менее, порты учитывают любые `PREFIX`, установленные через переменную окружения `MAKEFLAGS` и/или параметры `make`. +[[kde5-components-example]] +.Пример `USE_KDE` +[example] +==== +Это простой пример порта для KDE. `USES= cmake` указывает порту использовать CMake, инструмент конфигурации, широко применяемый в проектах KDE (см. crossref:special[using-cmake, Использование `cmake`] для подробного описания). `USE_KDE` добавляет зависимость от библиотек KDE. Необходимые компоненты KDE и другие зависимости можно определить через лог конфигурации. `USE_KDE` не подразумевает `USE_QT`. Если порту требуются некоторые компоненты Qt, укажите их в `USE_QT`. + +[.programlisting] +.... +USES= cmake kde:5 qt:5 +USE_KDE= ecm +USE_QT= core buildtools_build qmake_build +.... -[[kde4-components-example]] -.Пример `USE_KDE4` +==== + +[[using-lxqt]] +== Использование LXQt + +Приложения, зависящие от LXQt, должны устанавливать `USES+= lxqt` и задавать `USE_LXQT` списком необходимых компонентов из таблицы ниже + +[[using-lxqt-components]] +.Доступные компоненты LXQt +[cols="1,1", frame="none", options="header"] +|=== +| Имя +| Описание + +|`buildtools` +|Помощники для дополнительных модулей CMake + +|`libfmqt` +|Привязки Libfm к Qt + +|`lxqt` +|Ядро библиотеки LXQt + +|`qtxdg` +|Реализация Qt спецификаций freedesktop.org XDG +|=== + +[[lxqt-components-example]] +.Пример `USE_LXQT` [example] ==== -Это простой пример для порта KDE 4. `USES= cmake:outsource` указывает порту использовать CMake, конфигурационный инструмент, широко применяемый в проектах KDE 4 (подробное описание даёт <<using-cmake>>). `USE_KDE4` добавляет зависимость от библиотек KDE и заставляет порты использовать `automoc4` во время сборки. Требуемые компоненты KDE и другие зависимости можно определить в журнале configure. `USE_KDE4` не подразумевает `USE_QT4`. Если порт требует какой-либо из компонентов Qt 4, их следует указать в `USE_QT4`. +Это простой пример, `USE_LXQT` добавляет зависимость от библиотек LXQt. Необходимые компоненты LXQt и другие зависимости можно определить из лога конфигурации. [.programlisting] .... -USES= cmake:outsource -USE_KDE4= kdelibs kdeprefix automoc4 -USE_QT4= moc_build qmake_build rcc_build uic_build +USES= cmake lxqt qt:5 tar:xz +USE_QT= core dbus widgets buildtools_build qmake_build +USE_LXQT= buildtools libfmqt .... ==== @@ -978,155 +2944,159 @@ USE_QT4= moc_build qmake_build rcc_build uic_build == Использование Java [[java-variables]] -=== Задание переменных +=== Определения переменных -Если вашему порту необходимо наличие Java(TM) Development Kit (JDK(TM)) для построения, работы или даже распаковки дистрибутивного файла, то в нём должна быть задана переменная `USE_JAVA`. +Если порту требуется Java(TM) Development Kit (JDK(TM)) для сборки, запуска или даже извлечения distfile, определите `USE_JAVA`. -В Коллекции Портов присутствуют несколько JDK различных разработчиков и разных версий. Если ваш порт должен использовать одну из этих версий, то вы должны указать, какую именно. Самой последней версией и версией по умолчанию является package:java/openjdk6[]. +В коллекции портов доступно несколько JDK от различных поставщиков и в нескольких версиях. Если порт должен использовать определённую версию, укажите её с помощью переменной `JAVA_VERSION`. Самая актуальная версия — package:java/openjdk18[], также доступны package:java/openjdk17[], package:java/openjdk16[], package:java/openjdk15[], package:java/openjdk14[], package:java/openjdk13[], package:java/openjdk12[], package:java/openjdk11[], package:java/openjdk8[] и package:java/openjdk7[]. -.Переменные, которые которые могут задаваться портами, использующими Java +[[using-java-variables]] +.Переменные, которые могут быть установлены портами, использующими Java [cols="1,1", frame="none", options="header"] |=== | Переменная | Значение |`USE_JAVA` -|Должна быть определена для того, что последующие переменные вступили в действие. +|Определите для остальных переменных, чтобы они имели какой-либо эффект. |`JAVA_VERSION` -|Список версий Java, перечисленных через пробел, подходящих для порта. Опциональный знак `"+"` позволяет вам указать диапазон версий (возможные значения: `1.5[+] 1.6[+] 1.7[+]`). +|Список подходящих версий Java для порта, разделённых пробелами. +Необязательный символ `\+` позволяет указать диапазон версий (допустимые значения: `8[+] 11[\+] 17[+] 18[\+] 19[+] 20[\+] 21[+]`). |`JAVA_OS` -|Список операционных систем, перечисленных через пробел, порты JDK для которых подходят для порта (возможные значения: `native linux`). +|Список разделенных пробелами подходящих операционных систем портов JDK для порта (допустимые значения: `native linux`). |`JAVA_VENDOR` -|Список разработчиков портов JDK, перечисленных через пробел, которые подходят для порта (возможные значения: `freebsd bsdjava sun openjdk`). +|Список подходящих поставщиков портов JDK для порта через пробел (допустимые значения: `openjdk oracle`). |`JAVA_BUILD` -|Если задана, то означает, что выбранный порт JDK должен быть добавлен к зависимостям порта для его построения. +|Когда установлено, добавляет выбранный порт JDK в зависимости сборки. |`JAVA_RUN` -|Если задана, то означает, что выбранный порт JDK должен быть добавлен в зависимостям порта для его работы. +|Когда установлено, добавляет выбранный порт JDK в зависимости времени выполнения. |`JAVA_EXTRACT` -|Если задана, то означает, что выбранный порт JDK должен быть добавлен в зависимостям порта для распаковки его дистрибутивных файлов. +|Когда установлено, добавляет выбранный порт JDK в зависимости для извлечения. |=== -Ниже перечисляются все значения, которые принимают переменные после задания переменной `USE_JAVA`: +Ниже приведен список всех настроек, которые порт получит после установки `USE_JAVA`: -.Переменные, доступные в портах, использующих Java +[[using-java-variables2]] +.Переменные, предоставляемые портам, использующим Java [cols="1,1", frame="none", options="header"] |=== | Переменная | Значение |`JAVA_PORT` -|Название порта JDK (к примеру, `'java/openjdk6'`). +|Имя порта JDK (например, `java/openjdk6`). |`JAVA_PORT_VERSION` -|Полное наименовании версии порта JDK (к примеру, `'1.6.0'`). Если вам нужны только первые две цифры номера версии, используйте `${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/}`. +|Полная версия порта JDK (например, `1.6.0`). Требуются только первые две цифры номера версии, используйте `${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/}`. |`JAVA_PORT_OS` -|Операционная система, используемая портом JDK (к примеру, `'native'`). +|Операционная система, используемая портом JDK (например, `'native'`). |`JAVA_PORT_VENDOR` -|Разработчик порта JDK (к примеру, `'openjdk'`). +|Поставщик порта JDK (например, `'openjdk'`). |`JAVA_PORT_OS_DESCRIPTION` -|Описание операционной системы, используемой портом JDK (к примеру, `'Native'`). +|Описание операционной системы, используемой портом JDK (например, `'Native'`). |`JAVA_PORT_VENDOR_DESCRIPTION` -|Описание разработчика порта JDK (к примеру, `'OpenJDK BSD Porting Team'`). +|Описание поставщика порта JDK (например, `'OpenJDK BSD Porting Team'`). |`JAVA_HOME` -|Маршрут к установочному каталогу JDK (к примеру, [.filename]#'/usr/local/openjdk6'#). +|Путь к каталогу установки JDK (например, [.filename]#'/usr/local/openjdk6'#). |`JAVAC` -|Маршрут к используемому компилятору Java (к примеру, [.filename]#'/usr/local/openjdk6/bin/javac'#. +|Путь к используемому компилятору Java (например, [.filename]#'/usr/local/openjdk6/bin/javac'#). |`JAR` -|Маршрут к используемой утилите `jar` (к примеру, [.filename]#'/usr/local/openjdk6/bin/jar'# или [.filename]#'/usr/local/bin/fastjar'#). +|Путь к инструменту `jar`, который следует использовать (например, [.filename]#'/usr/local/openjdk6/bin/jar'# или [.filename]#'/usr/local/bin/fastjar'#). |`APPLETVIEWER` -|Маршрут к утилите `appletviewer` (к примеру, [.filename]#'/usr/local/openjdk6/bin/appletviewer'#). +|Путь к утилите `appletviewer` (например, [.filename]#'/usr/local/openjdk6/bin/appletviewer'#). |`JAVA` -|Маршрут к выполняемому файлу `java`. Используйте его для запуска Java-программ (к примеру, [.filename]#'/usr/local/openjdk6/bin/java'#). +|Путь к исполняемому файлу `java`. Используется для запуска программ на Java (например, [.filename]#'/usr/local/openjdk6/bin/java'#). |`JAVADOC` -|Маршрут к вспомогательной программе `javadoc`. +|Путь к программе `javadoc`. |`JAVAH` -|Маршрут к программе `javah`. +|Путь к программе `javah`. |`JAVAP` -|Маршрут к программе `javap`. +|Путь к программе `javap`. |`JAVA_KEYTOOL` -|Маршрут к вспомогательной программе `keytool`. +|Путь к утилите `keytool`. |`JAVA_N2A` -|Маршрут к утилите `native2ascii`. +|Путь к инструменту `native2ascii`. |`JAVA_POLICYTOOL` -|Маршрут к программе `policytool`. +|Путь к программе `policytool`. |`JAVA_SERIALVER` -|Маршрут к вспомогательной программе `serialver`. +|Путь к утилите `serialver`. |`RMIC` -|Маршрут к генератору каркаса программ RMI, утилите `rmic`. +|Путь к генератору RMI-заглушек/скелетов, `rmic`. |`RMIREGISTRY` -|Маршрут к программе регистрации RMI, `rmiregistry`. +|Путь к программе реестра RMI, `rmiregistry`. |`RMID` -|Маршрут к программе-даемону RMI `rmid`. +|Путь к программе демона RMI `rmid`. |`JAVA_CLASSES` -|Маршрут к архиву, который содержит файлы классов JDK, [.filename]#${JAVA_HOME}/jre/lib/rt.jar#. +|Путь к архиву, содержащему файлы классов JDK, [.filename]#${JAVA_HOME}/jre/lib/rt.jar#. |=== -Вы можете воспользоваться make-целью `java-debug` для получения информации, необходимой для отладки вашего порта. При её выполнении будут выданы значения многих упомянутых выше переменных. +Используйте цель `java-debug` в make для получения информации для отладки порта. Она отобразит значения многих из перечисленных ранее переменных. -Кроме того, для единообразия установки всех портов Java определены следующие константы: +Кроме того, определены следующие константы, чтобы все порты Java могли быть установлены единообразно: -.Константы, определённые для портов, использующих Java +[[using-java-constants]] +.Константы, определенные для портов, использующих Java [cols="1,1", frame="none", options="header"] |=== | Константа | Значение |`JAVASHAREDIR` -|Корневой каталог для всего, что связано с Java. По умолчанию: [.filename]#${PREFIX}/shared/java#. +|Базовый каталог для всего, связанного с Java. По умолчанию: [.filename]#${PREFIX}/share/java#. |`JAVAJARDIR` -|Каталог, в который должны устанавливаться JAR-файлы. По умолчанию: [.filename]#${JAVASHAREDIR}/classes#. +|Каталог, в котором установлены JAR-файлы. По умолчанию: [.filename]#${JAVASHAREDIR}/classes#. |`JAVALIBDIR` -|Каталог, в который устанавливаются JAR-файлы из других портов. По умолчанию: [.filename]#${LOCALBASE}/shared/java/classes#. +|Каталог, в котором расположены JAR-файлы, установленные другими портами. По умолчанию: [.filename]#${LOCALBASE}/share/java/classes#. |=== -Соответствующие записи определяются в обоих переменных `PLIST_SUB` (описана в crossref:plist[plist-sub,Изменение содержимого pkg-plist в зависимости от make-переменных]) и `SUB_LIST`. +Связанные записи определены как в `PLIST_SUB` (документировано в crossref:plist[plist-sub,Изменение pkg-plist на основе переменных Make]), так и в `SUB_LIST`. [[java-building-with-ant]] -=== Построение с Ant +=== Сборка с Ant -Если построение порта производится с использованием Apache Ant, то необходимо определить `USE_ANT`. Таким образом Ant становится подкомандой make. Если в порте не определена цель `do-build`, то будет установлена цель по умолчанию, которая просто запускает Ant в соответствии со значением `MAKE_ENV`, `MAKE_ARGS` и `ALL_TARGET`. Это похоже на механизм `USES= gmake`, который описан в <<building>>. +Когда порт должен собираться с использованием Apache Ant, он должен определять `USE_ANT`. Таким образом, Ant считается командой sub-make. Если цель `do-build` не определена в порте, будет установлена цель по умолчанию, которая запускает Ant в соответствии с `MAKE_ENV`, `MAKE_ARGS` и `ALL_TARGET`. Это аналогично механизму `USES= gmake`, который документирован в crossref:special[building, Building Mechanisms]. [[java-best-practices]] -=== Практические рекомендации +=== Лучшие практики -При портировании Java-библиотеки ваш порт должен устанавливать JAR-файл(ы) в каталог [.filename]#${JAVAJARDIR}#, а все остальные данные в каталог [.filename]#${JAVASHAREDIR}/${PORTNAME}# (за исключением документации, о которой пойдёт речь ниже). Для уменьшения размера упакованного файла вы можете сослаться на JAR-файл(ы) непосредственно в файле [.filename]#Makefile#. Просто воспользуйтесь следующей директивой (в которой [.filename]#myport.jar# является именем JAR-файла, устанавливаемого как часть порта): +При переносе библиотеки Java порт должен устанавливать JAR-файл(ы) в [.filename]#${JAVAJARDIR}#, а все остальное — в [.filename]#${JAVASHAREDIR}/${PORTNAME}# (за исключением документации, см. ниже). Чтобы уменьшить размер упаковочного файла, ссылайтесь на JAR-файл(ы) напрямую в [.filename]#Makefile#. Используйте следующую инструкцию (где [.filename]#myport.jar# — имя JAR-файла, устанавливаемого как часть порта): [.programlisting] .... -PLIST_FILES+= %%JAVAJARDIR%%/myport.jar +PLIST_FILES+= ${JAVAJARDIR}/myport.jar .... -При портировании Java-приложения порт обычно устанавливает всё в один каталог (в том числе все свои JAR-зависимости). В этом отношении настоятельно рекомендуется использование [.filename]#${JAVASHAREDIR}/${PORTNAME}#. На усмотрение создателя порта остаётся решение вопроса о том, устанавливать ли дополнительные JAR-зависимости в этот каталог или напрямую использовать уже установленные (из каталога [.filename]#${JAVAJARDIR}#). +При переносе Java-приложения порт обычно устанавливает все компоненты в единый каталог (включая зависимости в виде JAR-файлов). В этом отношении настоятельно рекомендуется использовать [.filename]#${JAVASHAREDIR}/${PORTNAME}#. Портеру предстоит решить, устанавливать ли дополнительные JAR-зависимости в этот каталог или использовать уже установленные (из [.filename]#${JAVAJARDIR}#). -При портировании приложения Java(TM), для запуска сервиса которого требуется сервер приложений, такой как package:www/tomcat7[], для производителя в порядке вещей является распространение файла [.filename]#.war#. Файл [.filename]#.war# - это Веб-приложение АРхивированное и оно распаковывается при вызове данным приложением. Избегайте добавлять файлы [.filename]#.war# в [.filename]#pkg-plist#. Это не является наилучшим решением. Сервер приложений производит расширение архива [.filename]#war# без должной его очистки при удалении порта. Более подходящим способом работы с этим файлом будет распаковать архив, установить файлы и добавить их в [.filename]#pkg-plist#. +При переносе Java(TM)-приложения, которое требует сервера приложений, такого как package:www/tomcat7[], для запуска службы, вендор часто распространяет файл [.filename]#.war#. [.filename]#.war# — это веб-архив приложения (Web application ARchive), который извлекается при вызове приложением. Избегайте добавления [.filename]#.war# в [.filename]#pkg-plist#. Это не считается лучшей практикой. Сервер приложений развернет архив war, но не очистит его должным образом при удалении порта. Более предпочтительный способ работы с этим файлом — извлечь архив, затем установить файлы и, наконец, добавить эти файлы в [.filename]#pkg-plist#. [.programlisting] .... @@ -1140,20 +3110,20 @@ post-extract: do-install: cd ${WRKDIR} && \ ${INSTALL} -d -o ${WWWOWN} -g ${WWWGRP} ${TOMCATDIR}/webapps/${PORTDIRNAME} - @cd ${WRKDIR}/${PORTDIRNAME} && ${COPYTREE_SHARE} \* ${WEBAPPDIR}/${PORTDIRNAME} + cd ${WRKDIR}/${PORTDIRNAME} && ${COPYTREE_SHARE} \* ${WEBAPPDIR}/${PORTDIRNAME} .... -Вне зависимости от типа вашего порта (библиотека это или приложение), дополнительная документация должна устанавливаться <<install-documentation,в тоже самое место>>, что и для других портов. Известно, что в зависимости от используемой версии JDK утилита JavaDoc генерирует различные наборы файлов. Для портов, которые не привязаны к использованию определённой версии JDK, таким образом становится проблематичным определить список файлов для упаковки ([.filename]#pkg-plist#). Это одна из причин, по которой создателям портов настоятельно рекомендуется использовать макрос `PORTDOCS`. Более того, даже если вы сможете угадать набор файлов, который будет сгенерирован утилитой `javadoc`, размер получающегося файла [.filename]#pkg-plist# голосует за использование `PORTDOCS`. +Независимо от типа порта (библиотека или приложение), дополнительная документация устанавливается crossref:makefiles[install-documentation,в том же месте], что и для любого другого порта. Известно, что инструмент Javadoc создает разный набор файлов в зависимости от версии используемого JDK. Для портов, которые не требуют использования конкретной версии JDK, указание списка упаковки ([.filename]#pkg-plist#) становится сложной задачей. Это одна из причин, по которой разработчикам портов настоятельно рекомендуется использовать `PORTDOCS`. Более того, даже если набор файлов, генерируемых `javadoc`, можно предсказать, размер результирующего [.filename]#pkg-plist# говорит в пользу использования `PORTDOCS`. -Значением по умолчанию для переменной `DATADIR` является [.filename]#${PREFIX}/shared/${PORTNAME}#. Хорошей идеей является переопределение для Java-портов значения `DATADIR` как [.filename]#${JAVASHAREDIR}/${PORTNAME}#. На самом деле `DATADIR` автоматически добавляется к `PLIST_SUB` (это описано в crossref:plist[plist-sub,Изменение содержимого pkg-plist в зависимости от make-переменных]), так что вы сможете использовать `%%DATADIR%%` непосредственно в [.filename]#pkg-plist#. +Значение по умолчанию для `DATADIR` — [.filename]#${PREFIX}/share/${PORTNAME}#. Рекомендуется переопределить `DATADIR` на [.filename]#${JAVASHAREDIR}/${PORTNAME}# для портов Java. Действительно, `DATADIR` автоматически добавляется в `PLIST_SUB` (документировано в crossref:plist[plist-sub,Изменение pkg-plist на основе переменных Make]), поэтому используйте `%%DATADIR%%` напрямую в [.filename]#pkg-plist#. -Что касается выбора между построением портов Java из исходных текстов или их прямой установкой из бинарных дистрибутивов, то на момент создания этого текста определённой политики на этот счёт не существует. Однако участники http://www.freebsd.org/java/[Проекта FreeBSD Java] рекомендуют создателям портов строить их из исходных текстов, если эта задача является несложной. +Что касается выбора между сборкой портов Java из исходного кода или их непосредственной установкой из бинарного дистрибутива, на момент написания документации определённой политики не существует. Однако участники https://www.freebsd.org/java/[FreeBSD Java Project] рекомендуют сопровождающим портов по возможности собирать их из исходного кода, если это не представляет сложностей. -Все возможности, которые были описаны в этом разделе, реализованы в файле [.filename]#bsd.java.mk#. Если вы предположите, что вашему порту требуется менее тривиальная поддержка Java, пожалуйста, взгляните сначала на http://svnweb.FreeBSD.org/ports/head/Mk/bsd.java.mk?view=markup[журнал изменений bsd.java.mk в Subversion], так как для документирования последних изменений требуется какое-то время. Затем, если вы думаете, что не хватающая вам поддержка окажется полезной для многих других портов Java, обсудите ваш вопрос в freebsd-java. +Все функции, представленные в этом разделе, реализованы в [.filename]#bsd.java.mk#. Если порту требуется более сложная поддержка Java, сначала ознакомьтесь с https://cgit.FreeBSD.org/ports/tree/Mk/bsd.java.mk[историей изменений bsd.java.mk], так как документирование новых функций обычно занимает некоторое время. Затем, если отсутствующая поддержка будет полезна для многих других Java-портов, не стесняйтесь обсудить это на списке рассылки freebsd-java. -Хотя в базе сообщений об ошибках для соответствующих PR имеется категория `java`, она относится к работе над портированием JDK, которые проводит Проект FreeBSD Java. Таким образом, вы должны относить свой Java-порт, как и любой другой, к категории `ports`, если решаемый вами вопрос не относится ни к реализации JDK, ни к [.filename]#bsd.java.mk#. +Хотя существует категория `java` для PR, она относится к усилиям по портированию JDK в рамках проекта FreeBSD Java. Поэтому отправляйте порт Java в категорию `ports`, как и любой другой порт, если только проблема не связана либо с реализацией JDK, либо с [.filename]#bsd.java.mk#. -Похожим образом определена политика по отношению к `CATEGORIES` порта Java, которая подробно описана в crossref:makefiles[makefile-categories, Разделение по категориям]. +Аналогично существует определённая политика в отношении `CATEGORIES` для портов Java, которая подробно описана в crossref:makefiles[makefile-categories,Категоризация]. [[using-php]] == Веб-приложения, Apache и PHP @@ -1161,315 +3131,334 @@ do-install: [[using-apache]] === Apache +[[using-apache-variables]] .Переменные для портов, использующих Apache [cols="1,1", frame="none"] |=== |`USE_APACHE` -|Порт требует Apache. Возможные значения: `yes` (берёт любую версию), `22`, `24`, `22-24`, `22+` и так далее. Версия по умолчанию `22`. Более подробная информация содержится в файле [.filename]#ports/Mk/bsd.apache.mk# и на странице http://wiki.freebsd.org/Apache/[wiki.freebsd.org/Apache/]. +|Порт требует Apache. Возможные значения: `yes` (любая версия), `22`, `24`, `22-24`, `22+` и т.д. Версия APACHE по умолчанию — `22`. Подробнее см. в [.filename]#ports/Mk/bsd.apache.mk# и на https://wiki.freebsd.org/Apache/[wiki.freebsd.org/Apache/]. |`APXS` -|Полный путь к исполняемому файлу `apxs`. Может быть переопределен в вашем порту. +|Полный путь к бинарному файлу `apxs`. Может быть переопределён в порте. |`HTTPD` -|Полный путь к исполняемому файлу `httpd`. Может быть переопределен в вашем порту. +|Полный путь к бинарному файлу `httpd`. Может быть переопределён в порте. |`APACHE_VERSION` -|Версия установленного Apache (переменная только для чтения). Эта переменная доступна только после подключения [.filename]#bsd.port.pre.mk#. Возможные значения: `22`, `24`. +|Версия установленной Apache (переменная только для чтения). Эта переменная доступна только после включения [.filename]#bsd.port.pre.mk#. Возможные значения: `22`, `24`. |`APACHEMODDIR` -|Каталог для модулей Apache. Значение переменной автоматически подставляется в [.filename]#pkg-plist#. +|Каталог для модулей Apache. Эта переменная автоматически раскрывается в [.filename]#pkg-plist#. |`APACHEINCLUDEDIR` -|Каталог для заголовков Apache. Значение переменной автоматически подставляется в [.filename]#pkg-plist#. +|Каталог для заголовков Apache. Эта переменная автоматически раскрывается в [.filename]#pkg-plist#. |`APACHEETCDIR` -|Каталог для конфигурационных файлов Apache. Значение переменной автоматически подставляется в [.filename]#pkg-plist#. +|Каталог для файлов конфигурации Apache. Эта переменная автоматически раскрывается в [.filename]#pkg-plist#. |=== -.Используемые переменные при портировании модулей Apache +[[using-apache-modules]] +.Полезные переменные для переноса модулей Apache [cols="1,1", frame="none"] |=== |`MODULENAME` -|Название модуля. Значением по умолчанию является `PORTNAME`. Пример: `mod_hello` +|Имя модуля. Значение по умолчанию — `PORTNAME`. Пример: `mod_hello` |`SHORTMODNAME` -|Краткое название модуля. Наследуется автоматически от `MODULENAME`, но может быть переопределено. Пример: `hello` +|Короткое имя модуля. Автоматически определяется из `MODULENAME`, но может быть переопределено. Пример: `hello` |`AP_FAST_BUILD` -|Использовать `apxs` для компиляции и установки модуля. +|Используйте `apxs` для компиляции и установки модуля. |`AP_GENPLIST` -|Также автоматически создает [.filename]#pkg-plist#. +|Также автоматически создаёт файл [.filename]#pkg-plist#. |`AP_INC` -|Добавляет каталог к пути поиска заголовков во время компиляции. +|Добавляет каталог в путь поиска заголовков во время компиляции. |`AP_LIB` -|Добавляет каталог к пути поиска библиотек во время компиляции. +|Добавляет каталог в путь поиска библиотек во время компиляции. |`AP_EXTRAS` -|Дополнительные флаги, передаваемые `apxs`. +|Дополнительные флаги для передачи в `apxs`. |=== [[web-apps]] === Веб-приложения -Веб-приложения следует устанавливать в [.filename]#PREFIX/www/appname#. Для вашего удобства этот путь одинаково доступен в [.filename]#Makefile# и [.filename]#pkg-plist# как переменная `WWWDIR`, а путь относительно `PREFIX` доступен в [.filename]#Makefile# как `WWWDIR_REL`. +Веб-приложения должны быть установлены в [.filename]#PREFIX/www/appname#. Этот путь доступен как в [.filename]#Makefile#, так и в [.filename]#pkg-plist# как `WWWDIR`, а путь относительно `PREFIX` доступен в [.filename]#Makefile# как `WWWDIR_REL`. + +Пользователь и группа процесса веб-сервера доступны как `WWWOWN` и `WWWGRP`, если необходимо изменить владельца некоторых файлов. Значения по умолчанию для обоих — `www`. Используйте `WWWOWN?= myuser` и `WWWGRP?= mygroup`, если порту требуются другие значения. Это позволяет пользователю легко их переопределить. -Пользователь и группа процесса веб-сервера доступны как `WWWOWN` и `WWWGRP`, в случае если вам нужно изменить владельца для некоторых файлов. Значением по умолчанию и для владельца, и для группы является `www`. Если вы хотите использовать в вашем порте другие значения, воспользуйтесь для этого нотацией `WWWOWN?= myuser`, чтобы позволить пользователю легко переопределить их. +[IMPORTANT] +==== +Используйте `WWWOWN` и `WWWGRP` с осторожностью. Помните, что каждый файл, доступный для записи веб-серверу, представляет собой потенциальную угрозу безопасности. +==== -Не добавляйте зависимость от Apache, если веб-приложение явным образом не нуждается в Apache. Учитывайте, что пользователи могут пожелать запустить ваше веб-приложение на другом веб-сервере помимо Apache. +Не зависьте от Apache, если веб-приложение явно не требует Apache. Учитывайте, что пользователи могут захотеть запускать веб-приложение на другом веб-сервере, кроме Apache. [[php-variables]] === PHP -.Переменные для портов, использующих PHP -[cols="1,1", frame="none"] -|=== -|`USE_PHP` -|Порт требует PHP. Значение `yes` добавляет зависимость от PHP. Вместо этого может быть указан перечень требуемых расширений PHP. Пример: `pcre xml gettext` +Веб-приложения PHP объявляют свою зависимость от него с помощью `USES=php`. Подробнее см. в crossref:uses[uses-php,`php`]. -|`DEFAULT_PHP_VER` -|Выбирает старший номер версии, с которым будет установлен PHP как зависимость в случае, когда PHP еще не установлен. По умолчанию `5`. Возможные значения: `4`, `5` +[[php-pear]] +=== Модули PEAR -|`IGNORE_WITH_PHP` -|Порт не работает с PHP данной версии. Возможные значения: `4`, `5` +Портирование модулей PEAR — это очень простой процесс. -|`USE_PHPIZE` -|Порт будет построен как расширение PHP. +Добавьте `USES=pear` в [.filename]#Makefile# порта. Фреймворк установит соответствующие файлы в нужные места и автоматически сгенерирует plist во время установки. -|`USE_PHPEXT` -|Порт будет считаться расширением PHP, включая установку и регистрацию в реестре расширений. +[[pear-makefile]] +.Пример Makefile для PEAR Class +[example] +==== +[.programlisting] +.... +PORTNAME= Date +DISTVERSION= 1.4.3 +CATEGORIES= devel www pear -|`USE_PHP_BUILD` -|Установить PHP как зависимость времени построения. +MAINTAINER= someone@example.org +COMMENT= PEAR Date and Time Zone Classes +WWW= https://pear.php.net/package/Date/ -|`WANT_PHP_CLI` -|Хочет CLI (командная строка) версию PHP. +USES= pear -|`WANT_PHP_CGI` -|Хочет CGI версию PHP. +.include <bsd.port.mk> +.... -|`WANT_PHP_MOD` -|Хочет PHP как модуль Apache. +==== -|`WANT_PHP_SCR` -|Хочет CLI или CGI версию PHP. +[TIP] +==== +Модули PEAR будут автоматически преобразованы в порт с флейвором с использованием crossref:flavors[flavors-auto-php,флейворов PHP]. +==== -|`WANT_PHP_WEB` -|Хочет модуль Apache или CGI версию PHP. -|=== +[NOTE] +==== +Если используется нестандартный `PEAR_CHANNEL`, зависимости для сборки и выполнения будут добавлены автоматически. +==== -=== Модули PEAR +[IMPORTANT] +==== +Модули PEAR не требуют определения `PKGNAMESUFFIX`, так как он автоматически заполняется с использованием `PEAR_PKGNAMEPREFIX`. Если порту необходимо добавить к `PKGNAMEPREFIX`, он также должен использовать `PEAR_PKGNAMEPREFIX`, чтобы отличать различные флейворы. +==== -Портирование модулей PEAR является очень простым процессом. +[[php-horde]] +==== Модули Horde -Используйте переменные `FILES`, `TESTS`, `DATA`, `SQLS`, `SCRIPTFILES`, `DOCS` and `EXAMPLES` для перечисления файлов, которые вы хотите установить. Все перечисленные файлы будут автоматически установлены в подходящие места и добавлены в [.filename]#pkg-plist#. +Также и перенос модулей Horde является простым процессом. -Подключите [.filename]#${PORTSDIR}/devel/pear/bsd.pear.mk# на последней строке [.filename]#Makefile#. +Добавьте `USES=horde` в [.filename]#Makefile# порта. Фреймворк установит соответствующие файлы в нужные места и автоматически сгенерирует plist во время установки. -[[pear-makefile]] -.Пример Makefile для классов PEAR +Переменные `USE_HORDE_BUILD` и `USE_HORDE_RUN` могут использоваться для добавления зависимостей времени сборки и выполнения от других модулей Horde. Полный список доступных модулей можно найти в [.filename]#Mk/Uses/horde.mk#. + +[[horde-Makefile]] +.Пример Makefile для модуля Horde [example] ==== [.programlisting] .... -PORTNAME= Date -PORTVERSION= 1.4.3 +PORTNAME= Horde_Core +DISTVERSION= 2.14.0 CATEGORIES= devel www pear -MAINTAINER= example@domain.com -COMMENT= PEAR Date and Time Zone Classes +MAINTAINER= horde@FreeBSD.org +COMMENT= Horde Core Framework libraries +WWW= https://pear.horde.org/ -BUILD_DEPENDS= ${PEARDIR}/PEAR.php:${PORTSDIR}/devel/pear-PEAR -RUN_DEPENDS:= ${BUILD_DEPENDS} +OPTIONS_DEFINE= KOLAB SOCKETS +KOLAB_DESC= Enable Kolab server support +SOCKETS_DESC= Depend on sockets PHP extension -FILES= Date.php Date/Calc.php Date/Human.php Date/Span.php \ - Date/TimeZone.php -TESTS= test_calc.php test_date_methods_span.php testunit.php \ - testunit_date.php testunit_date_span.php wknotest.txt \ - bug674.php bug727_1.php bug727_2.php bug727_3.php \ - bug727_4.php bug967.php weeksinmonth_4_monday.txt \ - weeksinmonth_4_sunday.txt weeksinmonth_rdm_monday.txt \ - weeksinmonth_rdm_sunday.txt -DOCS= TODO -_DOCSDIR= . +USES= horde +USE_PHP= session -.include <bsd.port.pre.mk> -.include "${PORTSDIR}/devel/pear/bsd.pear.mk" -.include <bsd.port.post.mk> +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> .... ==== +[TIP] +==== +Поскольку модули Horde также являются модулями PEAR, они будут автоматически преобразованы с использованием crossref:flavors[flavors-auto-php,флейворов PHP]. +==== + [[using-python]] == Использование Python -Коллекция Портов поддерживает параллельную установку множества версий Python. Следует убедиться, что в портах используется правильный интерпретатор `python` в соответствии с переменной `PYTHON_VERSION`, установленной пользователем. По большей части это означает замену пути к исполняемому файлу `python` в сценариях на значение переменной `PYTHON_CMD`. +Коллекция портов поддерживает параллельную установку нескольких версий Python. Порты должны использовать правильный интерпретатор `python` в соответствии с настраиваемым пользователем параметром `PYTHON_VERSION`. Важнее всего заменить путь к исполняемому файлу `python` в скриптах на значение `PYTHON_CMD`. -Порты, устанавливающие файлы под каталог `PYTHON_SITELIBDIR`, должны использовать префикс вида `pyXY-`, таким образом названия пакетов будут включать в себя версию Python, с которой они установлены. +Порты, которые устанавливают файлы в `PYTHON_SITELIBDIR`, должны использовать префикс имени пакета `pyXY-`, чтобы их имя пакета включало версию Python, для которой они предназначены. [.programlisting] .... PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} .... -.Переменные для портов, которые используют Python + +[[using-python-variables]] +.Наиболее полезные переменные для портов, использующих Python [cols="1,1", frame="none"] |=== -|`USE_PYTHON` -|Для этого порта нужен Python. Минимальная требуемая версия может быть указана с таким значением как `2.6+`. Также можно указан диапазон версий с разделением двух версий через -, например: `2.6-2.7` +|`USES=python` +|Порту требуется Python. Минимально необходимая версия может быть указана с такими значениями, как `3.10+`. Диапазоны версий также можно указать, разделив две версии дефисом: `USES=python:3.8-3.9`. Обратите внимание, что `USES=python` _не_ включает Python 2.7, его нужно запрашивать явно с помощью `USES=python:2.7+`. + +|`USE_PYTHON=distutils` +|Используйте Python distutils для настройки, компиляции и установки. Это требуется, когда порт поставляется с [.filename]#setup.py#. Это переопределяет цели `do-build` и `do-install`, а также может переопределить `do-configure`, если `GNU_CONFIGURE` не определён. Кроме того, подразумевается `USE_PYTHON=flavors`. -|`USE_PYDISTUTILS` -|Использовать дистрибутивные утилиты (distutils) Python для конфигурации, компиляции и установки. Необходимо, если порт использует [.filename]#setup.py#. Переопределяет цели `do-build` и `do-install` и также может переопределять `do-configure`, если не определена `GNU_CONFIGURE`. +|`USE_PYTHON=autoplist` +|Создать список пакетов автоматически. Это также требует установки `USE_PYTHON=distutils`. + +|`USE_PYTHON=concurrent` +|Порт будет использовать уникальный префикс, обычно `PYTHON_PKGNAMEPREFIX`, для определённых каталогов, таких как `EXAMPLESDIR` и `DOCSDIR`, а также добавлять суффикс — версию Python из `PYTHON_VER` — к устанавливаемым бинарным файлам и скриптам. Это позволяет устанавливать порты для разных версий Python одновременно, что в противном случае приводило бы к конфликту файлов. + +|`USE_PYTHON=flavors` +|Порт не использует distutils, но по-прежнему поддерживает несколько версий Python. `FLAVORS` будет установлен в поддерживаемые версии Python. Дополнительную информацию см. в crossref:flavors[flavors-auto-python,`USES`=python и флейворы]. + +|`USE_PYTHON=optsuffix` +|Если текущая версия Python не является версией по умолчанию, порт получит `PKGNAMESUFFIX=${PYTHON_PKGNAMESUFFIX}`. Полезно только для флейворов. |`PYTHON_PKGNAMEPREFIX` -|Используется как `PKGNAMEPREFIX` для отличия пакетов, использующих разные версии Python. Пример: `py24-` +|Используется как `PKGNAMEPREFIX` для различения пакетов разных версий Python. Пример: `py27-` |`PYTHON_SITELIBDIR` -|Местонахождение дерева site-packages, которое содержит путь установки Python (обычно, `LOCALBASE`). Переменная `PYTHON_SITELIBDIR` может быть очень полезной при установке модулей Python. +|Расположение дерева site-packages, которое содержит путь установки Python (обычно `LOCALBASE`). `PYTHON_SITELIBDIR` может быть очень полезно при установке модулей Python. |`PYTHONPREFIX_SITELIBDIR` -|Вариант PYTHON_SITELIBDIR без PREFIX. По возможности всегда используйте `%%PYTHON_SITELIBDIR%%` в [.filename]#pkg-plist#. Значением по умолчанию для `%%PYTHON_SITELIBDIR%%` является `lib/python%%PYTHON_VERSION%%/site-packages`. +|Вариант PREFIX-clean для PYTHON_SITELIBDIR. Всегда используйте `%%PYTHON_SITELIBDIR%%` в [.filename]#pkg-plist#, когда это возможно. Значение по умолчанию для `%%PYTHON_SITELIBDIR%%` — `lib/python%%PYTHON_VERSION%%/site-packages` |`PYTHON_CMD` -|Командная строка интерпретатора Python, включая номер версии. +|Интерпретатор командной строки Python, включая номер версии. +|=== +[[using-python-variables-helpers]] +.Помощники зависимостей модуля Python +[cols="1,1", frame="none"] +|=== |`PYNUMERIC` -|Строка зависимости для расширения numeric. +|Строка зависимости для числового расширения. |`PYNUMPY` -|Строка зависимости для нового расширения numeric, numpy (PYNUMERIC объявлен устаревшим вышестоящим производителем). +|Строка зависимости для нового числового расширения, numpy. (PYNUMERIC устарел у вендора). |`PYXML` -|Строка зависимости для расширения XML (не нужно для Python 2.0 и выше, т.к. включено в основной дистрибутив). -|=== +|Строка зависимости для расширения XML (не требуется для Python 2.0 и выше, так как оно также входит в базовую поставку). -Полный перечень доступных переменных можно найти в [.filename]#/usr/ports/Mk/bsd.python.mk#. +|`PY_ENUM34` +|Условная зависимость от пакета package:devel/py-enum34[] в зависимости от версии Python. -Некоторые приложения на Python заявляют о поддержке `DESTDIR` (требуется для staging), которая не работает (в частности, у Mailman до версии 2.1.16). Ограничение можно обойти путём перекомпиляции сценариев. Например, это можно выполнить в цели `post-build`. С учётом того, что после установки предполагаемое место размещения сценариев Python будет находиться в `PYTHONPREFIX_SITELIBDIR`, можно применить следующее решение: +|`PY_ENUM_COMPAT` +|Условная зависимость от пакета package:devel/py-enum-compat[] в зависимости от версии Python. -[.programlisting] -.... -(cd ${STAGEDIR}${PREFIX} \ - && ${PYTHON_CMD} ${PYTHON_LIBDIR}/compileall.py \ - -d ${PREFIX} -f ${PYTHONPREFIX_SITELIBDIR:S;${PREFIX}/;;}) -.... +|`PY_PATHLIB` +|Условная зависимость от пакета package:devel/py-pathlib[] в зависимости от версии Python. -Эта команда перекомпилирует исходный текст с заменой путей на относительные к каталогу сборки, а также дописывает значение `PREFIX` перед именем файла, записанного в выходном файле с промежуточным представлением, с использованием `-d`. `-f` требуется для безусловной перекомпиляции, `:S;${PREFIX}/;;` удаляет префиксы из значения переменной `PYTHONPREFIX_SITELIBDIR`, чтобы сделать его относительным к `PREFIX`. +|`PY_IPADDRESS` +|Условная зависимость от пакета package:net/py-ipaddress[] в зависимости от версии Python. -Для этого требуется Python 2.7 или выше. Это не работает с Python 2.6. - -[[using-tcl]] -== Использование Tcl/Tk - -В Коллекции Портов поддерживается одновременная установка множественных версий Tcl/Tk. Порты должны пытаться поддерживать по крайней мере версию Tcl/Tk, используемую по умолчанию, и выше с помощью переменных `USE_TCL` и `USE_TK`. Желаемую версию `tcl` можно указать в переменной `WITH_TCL_VER`. - -.Наиболее востребованные переменные для портов, которые используют Tcl/Tk -[cols="1,1", frame="none"] +|`PY_FUTURES` +|Условная зависимость от пакета package:devel/py-futures[] в зависимости от версии Python. |=== -|`USE_TCL` -|Порт зависит от библиотеки Tcl (не оболочки). Минимальную требуемую версию можно указать с использованием таких значений, как 84+. Отдельные неподдерживаемые версии указываются в переменной `INVALID_TCL_VER`. -|`USE_TCL_BUILD` -|Tcl нужен для порта только на время сборки. +Полный список доступных переменных можно найти в [.filename]#/usr/ports/Mk/Uses/python.mk#. -|`USE_TCL_WRAPPER` -|Эту новую переменную следует использовать для портов, для которых требуется оболочка Tcl и не требуется конкретная версия `tclsh`. Обертка `tclsh` устанавливается в систему. Пользователь может указать желаемую оболочку `tcl` для использования. +[IMPORTANT] +==== +Все зависимости для портов Python, использующих crossref:flavors[flavors-auto-python,флейворы Python] (с `USE_PYTHON=distutils` или `USE_PYTHON=flavors`), должны иметь флейвор Python, добавленную к их origin с помощью `@${PY_FLAVOR}`. См. crossref:special[python-Makefile,Makefile для простого модуля Python]. +==== -|`WITH_TCL_VER` -|Определяемые пользователем переменные, которые устанавливают желаемую версию Tcl. +[[python-Makefile]] +.Makefile для Простого Модуля Python +[example] +==== +[.programlisting] +.... +PORTNAME= sample +DISTVERSION= 1.2.3 +CATEGORIES= devel -|`UNIQUENAME_WITH_TCL_VER` -|Подобно `WITH_TCL_VER`, но для каждого порта. +MAINTAINER= fred.bloggs@example.com +COMMENT= Python sample module +WWW= https://example.com/project/sample/ -|`USE_TCL_THREADS` -|Требует многопоточную сборку Tcl/Tk. +RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR} -|`USE_TK` -|Порт зависит от библиотеки Tk (не от предпочитаемой оболочки). Подразумевает `USE_TCL` с тем же значением. Для большей информации смотрите описание переменной `USE_TCL`. +USES= python +USE_PYTHON= autoplist distutils -|`USE_TK_BUILD` -|Аналогично `USE_TCL_BUILD`. +.include <bsd.port.mk> +.... -|`USE_TK_WRAPPER` -|Аналогично `USE_TCL_WRAPPER`. +==== -|`WITH_TK_VER` -|Аналогично `WITH_TCL_VER`, подразумевает `WITH_TCL_VER` той же версии. -|=== +Некоторые приложения на Python заявляют о поддержке `DESTDIR` (что необходимо для промежуточной сборки), но она не работает (например, Mailman до версии 2.1.16). Это можно обойти, перекомпилировав скрипты. Это можно сделать, например, в цели `post-build`. Предполагая, что Python-скрипты должны находиться в `PYTHONPREFIX_SITELIBDIR` после установки, можно применить следующее решение: -Полный перечень доступных переменных находится в [.filename]#/usr/ports/Mk/bsd.tcl.mk#. +[.programlisting] +.... +(cd ${STAGEDIR}${PREFIX} \ + && ${PYTHON_CMD} ${PYTHON_LIBDIR}/compileall.py \ + -d ${PREFIX} -f ${PYTHONPREFIX_SITELIBDIR:S;${PREFIX}/;;}) +.... -[[using-emacs]] -== Использование Emacs +Это перекомпилирует исходники с путём, относительным к stage-директории, и добавляет значение `PREFIX` к имени файла, записанному в байт-компилированном выходном файле с помощью `-d`. `-f` требуется для принудительной перекомпиляции, а `:S;${PREFIX}/;;` удаляет префиксы из значения `PYTHONPREFIX_SITELIBDIR`, чтобы сделать его относительным к `PREFIX`. -Этот раздел ещё предстоит написать. +[[using-tcl]] +== Использование Tcl/Tk -[[using-ruby]] -== Использование Ruby +Коллекция Ports поддерживает параллельную установку нескольких версий Tcl/Tk. Порты должны стараться поддерживать как минимум версию Tcl/Tk по умолчанию и выше с помощью `USES=tcl`. Можно указать желаемую версию `tcl`, добавив `:_xx_`, например, `USES=tcl:85`. -.Полезные переменные для портов, использующих Ruby -[cols="1,1", frame="none", options="header"] +[[using-tcl-variables]] +.Самые полезные переменные только для чтения для портов, использующих Tcl/Tk +[cols="1,1", frame="none"] |=== -| Переменная -| Описание - -|`USE_RUBY` -|Порт требует Ruby. +|`TCL_VER` +| выбранная версия Tcl major.minor -|`USE_RUBY_EXTCONF` -|Порт использует для конфигурации [.filename]#extconf.rb#. +|`TCLSH` +| полный путь к интерпретатору Tcl -|`USE_RUBY_SETUP` -|Порт использует для конфигурации [.filename]#setup.rb#. +|`TCL_LIBDIR` +| путь к библиотекам Tcl -|`RUBY_SETUP` -|Устанавливает альтернативное имя для [.filename]#setup.rb#. Распространенным значением является [.filename]#install.rb#. -|=== +|`TCL_INCLUDEDIR` +| путь к заголовочным файлам Tcl C -Следующая таблица отражает некоторые переменные, доступные авторам портов через инфраструктуру портов. Эти переменные должны использоваться для установки файлов в правильное месторасположение. Используйте их в [.filename]#pkg-plist# как можно больше. Эти переменные не должны переопределяться в самом порте. +|`TCL_PKG_LIB_PREFIX` +| Префикс библиотеки, согласно TIP595 -.Отобранные переменные только для чтения для портов, использующих Ruby -[cols="1,1,1", frame="none", options="header"] -|=== -| Переменная -| Описание -| Примерное значение +|`TCL_PKG_STUB_POSTFIX` +|Заглушка библиотеки postfix -|`RUBY_PKGNAMEPREFIX` -|Используется как `PKGNAMEPREFIX` для различия пакетов от разных версий Ruby. -|`ruby18-` +|`TK_VER` +| выбранная версия Tk major.minor -|`RUBY_VERSION` -|Полная версия Ruby в форме `x.y.z`. -|`1.8.2` +|`WISH` +| полный путь к интерпретатору Tk -|`RUBY_SITELIBDIR` -|Путь для установки архитектуронезависимых библиотек. -|`/usr/local/lib/ruby/site_ruby/1.8` +|`TK_LIBDIR` +| путь к библиотекам Tk -|`RUBY_SITEARCHLIBDIR` -|Путь для установки архитектурозависимых библиотек. -|`/usr/local/lib/ruby/site_ruby/1.8/amd64-freebsd6` - -|`RUBY_MODDOCDIR` -|Путь для установки документации модуля. -|`/usr/local/shared/doc/ruby18/patsy` - -|`RUBY_MODEXAMPLESDIR` -|Путь для установки примеров модуля. -|`/usr/local/shared/examples/ruby18/patsy` +|`TK_INCLUDEDIR` +| путь к заголовочным файлам Tk C |=== -Полный перечень доступных переменных находится в [.filename]#/usr/ports/Mk/bsd.ruby.mk#. +См. crossref:uses[uses-tcl,`USES=tcl`] и crossref:uses[uses-tk,`USES=tk`] в crossref:uses[uses,Использование макросов `USES`] для полного описания этих переменных. Полный список этих переменных доступен в [.filename]#/usr/ports/Mk/Uses/tcl.mk#. [[using-sdl]] == Использование SDL -Переменная `USE_SDL` используется для автоматической настройки зависимостей для портов, использующих библиотеки на основе SDL, такие как package:devel/sdl12[] или package:graphics/sdl_image[]. +`USE_SDL` используется для автоматической настройки зависимостей для портов, которые используют библиотеку на основе SDL, такие как package:devel/sdl12[] и package:graphics/sdl_image[]. -Для версии 1.2 на данный момент распознаются следующие SDL-библиотеки: +Эти библиотеки SDL для версии 1.2 распознаются: * sdl: package:devel/sdl12[] * console: package:devel/sdl_console[] @@ -1482,7 +3471,7 @@ PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} * sound: package:audio/sdl_sound[] * ttf: package:graphics/sdl_ttf[] -Для версии 2.0 на данный момент распознаются следующие SDL-библиотеки: +Эти библиотеки SDL для версии 2.0 распознаются: * sdl: package:devel/sdl20[] * gfx: package:graphics/sdl2_gfx[] @@ -1491,61 +3480,47 @@ PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} * net: package:net/sdl2_net[] * ttf: package:graphics/sdl2_ttf[] -Таким образом, если порт имеет зависимость от package:net/sdl_net[] и package:audio/sdl_mixer[], то строка будет следующей: +Следовательно, если порт зависит от package:net/sdl_net[] и package:audio/sdl_mixer[], синтаксис будет следующим: [.programlisting] .... USE_SDL= net mixer .... -Зависимость от порта package:devel/sdl12[], который требуется для package:net/sdl_net[] и package:audio/sdl_mixer[], будет также автоматически добавлен. - -Если вы используете `USE_SDL` с элементами SDL 1.2, то он автоматически: - -* Добавляет зависимость от sdl12-config к `BUILD_DEPENDS` -* Добавляет переменную `SDL_CONFIG` к `CONFIGURE_ENV` -* Добавляет зависимости от указанных библиотек к `LIB_DEPENDS` - -Если вы используете `USE_SDL` с элементами SDL 2.0, то он автоматически: +Пакет зависимости package:devel/sdl12[], который требуется для package:net/sdl_net[] и package:audio/sdl_mixer[], также автоматически добавляется. -* Добавляет зависимость от sdl2-config к `BUILD_DEPENDS` -* Добавляет переменную `SDL2_CONFIG` к `CONFIGURE_ENV` -* Добавляет зависимости от указанных библиотек к `LIB_DEPENDS` +Использование `USE_SDL` с указанием SDL 1.2 автоматически: -Для проверки наличия библиотеки SDL вы можете делать это при помощи переменной `WANT_SDL`: +* Добавить зависимость от sdl12-config в `BUILD_DEPENDS` +* Добавьте переменную `SDL_CONFIG` в `CONFIGURE_ENV` +* Добавьте зависимости выбранных библиотек в `LIB_DEPENDS` -[.programlisting] -.... -WANT_SDL= yes - -.include <bsd.port.pre.mk> +Используя `USE_SDL` с записями для SDL 2.0, это автоматически: -.if ${HAVE_SDL:Mmixer}!="" -USE_SDL+= mixer -.endif +* Добавить зависимость от sdl2-config в `BUILD_DEPENDS` +* Добавьте переменную `SDL2_CONFIG` в `CONFIGURE_ENV` +* Добавьте зависимости выбранных библиотек в `LIB_DEPENDS` -.include <bsd.port.post.mk> -.... [[using-wx]] == Использование wxWidgets -Эта глава описывает статус библиотек wxWidgets в дереве портов и их интеграцию с системой портов. +Этот раздел описывает состояние библиотек wxWidgets в дереве портов и их интеграцию с системой портов. [[wx-introduction]] === Введение -Существует множество версий библиотек wxWidgets, конфликтующих между собой (устанавливают файлы под тем же именем). В дереве портов эта проблема решена путем установки каждой версии под собственным названием с использованием номера версии в качестве суффикса. +Существует множество версий библиотек wxWidgets, которые конфликтуют между собой (устанавливают файлы с одинаковыми именами). В дереве портов эта проблема решена путем установки каждой версии под разными именами с использованием суффиксов номеров версий. -Очевидным недостатком этого является необходимость изменения каждого приложения для нахождения искомой версии. К счастью, большинство приложений для определения нужного компилятора и флагов компоновки вызывают сценарий `wx-config`. Для каждой доступной версии этот сценарий имеет своё имя. Большинство приложений учитывают переменную окружения или принимают аргумент configure для указания, какой сценарий `wx-config` следует вызывать. На все остальные приходится накладывать патч. +Очевидный недостаток этого подхода заключается в том, что каждое приложение необходимо модифицировать для поиска нужной версии. К счастью, большинство приложений вызывают скрипт `wx-config` для определения необходимых флагов компилятора и компоновщика. Имя этого скрипта отличается для каждой доступной версии. Большинство приложений учитывают переменную окружения или принимают аргумент configure, чтобы указать, какой скрипт `wx-config` вызывать. В противном случае их необходимо патчить. [[wx-version]] === Выбор версии -Для того, чтобы заставить ваш порт использовать конкретную версию wxWidgets, существует две доступные для определения переменные (если определена только одна, то вторая примет значение по умолчанию): +Чтобы порт использовал определённую версию wxWidgets, доступны две переменные для определения (если задана только одна, другая будет установлена в значение по умолчанию): [[wx-ver-sel-table]] -.Переменные для выбора версии wxWidgets +.Переменные для выбора версий wxWidgets [cols="1,1,1", frame="none", options="header"] |=== | Переменная @@ -1553,65 +3528,59 @@ USE_SDL+= mixer | Значение по умолчанию |`USE_WX` -|Перечень версий, которые порт может использовать +|Список версий, которые порт может использовать |Все доступные версии |`USE_WX_NOT` -|Перечень версий, которые порт не может использовать -|Нет +|Список версий, которые порт не может использовать +|Ничего |=== -Перечень доступных версий wxWidgets и соответствующих им портов в дереве: +Доступные версии wxWidgets и соответствующие порты в дереве: +[[wx-widgets-versions-table]] .Доступные версии wxWidgets [cols="1,1", frame="none", options="header"] |=== | Версия | Порт -|`2.4` -|package:x11-toolkits/wxgtk24[] - -|`2.6` -|package:x11-toolkits/wxgtk26[] - |`2.8` |package:x11-toolkits/wxgtk28[] -|=== -[NOTE] -==== -Версии начиная с `2.5` также поставляются с Unicode и устанавливается подчиненным портом с названием как как у обычного, но с суффиксом `-unicode`, но этим можно управлять при помощи переменных (смотрите <<wx-unicode>>). -==== +|`3.0` +|package:x11-toolkits/wxgtk30[] +|=== -Переменные в <<wx-ver-sel-table>> можно установить в одну или более следующих комбинаций, разделенных пробелами: +Переменные в crossref:special[wx-ver-sel-table,Переменные для выбора версий wxWidgets] могут быть установлены в одну или несколько комбинаций, разделенных пробелами: -.Определение версии для wxWidgets +[[wx-widgets-versions-specification]] +.Спецификации версий wxWidgets [cols="1,1", frame="none", options="header"] |=== | Описание | Пример -|Единичная версия -|`2.4` +|Единственная версия +|`2.8` -|Восходящий диапазон -|`2.4+` +|Возрастающий диапазон +|`2.8+` |Нисходящий диапазон -|`2.6-` +|`3.0-` -|Полный диапазон (обязан быть восходящим) -|`2.4-2.6` +|Полный диапазон (должен быть возрастающим) +|`2.8-3.0` |=== -Кроме того, существует несколько переменных для выбора предпочитаемых версий из перечня доступных. Они могут быть установлены в несколько версий, первая из которых будет иметь наибольший приоритет. - -.Переменные для выбора предпочитаемых версий wxWidgets +Существуют также переменные для выбора предпочтительных версий из доступных. Их можно установить в виде списка версий, где первые будут иметь более высокий приоритет. +[[wx-widgets-preferred-version]] +.Переменные для выбора предпочтительных версий wxWidgets [cols="1,1", frame="none", options="header"] |=== -| Название -| Предназначение +| Имя +| Предназначен для |`WANT_WX_VER` |порт @@ -1623,58 +3592,52 @@ USE_SDL+= mixer [[wx-components]] === Выбор компонентов -Существуют другие приложения, которые, хотя и не являются библиотеками wxWidgets, но в тоже время относятся к ним. Эти приложения можно указать в переменной `WX_COMPS`. Доступны следующие компоненты: +Существуют другие приложения, которые, не являясь библиотеками wxWidgets, связаны с ними. Эти приложения можно указать в `WX_COMPS`. Доступны следующие компоненты: +[[wx-widgets-components-table]] .Доступные компоненты wxWidgets [cols="1,1,1", frame="none", options="header"] |=== -| Название +| Имя | Описание | Ограничение версии |`wx` |основная библиотека -|нет +|none |`contrib` |сторонние библиотеки -|`нет` +|`none` |`python` -|wxPython (привязки к Python) -|`2.4-2.6` - -|`mozilla` -|wxMozilla -|`2.4` - -|`svg` -|wxSVG -|`2.6` +|wxPython (интерфейс Python) +|`2.8-3.0` |=== -Тип добавляемой зависимости при выборе каждого компонента может быть указан вручную путем добавления суффикса, отделенного точкой с запятой. Если таковой отсутствует, но будет использовано значение по умолчанию (смотрите <<wx-def-dep-types>>). Доступные типы зависимости: +Тип зависимости может быть выбран для каждого компонента путем добавления суффикса, разделенного точкой с запятой. Если он отсутствует, будет использоваться тип по умолчанию (см. crossref:special[wx-def-dep-types,Типы зависимостей wxWidgets по умолчанию]). Доступны следующие типы: -.Доступные типы зависимости wxWidgets +[[wx-widgets-dependency-table]] +.Доступные типы зависимостей wxWidgets [cols="1,1", frame="none", options="header"] |=== -| Название +| Имя | Описание |`build` -|Компонент требуется для построения, эквивалентен `BUILD_DEPENDS` +|Компонент необходим для сборки, эквивалентен `BUILD_DEPENDS` |`run` -|Компонент требуется для запуска, эквивалентен `RUN_DEPENDS` +|Компонент необходим для запуска, эквивалентно `RUN_DEPENDS` |`lib` -|Компонент требуется для построения и запуска, эквивалентен `LIB_DEPENDS` +|Компонент необходим для сборки и запуска, эквивалентен `LIB_DEPENDS` |=== -Значения по умолчанию для компонентов подробно рассматриваются в следующей таблице: +Значения по умолчанию для компонентов подробно описаны в этой таблице: [[wx-def-dep-types]] -.Типы зависимости wxWidgets, используемые по умолчанию +.Типы зависимостей wxWidgets по умолчанию [cols="1,1", frame="none", options="header"] |=== | Компонент @@ -1700,61 +3663,26 @@ USE_SDL+= mixer .Выбор компонентов wxWidgets [example] ==== -Следующий фрагмент относится к порту, в котором используется wxWidgets версии `2.4` с его сторонними библиотеками. +Этот фрагмент соответствует порту, который использует wxWidgets версии `2.4` и дополнительные библиотеки. [.programlisting] .... -USE_WX= 2.4 +USE_WX= 2.8 WX_COMPS= wx contrib .... ==== -[[wx-unicode]] -=== Unicode - -Библиотека wxWidgets поддерживает Unicode начиная с версии `2.5`. В дереве портов доступны обе версии и могут быть выбраны с использованием следующих переменных: -[[wx-unicode-var-table]] -.Переменные для выбора версии wxWidgets с Unicode -[cols="1,1,1", frame="none", options="header"] -|=== -| Переменная -| Описание -| Предназначение - -|`WX_UNICODE` -|Порт работает _только_ с версией Unicode -|порт - -|`WANT_UNICODE` -|Порт работает с обеими версиями, но предпочитает версию с Unicode -|порт - -|`WITH_UNICODE` -|Порт будет использовать версию Unicode -|пользователь - -|`WITHOUT_UNICODE` -|Порт будет использовать обычную версию, если это поддерживается (когда `WX_UNICODE` не определена) -|пользователь -|=== - -[WARNING] -==== - -Не используйте `WX_UNICODE` для портов, которые могут использовать обе версии. Если вы хотите, чтобы порт по умолчанию использовал Unicode, определите вместо этого `WANT_UNICODE`. -==== - [[wx-version-detection]] === Обнаружение установленных версий -Для обнаружения установленной версии вам необходимо задать переменную `WANT_WX`. Если вы не присвоите ей определенную версию, то компоненты получат суффикс версии. Переменная `HAVE_WX` будет заполнена после обнаружения. +Для определения установленной версии определите `WANT_WX`. Если значение не задано для конкретной версии, компоненты будут иметь суффикс версии. `HAVE_WX` будет заполнен после обнаружения. [[wx-ver-det-example]] .Обнаружение установленных версий и компонентов wxWidgets [example] ==== -Следующий фрагмент может быть использован в порту, который использует wxWidgets, в случае если он установлен или выбран соответствующий параметр. +Этот фрагмент может использоваться в порте, который использует wxWidgets, если они установлены или выбран соответствующий параметр. [.programlisting] .... @@ -1762,19 +3690,19 @@ WANT_WX= yes .include <bsd.port.pre.mk> -.if defined(WITH_WX) || !empty(PORT_OPTIONS:MWX) || !empty(HAVE_WX:Mwx-2.4) -USE_WX= 2.4 +.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.6`. +Этот фрагмент может использоваться в порте, который включает поддержку wxPython, если она установлена или выбрана соответствующая опция, в дополнение к wxWidgets, обе версии `2.8`. [.programlisting] .... -USE_WX= 2.6 +USE_WX= 2.8 WX_COMPS= wx -WANT_WX= 2.6 +WANT_WX= 2.8 .include <bsd.port.pre.mk> @@ -1787,48 +3715,46 @@ CONFIGURE_ARGS+= --enable-wxpython ==== [[wx-defined-variables]] -=== Переменные для определения +=== Переменные, определенные в фреймворке -Следующие переменные доступны в порту (после определения одной из переменных из <<wx-ver-sel-table>>). +Эти переменные доступны в порте (после определения одной из crossref:special[wx-ver-sel-table,переменных для выбора версий wxWidgets]). +[[wx-widgets-variables]] .Переменные, определенные для портов, использующих wxWidgets [cols="1,1", frame="none", options="header"] |=== -| Название +| Имя | Описание |`WX_CONFIG` -|Путь к сценарию wxWidgets `wx-config` (с другим именем) +|Путь к скрипту `wx-config` wxWidgets (с другим именем) |`WXRC_CMD` -|Путь к программе wxWidgets `wxrc` (с другим именем) +|Путь к программе `wxrc` wxWidgets (с другим именем) |`WX_VERSION` |Версия wxWidgets, которая будет использоваться (например, `2.6`) - -|`WX_UNICODE` -|Если не определена, но Unicode будет использоваться, то она будет определена |=== [[wx-premk]] === Обработка в [.filename]#bsd.port.pre.mk# -Если вам нужно использовать переменные для запуска команд сразу после подключения [.filename]#bsd.port.pre.mk#, то вам нужно определить `WX_PREMK`. +Определите `WX_PREMK`, чтобы иметь возможность использовать переменные сразу после включения [.filename]#bsd.port.pre.mk#. [IMPORTANT] ==== -Если вы определите `WX_PREMK`, то версия, зависимости, компоненты и заданные переменные не изменяться, в случае вы изменили переменные порта wxWidgets после подключения [.filename]#bsd.port.pre.mk#. +При определении `WX_PREMK` версия, зависимости, компоненты и определенные переменные не изменятся при модификации переменных порта wxWidgets _после_ включения [.filename]#bsd.port.pre.mk#. ==== [[wx-premk-example]] .Использование переменных wxWidgets в командах [example] ==== -Следующий фрагмент иллюстрирует использование переменной `WX_PREMK` посредством запуска сценария `wx-config` для получения строки с полной версией с присвоением ее переменной и передачей в программу. +Этот фрагмент иллюстрирует использование `WX_PREMK` путем запуска скрипта `wx-config` для получения полной строки версии, присвоения её переменной и передачи в программу. [.programlisting] .... -USE_WX= 2.4 +USE_WX= 2.8 WX_PREMK= yes .include <bsd.port.pre.mk> @@ -1844,15 +3770,16 @@ PLIST_SUB+= VERSION="${VER_STR}" [NOTE] ==== -Переменные wxWidgets можно безопасно использовать в командах внутри целей без необходимости в использовании `WX_PREMK`. +Переменные wxWidgets можно безопасно использовать в командах внутри целей без необходимости в `WX_PREMK`. ==== [[wx-additional-config-args]] === Дополнительные параметры `configure` -Некоторые сценарии GNU `configure` не могут найти wxWidgets только с установленной переменной окружения `WX_CONFIG`, требуя дополнительные параметры. Для их передачи можно использовать переменную `WX_CONF_ARGS`. +Некоторые скрипты GNU `configure` не могут найти wxWidgets, если задана только переменная окружения `WX_CONFIG`, и требуют дополнительные параметры. `WX_CONF_ARGS` можно использовать для их указания. -.Допустимые значения `WX_CONF_ARGS` +[[wx-conf-args-values]] +.Допустимые значения для `WX_CONF_ARGS` [cols="1,1", frame="none", options="header"] |=== | Возможное значение @@ -1868,374 +3795,465 @@ PLIST_SUB+= VERSION="${VER_STR}" [[using-lua]] == Использование Lua -Эта глава описывает статус библиотек Lua в дереве портов и их интеграцию в систему портов. +Этот раздел описывает состояние библиотек Lua в дереве портов и их интеграцию с системой портов. [[lua-introduction]] === Введение -Существует множество версий библиотек Lua и соответствующих интерпретаторов, конфликтующих между собой (устанавливают файлы под тем же именем). В дереве портов эта проблема решена путем установки каждой версии в собственное место с использованием номера версии в качестве суффикса. +Существует множество версий библиотек Lua и соответствующих интерпретаторов, которые конфликтуют между собой (устанавливают файлы с одинаковыми именами). В дереве портов эта проблема решена установкой каждой версии под разными именами с использованием суффиксов номеров версий. + +Очевидный недостаток этого заключается в том, что каждое приложение необходимо модифицировать для поиска ожидаемой версии. Однако это можно решить, добавив дополнительные флаги компилятору и компоновщику. -Очевидным недостатком этого является необходимость изменения каждого приложения для нахождения искомой версии. Но это решается добавлением некоторых дополнительных флагов для компилятора и компоновщика. +Приложения, использующие Lua, обычно должны собираться только для одной версии. Однако загружаемые модули для Lua собираются в отдельных флейворах для каждой поддерживаемой версии Lua, и зависимости от таких модулей должны указывать флейвор с использованием суффикса `@${LUA_FLAVOR}` в расположении (origin) порта. [[lua-version]] === Выбор версии -Для того, чтобы заставить ваш порт использовать конкретную версию Lua, существует две доступные для определения переменные (если определена только одна, то вторая примет значение по умолчанию): +Порт, использующий Lua, должен содержать строку следующего вида: -[[lua-ver-sel-table]] -.Переменные для выбора версии Lua -[cols="1,1,1", frame="none", options="header"] -|=== -| Переменная -| Описание -| Значение по умолчанию +[.programlisting] +.... +USES= lua +.... -|`USE_LUA` -|Перечень версий, которые порт может использовать -|Все доступные версии +Если требуется определённая версия Lua или диапазон версий, его можно указать в виде параметра `XY` (который можно использовать несколько раз), `XY+`, `-XY` или `XY-ZA`. Версия Lua, установленная через `DEFAULT_VERSIONS`, будет использована, если она попадает в запрошенный диапазон, в противном случае будет использована ближайшая к умолчанию запрошенная версия. Например: -|`USE_LUA_NOT` -|Перечень версий, которые порт не может использовать -|Пусто -|=== +[.programlisting] +.... +USES= lua:52-53 +.... -Перечень доступных версий Lua и соответствующих портов в дереве: +Обратите внимание, что не предпринимается попытка изменить выбор версии на основе наличия любой уже установленной версии Lua. -.Доступные версии Lua -[cols="1,1", frame="none", options="header"] -|=== -| Версия -| Порт +[NOTE] +==== +Форма указания версии `XY+` не должна использоваться без тщательного обдумывания; Lua API в некоторой степени меняется с каждой версией, и инструменты конфигурации, такие как CMake или Autoconf, скорее всего не будут работать с будущими версиями Lua, пока не будут обновлены для этого. +==== -|`4.0` -|package:lang/lua4[] +[[lua-version-config]] +=== Конфигурация и флаги компилятора -|`5.0` -|package:lang/lua50[] +Программное обеспечение, использующее Lua, может быть написано с автоматическим определением версии Lua в использовании. В общем случае порты должны переопределять это предположение и принудительно использовать конкретную выбранную версию Lua, как описано выше. В зависимости от портируемого программного обеспечения, это может потребовать любого или всех из следующих действий: -|`5.1` -|package:lang/lua[] -|=== +* Использование `LUA_VER` в качестве части параметра для скрипта конфигурации программного обеспечения через `CONFIGURE_ARGS` или `CONFIGURE_ENV` (или эквивалентные для других систем сборки); +* Добавление `-I${LUA_INCDIR}`, `-L${LUA_LIBDIR}` и `-llua-${LUA_VER}` в `CFLAGS`, `LDFLAGS` и `LIBS` соответственно, где это необходимо; +* Исправьте конфигурационные или файлы сборки программного обеспечения, чтобы выбрать правильную версию. + + +[[lua-version-flavors]] +=== Флейворы версии + +Порт, который устанавливает модуль Lua (а не приложение, просто использующее Lua), должен собирать отдельный флейвор для каждой поддерживаемой версии Lua. Это делается путем добавления параметра `module`: + +[.programlisting] +.... +USES= lua:module +.... + +Так же может быть указае номер версии или диапазон версий. Используйте запятую для разделения параметров. + +Поскольку каждый флейвор должен иметь уникальное имя пакета, предоставляется переменная `LUA_PKGNAMEPREFIX`, которая будет установлена в соответствующее значение; предполагаемое использование: + +[.programlisting] +.... +PKGNAMEPREFIX= ${LUA_PKGNAMEPREFIX} +.... + +Модульные порты обычно должны устанавливать файлы только в `LUA_MODLIBDIR`, `LUA_MODSHAREDIR`, `LUA_DOCSDIR` и `LUA_EXAMPLESDIR`, все из которых настроены на ссылки в версионно-зависимые подкаталоги. Установка любых других файлов должна выполняться с осторожностью, чтобы избежать конфликтов между версиями. + +Порт (кроме модуля Lua), который хочет собрать отдельный пакет для каждой версии Lua, должен использовать параметр `flavors`: + +[.programlisting] +.... +USES= lua:flavors +.... + +Это работает так же, как параметр `module`, описанный выше, но без предположения, что пакет должен быть задокументирован как модуль Lua (поэтому `LUA_DOCSDIR` и `LUA_EXAMPLESDIR` по умолчанию не определены). Однако порт может определить `LUA_DOCSUBDIR` как подходящее имя подкаталога (обычно `PORTNAME` порта, если это не конфликтует с `PORTNAME` любого модуля), и в этом случае фреймворк определит как `LUA_DOCSDIR`, так и `LUA_EXAMPLESDIR`. -Переменные из <<lua-ver-sel-table>> могут иметь комбинации из одного или нескольких значений, разделенных пробелом: +Как и в случае с модульными портами, порт с флейворами должен избегать установки файлов, которые могут конфликтовать между версиями. Обычно это достигается добавлением `LUA_VER_STR` в качестве суффикса к именам программ (например, с использованием crossref:uses[uses-uniquefiles,`uniquefiles`]), а также использованием `LUA_VER` или `LUA_VER_STR` в составе других файлов или поддиректорий, используемых вне `LUA_MODLIBDIR` и `LUA_MODSHAREDIR`. -.Определение версии Lua +[[lua-defined-variables]] +=== Переменные, определенные в фреймворке + +В порте доступны эти переменные. + +[[using-lua-variables-ports]] +.Переменные, определенные для портов, использующих Lua [cols="1,1", frame="none", options="header"] |=== +| Имя | Описание -| Пример -|Единичная версия -|`4.0` +|`LUA_VER` +|Версия Lua, которая будет использоваться (например, `5.4`) -|Восходящий диапазон -|`5.0+` +|`LUA_VER_STR` +|Версия Lua без точек (например, `54`) -|Нисходящий диапазон -|`5.0-` +|`LUA_FLAVOR` +|Имя флейвора, соответствующее выбранной версии Lua, используемое для указания зависимостей + +|`LUA_BASE` +|Префикс, который должен использоваться для поиска Lua (и компонентов), уже установленных + +|`LUA_PREFIX` +|Префикс, куда этим портом будут установлены Lua (и компоненты) + +|`LUA_INCDIR` +|Каталог, в котором установлены заголовочные файлы Lua + +|`LUA_LIBDIR` +|Каталог, в котором установлены библиотеки Lua -|Полный диапазон (обязан быть восходящим) -|`5.0-5.1` +|`LUA_REFMODLIBDIR` +|Каталог, в котором находятся уже установленные библиотеки модулей Lua ([.filename]#.so#) + +|`LUA_REFMODSHAREDIR` +|Каталог, в котором находятся установленные модули Lua ([.filename]#.lua#) + +|`LUA_MODLIBDIR` +|Каталог, в котором библиотеки модулей Lua ([.filename]#.so#) должны быть установлены данным портом + +|`LUA_MODSHAREDIR` +|Каталог, в котором должны быть установлены модули Lua ([.filename]#.lua#) данным портом + +|`LUA_PKGNAMEPREFIX` +|Префикс имени пакета, используемый модулями Lua + +|`LUA_CMD` +|Название интерпретатора Lua (например, `lua54`) + +|`LUAC_CMD` +|Название компилятора Lua (например, `luac54`) |=== -Кроме того, существует несколько переменных для выбора предпочитаемых версий из перечня доступных. Они могут быть установлены в несколько версий, первая из которых будет иметь наибольший приоритет. +Эти дополнительные переменные доступны для портов, которые указали параметр `module`: -.Переменные для выбора предпочитаемых версий Lua +[[using-lua-variables-modules]] +.Переменные, определенные для модулей Lua в портах [cols="1,1", frame="none", options="header"] |=== -| Название -| Предназначение +| Имя +| Описание -|`WANT_LUA_VER` -|порт +|`LUA_DOCSDIR` +|каталог, в который должна быть установлена документация модуля. -|`WITH_LUA_VER` -|пользователь +|`LUA_EXAMPLESDIR` +|каталог, в который должны быть установлены примеры файлов модуля. |=== -[[lua-version-example]] -.Выбор версии Lua +[[lua-examples]] +=== Примеры + +[[lua-app-Makefile]] +.`Makefile` для приложения, использующего Lua [example] ==== -Следующий фрагмент взят из порта, который использует Lua версий `5.0` или `5.1`, по умолчанию `5.0`. Значение может быть переопределено пользователем с использованием переменной `WITH_LUA_VER`. +Этот пример показывает, как сослаться на модуль Lua, требуемый во время выполнения. Обратите внимание, что ссылка должна указывать флейвор. [.programlisting] .... -USE_LUA= 5.0-5.1 -WANT_LUA_VER= 5.0 +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> .... ==== -[[lua-components]] -=== Выбор компонентов - -Существуют другие приложения, которые хотя и не являются библиотеками Lua, но относятся к ним. Эти приложения можно указать в переменной `LUA_COMPS`. Доступны следующие компоненты: +[[lua-mod-Makefile]] +.`Makefile` для простого модуля Lua +[example] +==== +[.programlisting] +.... +PORTNAME= sample +DISTVERSION= 1.2.3 +CATEGORIES= whatever +PKGNAMEPREFIX= ${LUA_PKGNAMEPREFIX} -.Доступные компоненты Lua -[cols="1,1,1", frame="none", options="header"] -|=== -| Название -| Описание -| Ограничение версии +MAINTAINER= fred.bloggs@example.com +COMMENT= Sample +WWW= https://example.com/lua_sample/sample/ -|`lua` -|Основная библиотека -|нет +USES= lua:module -|`tolua` -|Библиотека доступа к коду C/C++ -|4.0-5.0 +DOCSDIR= ${LUA_DOCSDIR} -|`ruby` -|Привязка к Ruby -|4.0-5.0 -|=== +.include <bsd.port.mk> +.... -[NOTE] -==== -Есть и другие компоненты, но они относятся к модулям для интерпретатора и не используются приложениями (только другими модулями). ==== -Тип зависимости можно выбрать для каждого компонента через добавление суффикса, отделенного точкой с запятой. В случае отсутствия будет использован тип по умолчанию (смотрите <<lua-def-dep-types>>). Доступные следующие типы: +[[using-guile]] +== Использование Guile -.Доступные типы зависимости Lua -[cols="1,1", frame="none", options="header"] -|=== -| Название -| Описание +Этот раздел описывает состояние Guile в дереве портов и его интеграцию с системой портов. -|`build` -|Компонент требуется для построения, эквивалентен `BUILD_DEPENDS` +[[guile-introduction]] +=== Введение -|`run` -|Компонент требуется для запуска, эквивалентен `RUN_DEPENDS` +Существует несколько версий библиотек Guile и соответствующих интерпретаторов, которые конфликтуют между собой (устанавливают файлы с одинаковыми именами). В дереве портов эта проблема решена путем установки каждой версии под разными именами с использованием суффиксов номеров версий. В большинстве случаев приложения должны определять правильную версию из предоставленных конфигурационных переменных и использовать `pkg-config` для определения имени и связанных путей. Однако некоторые приложения (особенно те, которые используют собственные правила конфигурации для `cmake` или `meson`) всегда будут пытаться использовать последнюю доступную версию. В этом случае либо исправьте порт, либо объявите конфликт сборки (см. опцию `conflicts` ниже), чтобы гарантировать создание правильной зависимости при сборке вне poudriere. -|`lib` -|Компонент требуется для построения и запуска, эквивалентен `LIB_DEPENDS` -|=== +Приложения, использующие Guile, обычно должны собираться только для одной версии, предпочтительно указанной в `DEFAULT_VERSIONS`, или, если это невозможно, для последней поддерживаемой версии. Однако библиотеки Guile или Scheme, а также модули расширения для Guile собираются в отдельных флейворах для каждой поддерживаемой версии Guile. Зависимости от таких портов должны указывать флейвор с использованием суффикса `@${GUILE_FLAVOR}` в расположении (origin) порта. -Значения по умолчанию для компонентов подробно рассматриваются в следующей таблице: +[[guile-version]] +=== Выбор версии -[[lua-def-dep-types]] -.Типы зависимости Lua, используемые по умолчанию -[cols="1,1", frame="none", options="header"] +Порт, использующий Guile, должен определять `USES=guile:__arg,arg...__` с соответствующими параметрами следующим образом: + +[[guile-defined-uses-args]] +.Параметры, определенные для портов, использующих Guile +[cols="1m,4", frame="none", options="header"] |=== -| Компонент -| Тип зависимости +| Имя +| Описание + +|_X.Y_ +|Объявить совместимость с версией Guile `X.Y`. +Доступные версии: `1.8` (устарела), `2.2` и `3.0`. +Можно указать несколько версий. + +|flavors +|Создать флейвор для каждой указанной версии Guile. +Версия, указанная в `DEFAULT_VERSIONS`, станет флейвором по умолчанию. +Названия флейворов имеют вид `guileXY`. -|`lua` -|`lib` для `4.0-5.0` (динамическая) и `build` для `5.1` (статическая) +|build +|Добавить интерпретатор Guile только как зависимость для сборки, а не как зависимость библиотеки. +`build` и `run` могут быть указаны оба. -|`tolua` -|`build` (статическая) +|run +|Добавить интерпретатор Guile только как зависимость во время выполнения, а не как зависимость от библиотеки. +`build` и `run` могут быть указаны оба. -|`ruby` -|`lib` (динамическая) +|alias +|Добавить значения `BINARY_ALIAS` для интерпретатора и инструментов. + +|conflicts +|Объявить `CONFLICTS_BUILD` для версий Guile новее выбранной. +Используйте это, когда порт нельзя настроить на использование определённой версии Guile. |=== -[[lua-components-example]] -.Выбор компонентов Lua -[example] -==== -Следующий фрагмент соответствует порту, использующему Lua версии `4.0` и привязку к Ruby. +Некоторые дополнительные аргументы доступны для обработки нестандартных случаев; подробности см. в `Mk/Uses/guile.mk`. -[.programlisting] -.... -USE_LUA= 4.0 -LUA_COMPS= lua ruby -.... +Если не указано `build` или `run`, то `LIB_DEPENDS` получает зависимость от библиотеки `libguile`, а также любые дополнительные зависимости, требуемые версией guile, например, `libgc`. Обычно порту не требуются дополнительные зависимости, связанные с использованием Guile. -==== +[[guile-version-config]] +=== Флаги конфигурации -[[lua-version-detection]] -=== Обнаружение установленных версий +Программное обеспечение, использующее Guile, должно использовать механизм `pkg-config` для получения флагов компилятора и компоновщика. Некоторые старые или экзотические порты могут использовать `guile-config` или получать значения напрямую из `guile`, что также должно работать (в некоторых из этих случаев может быть полезен аргумент `alias`). -Для обнаружения установленной версии вам необходимо задать переменную `WANT_LUA`. Если вы не присвоите ей определенную версию, то компоненты получат суффикс версии. Переменная `HAVE_LUA` будет заполнена после обнаружения. +Фреймворк пытается сообщить порту желаемую версию Guile, используя следующие методы: -[[lua-ver-det-example]] -.Обнаружение установленных версий и компонентов Lua -[example] -==== -Следующий фрагмент можно использовать для порта, использующего Lua, если она установлена, или был выбран соответствующий параметр. +* `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` и т.д. -[.programlisting] -.... -WANT_LUA= yes +Для некоторых портов может потребоваться указать версию дополнительными способами, например, через `CONFIGURE_ARGS` или `MESON_ARGS`, в зависимости от порта. -.include <bsd.port.pre.mk> +Если ни один из этих методов не приводит к тому, что порт выбирает указанную версию Guile при наличии других версий, то предпочтительно исправить его, чтобы это происходило. Если это невозможно, укажите опцию `conflicts`, чтобы предотвратить сборку порта в условиях, когда он обнаруживает неправильную версию. -.if defined(WITH_LUA5) || !empty(PORT_OPTIONS:MLUA5) || !empty(HAVE_LUA:Mlua-5.[01]) -USE_LUA= 5.0-5.1 -CONFIGURE_ARGS+= --enable-lua5 -.endif -.... +[[guile-version-flavors]] +=== Флейворы версии + +Порт, который устанавливает расширение или библиотеку Guile, или библиотеку Scheme, которая предварительно компилируется для Guile, должен собирать отдельный флейвор для каждой поддерживаемой версии Guile. Это делается путем добавления опции `flavors`. -Следующий фрагмент можно использовать для порта, который включает поддержку tolua, если такой компонент установлен, или был выбран соответствующий параметр в дополнение к Lua, оба имеют версию `4.0`. +Поскольку каждый флейвор должен иметь уникальное имя пакета, такие порты обычно устанавливают `PKGNAMESUFFIX`, например: [.programlisting] .... -USE_LUA= 4.0 -LUA_COMPS= lua -WANT_LUA= 4.0 +PKGNAMESUFFIX= -${FLAVOR} +.... -.include <bsd.port.pre.mk> +Такие порты должны устанавливать файлы Scheme в `GUILE_SITE_DIR`, а не в `GUILE_GLOBAL_SITE_DIR`, даже если файлы не зависят от версии. Это часто требует исправления порта. -.if defined(WITH_TOLUA) || !empty(PORT_OPTIONS:MTOLUA) || !empty(HAVE_LUA:Mtolua) -LUA_COMPS+= tolua -CONFIGURE_ARGS+= --enable-tolua -.endif -.... +Кроме того, если такой порт устанавливает файл `.pc`, он должен быть размещён в `GUILE_PKGCONFIG_PATH`, а не в глобальной директории `pkgconfig`. Это позволяет зависимым портам находить правильную конфигурацию для используемой версии Guile. -==== +Если порт расширения Guile устанавливает файл `.so`, то обычно он должен быть размещён в специфичной для версии Guile директории `extensions`. Обычно не следует использовать `USE_LDCONFIG`. -[[lua-defined-variables]] -=== Переменные для определения +Любые другие файлы, устанавливаемые портом с флейвором, также должны находиться в версионных каталогах или использовать версионные имена файлов. Для документации и примеров переменные `GUILE_DOCS_DIR` и `GUILE_EXAMPLES_DIR` указывают подходящие расположения, в которых порт должен создать подкаталог (см. ниже). -Следующие переменные доступны в порту (после определения одной из переменных из <<lua-ver-sel-table>>). +[[guile-defined-variables]] +=== Переменные, определенные в фреймворке -.Переменные, определенные для портов, использующих Lua -[cols="1,1", frame="none", options="header"] +В порте доступны эти переменные. + +[[using-guile-variables-ports]] +.Переменные, определенные для портов, использующих Guile +[cols="1,3m,6", frame="none", options="header"] |=== -| Название +| Имя +| Пример значения | Описание -|`LUA_VER` -|Версия Lua, которая будет использоваться (например, `5.1`) +|`GUILE_VER` +|3.0 +|Используемая версия Guile. -|`LUA_VER_SH` -|Старший номер версии динамической библиотеки Lua (например, `1`) +|`GUILE_SFX` +|3 +|Короткий суффикс, используемый в некоторых именах. +Используйте с осторожностью; может быть неуникальным или измениться в будущем. -|`LUA_VER_STR` -|Версия Lua без точки (например, `51`) +|`GUILE_FLAVOR` +|guile30 +|Название флейвора, соответствующее выбранной версии. -|`LUA_PREFIX` -|Префикс, в который установлена Lua (и компоненты) +|`GUILE_PORT` +|lang/guile3 +|Расположение порта (origin) для указанной версии Guile. -|`LUA_SUBDIR` -|Каталог под [.filename]#${PREFIX}/bin#, [.filename]#${PREFIX}/share# и [.filename]#${PREFIX}/lib#, в который установлена Lua +|`GUILE_PREFIX` +|${PREFIX} +|Префикс каталога для использования при установке. -|`LUA_INCDIR` -|Каталог, в который установлены заголовочные файлы Lua и tolua +|`GUILE_CMD` +|guile-3.0 +|Имя интерпретатора Guile с суффиксом версии. -|`LUA_LIBDIR` -|Каталог, в который установлены библиотеки Lua и tolua +|`GUILE_CMDPATH` +|${LOCALBASE}/bin/guile-3.0 +|Полный путь к интерпретатору Guile. -|`LUA_MODLIBDIR` -|Каталог, в который установлены модули библиотеки Lua ([.filename]#.so#) +|`GUILD_CMD` +|guild-3.0 +|Название инструмента Guild, с суффиксом версии. -|`LUA_MODSHAREDIR` -|Каталог, в который установлены модули Lua ([.filename]#.lua#) +|`GUILD_CMDPATH` +|`${LOCALBASE}/bin/guild-3.0` +|Полный путь к инструменту Guild. -|`LUA_PKGNAMEPREFIX` -|Префикс с именем пакета, используемый модулями Lua +|`++GUILE_*_CMD++` + +`++GUILE_*_CMDPATH++` +| +|Как `GUILE_CMD` и `GUILE_CMDPATH`, но для других исполняемых файлов утилит. -|`LUA_CMD` -|Путь к интерпретатору Lua +|`GUILE_PKGCONFIG_PATH` +|${LOCALBASE}/libdata/pkgconfig/guile/3.0 +|Где пакеты, использующие `flavors`, должны устанавливать файлы `.pc`. -|`LUAC_CMD` -|Путь к компилятору Lua +|`GUILE_INFO_PATH` +|share/info/guile3 +|Подходящее значение для `INFO_PATH` для портов, использующих опцию `flavors`. +|=== -|`TOLUA_CMD` -|Путь к программе tolua +Следующие элементы определены как переменные и как записи `PLIST_SUB`. Форма переменной имеет суффикс `_DIR` и представляет собой полный путь (с префиксом `GUILE_PREFIX`). + +[[using-guile-path-variables-ports]] +.Подстановки путей, определенные для портов, использующих Guile +[cols="1m,3m,6", frame="none", options="header"] |=== +| Имя +| Пример значения +| Описание -[[lua-variables-example]] -.Указание для порта, где искать Lua -[example] -==== -Следующий фрагмент показывает, как сообщить порту, который использует сценарий configure, где расположены заголовочные файлы и библиотеки Lua. +|GUILE_GLOBAL_SITE +|share/guile/site +|Каталог сайта, общий для всех версий guile; обычно не должен использоваться. -[.programlisting] -.... -USE_LUA= 4.0 -GNU_CONFIGURE= yes -CONFIGURE_ENV= CPPFLAGS="-I${LUA_INCDIR}" LDFLAGS="-L${LUA_LIBDIR}" -.... +|GUILE_SITE +|share/guile/3.0/site +|Каталог сайта для выбранной версии Guile. -==== +|GUILE_SITE_CCACHE +|lib/guile/3.0/site-ccache +|Каталог для скомпилированных файлов байт-кода. -[[lua-premk]] -=== Обработка в [.filename]#bsd.port.pre.mk# +|GUILE_DOCS +|share/doc/guile30 +|Родительский каталог для документации, специфичной для версий. -Если вам нужно использовать переменные для запуска команд сразу после подключения [.filename]#bsd.port.pre.mk#, для этого вам нужно определить переменную `LUA_PREMK`. +|GUILE_EXAMPLES +|share/examples/guile30 +|Родительский каталог для примеров, специфичных для версий. +|=== -[IMPORTANT] -==== -Если вы задаете `LUA_PREMK`, то версия, зависимости, компоненты и уже заданные переменные не будут изменены, в случае если вы изменили переменные порта Lua после подключения [.filename]#bsd.port.pre.mk#. -==== +[[guile-examples]] +=== Примеры -[[lua-premk-example]] -.Использование переменных Lua в командах +[[guile-app-Makefile]] +.`Makefile` для приложения, использующего Guile [example] ==== -Следующий фрагмент иллюстрирует использование `LUA_PREMK` посредством запуска интерпретатора Lua для того, чтобы получить строку с полной версией, сохранить ее в переменную и передать программе. +Этот пример демонстрирует, как сослаться на библиотеку Guile, необходимую во время сборки и выполнения. Обратите внимание, что ссылка должна указывать флейвор. В этом примере предполагается, что приложение использует `pkg-config` для поиска зависимостей. [.programlisting] .... -USE_LUA= 5.0 -LUA_PREMK= yes +PORTNAME= sample +DISTVERSION= 1.2.3 +CATEGORIES= whatever -.include <bsd.port.pre.mk> +MAINTAINER= fred.bloggs@example.com +COMMENT= Sample +WWW= https://example.com/guile_sample/sample/ -.if exists(${LUA_CMD}) -VER_STR!= ${LUA_CMD} -v +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} -CFLAGS+= -DLUA_VERSION_STRING="${VER_STR}" -.endif -.... +USES= guile:2.2,3.0 pkgconfig -==== +.include <bsd.port.mk> +.... -[NOTE] -==== -Переменные Lua можно безопасно использовать в командах внутри целей без необходимости в использовании `LUA_PREMK`. ==== [[using-iconv]] == Использование `iconv` -После 10-08-2013 (link:https://svnweb.freebsd.org/changeset/base/254273[r254273]) в составе FreeBSD 10-CURRENT и более новых версий имеется собственный `iconv`. В более ранних версиях дополнительной зависимостью выступал package:converters/libiconv[]. +В FreeBSD имеется встроенная реализация `iconv` в самой операционной системе. -Для программного обеспечения, которому нужен `iconv`, определите `USES=iconv`. Версии FreeBSD до 10-CURRENT от 13-08-2013 (link:https://svnweb.freebsd.org/changeset/base/254273[r254273]) не имеют собственного `iconv`. На этих более ранных версиях будет автоматически добавлена зависимость от package:converters/libiconv[]. +Для программного обеспечения, требующего `iconv`, определите `USES=iconv`. -Когда порт задаёт `USES=iconv`, становятся доступными следующие переменные: +Когда порт определяет `USES=iconv`, становятся доступны следующие переменные: [.informaltable] [cols="1,1,1,1", frame="none", options="header"] |=== | Имя переменной | Назначение -| Значение до FreeBSD 10-CURRENT 254273 (13-08-2013) -| Значение после FreeBSD 10-CURRENT 254273 (13-08-2013) +| Порт iconv (при использовании расширений WCHAR_T или //TRANSLIT) +| Базовый iconv + |`ICONV_CMD` -|Каталог размещения двоичного файла `iconv` +|Каталог, в котором находится бинарный файл `iconv` |`${LOCALBASE}/bin/iconv` |[.filename]#/usr/bin/iconv# |`ICONV_LIB` -|Аргумент `ld` для компоновки с [.filename]#libiconv# (если нужно) +|аргумент `ld` для линковки с [.filename]#libiconv# (если требуется) |`-liconv` |(пусто) |`ICONV_PREFIX` -|Каталог размещения реализации `iconv` (используется для сценариев конфигурации) +|Каталог, в котором находится реализация `iconv` (полезно для скриптов configure) |`${LOCALBASE}` |[.filename]#/usr# |`ICONV_CONFIGURE_ARG` -|Параметр предварительно собранной конфигурации для сценариев конфигурации +|Предварительно сконструированный аргумент configure для скриптов configure |`--with-libiconv-prefix=${LOCALBASE}` |(пусто) |`ICONV_CONFIGURE_BASE` -|Параметр предварительно собранной конфигурации для сценариев конфигурации +|Предварительно сконструированный аргумент configure для скриптов configure |`--with-libiconv=${LOCALBASE}` |(пусто) |=== -В следующих двух примерах демонстрируется автоматическое присвоение переменным правильных значений для систем, использующих package:converters/libiconv[] или собственный `iconv`. +Эти два примера автоматически заполняют переменные правильным значением для систем, использующих package:converters/libiconv[] или `iconv`, входящий в состав операционной системы, соответственно: [[iconv-simple-use]] .Простое использование `iconv` @@ -2261,12 +4279,12 @@ CONFIGURE_ARGS+=${ICONV_CONFIGURE_ARG} ==== -Как показано выше, `ICONV_LIB` имеет пустое значение с собственным `iconv`. Эту особенность можно использовать для обнаружения собственного `iconv` с соответствующими действиями. +Как показано выше, `ICONV_LIB` пуста, когда присутствует встроенный `iconv`. Это можно использовать для обнаружения встроенного `iconv` и действовать соответственно. -Иногда в программе параметр `ld` или путь поиска жёстко заданы в [.filename]#Makefile# или сценарии конфигурации. Для решения этой проблемы можно использовать следующий подход: +Иногда в программе аргумент `ld` или путь поиска жестко заданы в [.filename]#Makefile# или скрипте configure. Для решения этой проблемы можно использовать следующий подход: [[iconv-reinplace]] -.Исправление жёстко заданного `-liconv` +.Исправление жестко заданного `-liconv` [example] ==== [.programlisting] @@ -2279,10 +4297,10 @@ post-patch: ==== -В некоторых случаях необходимо установить альтернативные значения или выполнить операции в случае использования собственного `iconv`. Перед проверкой значения `ICONV_LIB` обязан быть подключён [.filename]#bsd.port.pre.mk#: +В некоторых случаях необходимо установить альтернативные значения или выполнить операции в зависимости от наличия встроенного `iconv`. [.filename]#bsd.port.pre.mk# должен быть включен до проверки значения `ICONV_LIB`: [[iconv-conditional]] -.Проверка доступности собственного `iconv` +.Проверка доступности встроенной поддержки `iconv` [example] ==== [.programlisting] @@ -2293,7 +4311,7 @@ USES= iconv post-patch: .if empty(ICONV_LIB) - # обнаружен собственный iconv + # native iconv detected @${REINPLACE_CMD} -e 's|iconv||' ${WRKSRC}/Config.sh .endif @@ -2305,126 +4323,239 @@ post-patch: [[using-xfce]] == Использование Xfce -Переменная `USE_XFCE` используется для автоматической конфигурации зависимостей для портов, использующих библиотеки или приложения на основе Xfce, такие как package:x11-toolkits/libxfce4gui[] и package:x11-wm/xfce4-panel[]. +Порты, которым требуются библиотеки или приложения Xfce, устанавливают `USES=xfce`. -В настоящее время распознаются следующие библиотеки и приложения Xfce: +Конкретные зависимости библиотек и приложений Xfce задаются с помощью значений, присвоенных `USE_XFCE`. Они определены в [.filename]#/usr/ports/Mk/Uses/xfce.mk#. Возможные значения: -* libexo: package:x11/libexo[] -* libgui: package:x11-toolkits/libxfce4gui[] -* libutil: package:x11/libxfce4util[] -* libmcs: package:x11/libxfce4mcs[] -* mcsmanager: package:sysutils/xfce4-mcs-manager[] -* panel: package:x11-wm/xfce4-panel[] -* thunar: package:x11-fm/thunar[] -* wm: package:x11-wm/xfce4-wm[] -* xfdev: package:dev/xfce4-dev-tools[] +.Значения `USE_XFCE` +garcon:: +package:sysutils/garcon[] -Распознаются следующие дополнительные параметры: +libexo:: +package:x11/libexo[] + +libgui:: +package:x11-toolkits/libxfce4gui[] + +libmenu:: +package:x11/libxfce4menu[] + +libutil:: +package:x11/libxfce4util[] + +panel:: +package:x11-wm/xfce4-panel[] + +thunar:: +package:x11-fm/thunar[] + +xfconf:: +package:x11/xfce4-conf[] + +[[use-xfce]] +.Пример `USES=xfce` +[example] +==== +[.programlisting] +.... +USES= xfce +USE_XFCE= libmenu +.... + +==== + +[[use-xfce-gtk2]] +.Использование собственных виджетов GTK2 в Xfce +[example] +==== +В этом примере портированное приложение использует пакет виджетов, специфичных для GTK2: package:x11/libxfce4menu[] и package:x11/xfce4-conf[]. -* configenv: Используйте, если ваш порт требует специально измененного значения `CONFIGURE_ENV` для поиска требуемых для порта библиотек. -+ [.programlisting] .... --I${LOCALBASE}/include -L${LOCALBASE}/lib +USES= xfce:gtk2 +USE_XFCE= libmenu xfconf .... -+ -добавляется в CPPFLAGS к `CONFIGURE_ENV`. +==== -Следовательно, если у порта имеется зависимость от package:sysutils/xfce4-mcs-manager[], и порт требует специальных CPPFLAGS в своем окружении configure, то синтаксис будет следующим: +[TIP] +==== +Компоненты Xfce, включённые таким образом, автоматически загрузят все необходимые зависимости. Указывать полный список больше не требуется. Если порту нужен только package:x11-wm/xfce4-panel[], используйте: [.programlisting] .... -USE_XFCE= mcsmanager configenv +USES= xfce +USE_XFCE= panel .... -[[using-mozilla]] -== Использование Mozilla +Нет необходимости перечислять компоненты package:x11-wm/xfce4-panel[], которые ему самому требуются, вот так: -.Переменные для портов, использующих Mozilla -[cols="1,1", frame="none"] -|=== -|`USE_GECKO` -|Один из бэкэндов Gecko, с которым может работать порт. Возможные значения: `libxul` ([.filename]#libxul.so#), `seamonkey` ([.filename]#libgtkembedmoz.so#, устаревший, больше не должен использоваться). +[.programlisting] +.... +USES= xfce +USE_XFCE= libexo libmenu libutil panel +.... + +Однако компоненты Xfce и зависимости порта, не относящиеся к Xfce, должны быть явно включены. Не рассчитывайте, что компонент Xfce предоставит дополнительную зависимость, кроме себя, для основного порта. +==== + +[[using-budgie]] +== Использование Budgie + +Приложения или библиотеки, зависящие от рабочего стола Budgie, должны указывать `USES= budgie` и устанавливать `USE_BUDGIE` в список необходимых компонентов. -|`USE_FIREFOX` -|Для запуска порта требуется Firefox. Возможные значения: `yes` (версия по умолчанию), `40`, `36`, `35`. По умолчанию устанавливает зависимость от версии `40`. +[cols="1,1", frame="none", options="header"] +|=== +| Имя +| Описание -|`USE_FIREFOX_BUILD` -|Для построения порта требуется Firefox. Возможные значения: смотрите USE_FIREFOX. Автоматически устанавливает USE_FIREFOX с присвоением того же значения. +| `libbudgie` +| Ядро рабочего стола (библиотека) -|`USE_SEAMONKEY` -|Для запуска порта требуется SeaMonkey. Возможные значения: `yes` (версия по умолчанию), `20`, `11` (устарело, больше не должно использоваться). По умолчанию устанавливает зависимость от версии `20`. +| `libmagpie` +| Оконный менеджер X11 и библиотека композитинга Budgie -|`USE_SEAMONKEY_BUILD` -|Для построения порта требуется SeaMonkey. Возможные значения: смотрите USE_SEAMONKEY. Автоматически устанавливает USE_SEAMONKEY с присвоением того же значения. +| `raven` +| Универсальный центр в панели для доступа к различным виджетам приложений -|`USE_THUNDERBIRD` -|Для запуска порта требуется Thunderbird. Возможные значения: `yes` (версия по умолчанию), `31`, `30` (устарело, больше не должно использоваться). По умолчанию устанавливает зависимость от версии `31`. +| `screensaver` +| Рабочий стол: специальная заставка -|`USE_THUNDERBIRD_BUILD` -|Для построения порта требуется Thunderbird. Возможные значения: смотрите USE_THUNDERBIRD. Автоматически устанавливает USE_THUNDERBIRD с присвоением того же значения. |=== -Полный перечень доступных переменных можно получить в файле [.filename]#/usr/ports/Mk/bsd.gecko.mk#. +[NOTE] +==== +Все виджеты приложений взаимодействуют через службу *org.budgie_desktop.Raven*. + +Зависимость по умолчанию включает время сборки и выполнения, её можно изменить с помощью `:build` или `:run`, например: + +[.programlisting] +.... +USES= budgie +USE_BUDGIE= screensaver:build +.... +==== + +[[budgie-components-example]] +.Пример `USE_BUDGIE` +[example] +==== +[.programlisting] +.... +USES= budgie gettext gnome meson pkgconfig +USE_BUDGIE= libbudgie +.... +==== [[using-databases]] == Использование баз данных -.Переменные для портов, использующих базы данных +Используйте один из макросов `USES` из crossref:special[using-databases-uses,Макросы `USES` для баз данных], чтобы добавить зависимость от базы данных. + +[[using-databases-uses]] +.Макросы `USES` для баз данных [cols="1,1", frame="none", options="header"] |=== -| Переменная -| Значение +| База данных +| Макрос USES -|`USE_BDB` -|Если переменная установлена в `yes`, добавляет зависимость от порта package:databases/db41[]. Также переменной можно присвоить значения: 2, 3, 40, 41, 42, 43, 44, 46, 47, 48 или 51. Вы можете объявить диапазон принимаемых значений, `USE_BDB`=42+ будет искать установленную версию с наибольшим номером, и, если ничего не установлено, вернется к 42. +|Berkeley DB +|crossref:uses[uses-bdb,`bdb`] -|`USE_MYSQL` -|Если переменная установлена в `yes`, добавляет зависимость от порта package:databases/mysql55-client[]. Как связанная переменная, `WANT_MYSQL_VER` может быть установлена в значение 323, 40, 41, 50, 51, 52, 55 или 60. +|MariaDB, MySQL, Percona +|crossref:uses[uses-mysql,`mysql`] -|`USE_PGSQL` -|Если установлена в `yes`, добавляет зависимость от порта package:databases/postgresql90-client[]. Как связанная переменная, `WANT_PGSQL_VER` может быть установлена в значение 83, 84, 90, 91 или 92. Вы можете указать максимальное и минимальное значения; `WANT_PGSQL_VER=90+` сделает порт зависимым от минимальной версии 9.0. +|PostgreSQL +|crossref:uses[uses-pgsql,`pgsql`] -|`USE_SQLITE` -|Если переменная имеет значение `yes`, добавляет зависимость от порта package:databases/sqlite3[]. Переменная может принимать значения: 3, 2. +|SQLite +|crossref:uses[uses-sqlite,`sqlite`] |=== -Подробнее смотрите в http://svnweb.FreeBSD.org/ports/head/Mk/bsd.database.mk?view=markup[bsd.database.mk]. +[[using-databases-bdb-ex1]] +.Использование Berkeley DB 6 +[example] +==== +[.programlisting] +.... +USES= bdb:6 +.... + +См. crossref:uses[uses-bdb,`bdb`] для получения дополнительной информации. +==== + +[[using-databases-mysql-ex1]] +.Использование MySQL +[example] +==== +Когда порту требуется клиентская библиотека MySQL, добавьте + +[.programlisting] +.... +USES= mysql +.... + +См. crossref:uses[uses-mysql,`mysql`] для получения дополнительной информации. +==== + +[[using-databases-pgsql-ex1]] +.Использование PostgreSQL +[example] +==== +Когда порту требуется сервер PostgreSQL версии 9.6 или новее, добавьте + +[.programlisting] +.... +USES= pgsql:9.6+ +WANT_PGSQL= server +.... + +См. crossref:uses[uses-pgsql,`pgsql`] для получения дополнительной информации. +==== + +[[using-databases-sqlite-ex1]] +.Использование SQLite 3 +[example] +==== +[.programlisting] +.... +USES= sqlite:3 +.... + +См. crossref:uses[uses-sqlite,`sqlite`] для получения дополнительной информации. +==== [[rc-scripts]] -== Запуск и остановка служб (сценарии `rc`) +== Запуск и остановка служб (скрипты `rc`) -Сценарии [.filename]#rc.d# используются для запуска служб при запуске системы и дают администратору стандартный способ остановки, запуска и перезапуска службы. Порты интегрируются в системную инфраструктуру [.filename]#rc.d#. Подробности по её использованию можно найти в extref:{handbook}config-tuning/[главе rc.d Руководства, configtuning-rcd]. Подробное объяснение доступных команд находится в man:rc[8] и man:rc.subr[8]. Наконец, есть extref:{rc-scripting}[статья]о практических аспектах написания сценариев [.filename]#rc.d#. +[.filename]#rc.d# скрипты используются для запуска служб при загрузке системы, а также предоставляют администраторам стандартный способ остановки, запуска и перезапуска служб. Порты интегрируются в систему [.filename]#rc.d#. Подробности использования можно найти в extref:{handbook}[соответствующей главе Handbook, configtuning-rcd]. Детальное объяснение доступных команд приведено в man:rc[8] и man:rc.subr[8]. Наконец, существует extref:{rc-scripting}[статья], посвящённая практическим аспектам написания [.filename]#rc.d# скриптов. -Установить можно один или более сценариев [.filename]#rc.d#: +С мифическим портом под названием _doorman_, которому необходимо запустить демон _doormand_. Добавьте следующее в [.filename]#Makefile#: [.programlisting] .... USE_RC_SUBR= doormand .... -Сценарии обязаны размещаться в подкаталоге [.filename]#files# с обязательным добавлением суффикса `.in` к имени файла. Для этого файла будут использоваться стандартные расширения `SUB_LIST`. Также особенно приветствуется использование расширений `%%PREFIX%%` и `%%LOCALBASE%%`. Подробнее о `SUB_LIST` в <<using-sub-files,соответствующей главе>>. +Можно указать несколько скриптов, которые будут установлены. Скрипты должны быть размещены в подкаталоге [.filename]#files#, и к их имени должен быть добавлен суффикс `.in`. Для этого файла будут выполнены стандартные подстановки `SUB_LIST`. Также настоятельно рекомендуется использовать подстановки `%%PREFIX%%` и `%%LOCALBASE%%`. Подробнее о `SUB_LIST` см. в crossref:pkg-files[using-sub-files,соответствующем разделе]. -Начиная с FreeBSD 6.1-RELEASE локальные сценарии [.filename]#rc.d# (включая установленные из портов) включены в общий man:rcorder[8] основной системы. +Начиная с FreeBSD 6.1-RELEASE, локальные скрипты [.filename]#rc.d# (включая те, что установлены через порты) включены в общий man:rcorder[8] базовой системы. -Пример простого сценария [.filename]#rc.d#: +Пример простого скрипта [.filename]#rc.d# для запуска демона doormand: [.programlisting] .... #!/bin/sh -# $FreeBSD$ -# # PROVIDE: doormand # REQUIRE: LOGIN # KEYWORD: shutdown # -# Add the following lines to /etc/rc.conf.local or /etc/rc.conf +# 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 doorman. +# Set it to YES to enable doormand. # doormand_config (path): Set to %%PREFIX%%/etc/doormand/doormand.cf # by default. @@ -2446,73 +4577,76 @@ command_args="-p $pidfile -f $doormand_config" run_rc_command "$1" .... -Если нет стоящей причины запускать службы раньше всех портов, сценарии должны использовать +Если нет очень веской причины запускать службу раньше или она работает от имени определенного пользователя (не root), все скрипты портов должны использовать: [.programlisting] .... REQUIRE: LOGIN .... -Если служба работает под определенным пользователем (отличным от root), то это делается принудительно. В сценарий выше включена конструкция +Если скрипт запуска демона требует его остановки, следующий код активирует остановку службы при выключении системы: [.programlisting] .... KEYWORD: shutdown .... -потому что вымышленный порт, который мы используем в качестве примера, запускает службу, и она должна корректно завершиться при выключении системы. Если сценарий не запускает постоянную службу, то это не является необходимым. +Если скрипт не запускает постоянную службу, это не требуется. -Для необязательных элементов конфигурации присвоение переменной по умолчанию в стиле "=" является более предпочтительным по сравнению со стилем ":=", используемым здесь, поскольку первый устанавливает значение по умолчанию только если переменная не установлена, а последний устанавливает её, если переменная не установлена _или_ обнулена. Пользователь вполне может написать в своем файле [.filename]#rc.conf.local# что-нибудь типа +Для необязательных элементов конфигурации предпочтительнее использовать стиль присваивания переменных по умолчанию "=" вместо стиля ":=", так как первый устанавливает значение по умолчанию только если переменная не задана, а второй — если переменная не задана _или_ равна null. Пользователь может включить что-то вроде: [.programlisting] .... doormand_flags="" .... -и тогда произойдет неуместная подстановка переменной с использованием ":=", что переопределит намерения пользователя. Переменная `_enable` является обязательной; значением по умолчанию должно быть ":". +в свой [.filename]#rc.conf.local#, а подстановка переменной с использованием ":=" некорректно переопределила бы намерение пользователя. Переменная `_enable` не является опциональной и должна использовать ":" для значения по умолчанию. + +[IMPORTANT] +==== +Порты _не должны_ запускать и останавливать свои службы при установке и удалении. Не злоупотребляйте ключевыми словами [.filename]#plist#, описанными в crossref:plist[plist-keywords-base-exec, "разделе @preexec command,@postexec command,@preunexec command,@postunexec command"], выполняя команды, которые изменяют работающую систему, включая запуск или остановку служб. +==== -=== Контрольный список перед внесением изменений +[[rc-scripts-checklist]] +=== Pre-Commit Checklist -Перед тем, как отсылать порт со сценарием [.filename]#rc.d#, и тем более перед его коммитом, сверьтесь со следующим контрольным списком, чтобы убедиться, что порт для этого готов. +Прежде чем внести порт с [.filename]#rc.d# скриптом, и что более важно, перед его коммитом, пожалуйста, ознакомьтесь с этим контрольным списком, чтобы убедиться, что он готов. -Большинство из этих проверок умеет выполнять порт package:devel/rclint[], но это не является заменой надлежащему просмотру. +Порт package:devel/rclint[] может проверить большинство из них, но он не заменяет тщательного просмотра и проверки. [.procedure] -==== -. Если это новый файл, заканчивается ли он на [.filename]#.sh#? Если это так, то имя файла должно быть изменено на [.filename]#file.in#, поскольку файлы [.filename]#rc.d# не могут оканчиваться на такое расширение. -. Присутствует ли в файле тег `$FreeBSD$`? -. Соответствуют ли друг другу имя файла (без [.filename]#.in#), строка `PROVIDE` и ``$``__name__? Имя файла, совпадающее с `PROVIDE`, упрощает отладку, особенно для проблем, связанных с man:rcorder[8]. Соответствие имени файла и ``$``__name__ также упрощает понимание, какие переменные имеют отношение к сценарию в [.filename]#rc.conf[.local]#. Последнее также является тем, что вы могли бы назвать "политикой" для всех новых сценариев, включая те, что входят в базовую систему. -. Содержит ли строка `REQUIRE` значение LOGIN? Это условие обязательно для сценариев, работающих не из-под суперпользователя. Если сценарий запускается из-под суперпользователя, то стоит ли его запускать до `LOGIN`? Если нет, то его следует запускать после, так чтобы мы могли свободно сгруппировать локальные сценарии в той точке man:rcorder[8], когда почти все сценарии в базовой системе уже стартовали. -. Запускает ли сценарий постоянную службу? Если да, то он должен иметь `KEYWORD: shutdown`. -. Убедитесь в том, что в сценарии отсутствует `KEYWORD: FreeBSD`. Это перестало быть нужным и нежелательно уже много лет. Это также служит индикатором того, что новый сценарий был скопирован со старого, поэтому особое внимание должно быть уделено при проверке. -. Если сценарий использует интерпретируемый язык, такой как `perl`, `python` или `ruby`, то убедитесь, что значение `command_interpreter` установлено должным образом. В противном случае +. Если это новый файл, имеет ли он расширение [.filename]#.sh#? Если да, его необходимо изменить на просто [.filename]#file.in#, поскольку файлы [.filename]#rc.d# не могут оканчиваться таким расширением. +. Совпадают ли имя файла (без [.filename]#.in#), строка `PROVIDE` и `$`_name_? Совпадение имени файла с `PROVIDE` упрощает отладку, особенно при проблемах с man:rcorder[8]. Совпадение имени файла и `$`_name_ облегчает понимание того, какие переменные актуальны в [.filename]#rc.conf[.local]#. Это также является политикой для всех новых скриптов, включая те, что в базовой системе. +. Установлена ли строка `REQUIRE` в значение `LOGIN`? Это обязательно для скриптов, выполняемых от имени непривилегированного пользователя. Если скрипт выполняется от имени root, есть ли веская причина для его запуска до `LOGIN`? Если нет, он должен запускаться после, чтобы локальные скрипты можно было условно сгруппировать в man:rcorder[8] после запуска большинства компонентов базовой системы. +. Запускает ли скрипт постоянную службу? Если да, он должен содержать `KEYWORD: shutdown`. +. Убедитесь, что отсутствует `KEYWORD: FreeBSD`. Это перестало быть необходимым или желательным уже много лет. Это также указывает на то, что новый скрипт был скопирован/вставлен из старого скрипта, поэтому следует проявить дополнительную осторожность при проверке. +. Если скрипт использует интерпретируемый язык, например `perl`, `python` или `ruby`, убедитесь, что `command_interpreter` установлен корректно. Например, для Perl добавьте `PERL=${PERL}` в `SUB_LIST` и используйте `%%PERL%%`. В противном случае, + -[source,shell] +[source, shell] .... # service name stop .... -+ -возможно будет работать неправильно. Смотрите man:service[8] для дополнительной информации. -. Все ли вхождения [.filename]#/usr/local# были заменены на `%%PREFIX%%`? -. Идет ли присвоение переменным значений по умолчанию после `load_rc_config`? ++ +вероятно, не будет работать корректно. Дополнительную информацию смотрите в man:service[8]. +. Проверено, что все вхождения [.filename]#/usr/local# заменены на `%%PREFIX%%`? +. Делаются ли присваивания переменным по умолчанию после `load_rc_config`? . Используются ли пустые строки при присвоении значений по умолчанию? Такие присвоения должны быть удалены, но перепроверьте, что эти параметры задокументированы в комментариях в начале файла. . Действительно ли в сценариях используются значения, присвоенные переменным? -. Являются ли параметры по умолчанию, перечисленные в __name__``_flags``, обязательными? Если это так, то их следует поместить в `command_args`. Параметр `-d` здесь - это как красный флаг (прошу прощения за каламбур), поскольку обычно он применяется для "демонизации" процесса и поэтому на самом деле обязательный. -. Никогда не включайте переменную __name__``_flags`` в `command_args` (и наоборот; в прочем, такая ошибка встречается реже). -. Запускает ли сценарий какой-либо код безусловно? Это нехорошо. Обычно такие вещи могут/должны помещаться в `start_precmd`. -. Все логические условия должны использовать функцию `checkyesno`. Не пишите самописных проверок для `[Yy][Ee][Ss]`, и так далее. -. Если в сценарии выполняется цикл (например, ожидание чего-либо перед стартом), используется ли счетчик для завершения цикла? Мы не хотим бесконечного ожидания загрузки в случае возникновения ошибки. -. Создает ли сценарий файлы или каталоги, которым нужны особые права доступа? Например, файл [.filename]#pid#, который должен принадлежать пользователю, из-под которого запускается процесс. Вместо традиционных команд man:touch[1]/man:chown[8]/man:chmod[1] подумайте об использовании man:install[1] с подходящими аргументами командной строки, для того чтобы выполнить всю процедуру за один шаг. -==== +. Являются ли опции, перечисленные в стандартном _name_`_flags`, обязательными? Если да, они должны быть в `command_args`. Флаг `-d` здесь, как красный флаг (простите за каламбур), так как обычно это опция для "демонизации" процесса и, следовательно, фактически обязательна. +. `_name__flags` никогда не должны включаться в `command_args` (и наоборот, хотя такая ошибка встречается реже). +. Выполняет ли скрипт любой код безусловно? Это не приветствуется. Обычно такие вещи должны обрабатываться через `start_precmd`. +. Все логические проверки должны использовать функцию `checkyesno`. Не допускаются самодельные проверки на `[Yy][Ee][Ss]` и т.п. +. Если есть цикл (например, ожидание запуска чего-либо), есть ли в нём счётчик для завершения цикла? Мы не хотим, чтобы загрузка зависала навсегда в случае ошибки. +. Создает ли скрипт файлы или каталоги, требующие определенных разрешений, например, [.filename]#pid#, который должен принадлежать пользователю, запускающему процесс? Вместо традиционной последовательности man:touch[1]/man:chown[8]/man:chmod[1] рассмотрите использование man:install[1] с соответствующими аргументами командной строки, чтобы выполнить всю процедуру за один шаг. [[users-and-groups]] == Добавление пользователей и групп -Некоторые порты требуют в установленной системе наличие определенного пользователя. Выберите свободный UID в диапазоне от 50 до 999 и зарегистрируйте его в [.filename]#ports/UIDs# (для пользователей) и/или в [.filename]#ports/GIDs# (для групп). Удостоверьтесь, что не используете UID, уже используемый системой или другими портами. +Некоторые порты требуют наличия определённой учётной записи пользователя, обычно для демонов, работающих от имени этого пользователя. Для таких портов выберите _уникальный_ UID в диапазоне от 50 до 999 и зарегистрируйте его в [.filename]#ports/UIDs# (для пользователей) и [.filename]#ports/GIDs# (для групп). Уникальный идентификатор должен быть одинаковым для пользователей и групп. -Пожалуйста, включите в патч изменение для этих двух файлов, если вам требуется создать нового пользователя или группу для вашего порта. +Пожалуйста, приложите патч для этих двух файлов, если требуется создать нового пользователя или группу для порта. -Затем вы сможете использовать в вашем [.filename]#Makefile# переменные `USERS` и `GROUPS`, и пользователь автоматически создастся при установке порта. +Затем используйте `USERS` и `GROUPS` в [.filename]#Makefile#, и пользователь будет автоматически создан при установке порта. [.programlisting] .... @@ -2520,16 +4654,58 @@ USERS= pulse GROUPS= pulse pulse-access pulse-rt .... -Текущий перечень зарезервированных UID и GID находится в [.filename]#ports/UIDs# и [.filename]#ports/GIDs#. +Текущий список зарезервированных UID и GID можно найти в [.filename]#ports/UIDs# и [.filename]#ports/GIDs#. [[requiring-kernel-sources]] -== Порты, требующие наличия исходных текстов ядра +== Порты, зависящие от исходных кодов ядра -Некоторым портам (таким как загружаемые модули ядра) для компиляции нужны файлы с исходными текстами ядра. Ниже указан корректный способ определения, установлены ли они пользователем: +Некоторые порты (например, загружаемые модули ядра) требуют исходные файлы ядра для компиляции порта. Вот правильный способ проверить, установлены ли они у пользователя: [.programlisting] .... USES= kmod .... -Кроме этой проверки, `kmod` заботится о большинстве пунктов, которые должны учитываться в этих портах. +Помимо этой проверки, функция `kmod` учитывает большинство аспектов, которые необходимо принимать во внимание данным портам. + +[[go-libs]] +== Библиотеки Go + +Порты не должны упаковывать или устанавливать библиотеки или исходный код Go. Порты Go должны загружать необходимые зависимости в обычное время загрузки и должны устанавливать только программы и то, что нужно пользователям, а не то, что нужно разработчикам на Go. + +Порты должны (в порядке предпочтения): + +* Использовать зависимости, включенные в исходный код пакета. +* Получить версии зависимостей, указанные вышестоящим проектом (в случае go.mod, vendor.json или аналогичных). +* В крайнем случае (зависимости не включены и версии не указаны точно) получить версии зависимостей, доступные на момент разработки/выпуска вышестоящего проекта. + +[[haskell-libs]] +== Библиотеки Haskell + +Как и в случае с языком Go, коллекция портов не должна включать или устанавливать библиотеки Haskell. Порты Haskell должны статически линковаться со своими зависимостями и загружать все распространяемые файлы на этапе fetch. + +[[shell-completion]] +== Файлы завершения командной оболочки + +Многие современные оболочки (включая bash, fish, tcsh и zsh) поддерживают табуляцию для параметров и/или опций. Эта поддержка обычно обеспечивается файлами завершения, которые содержат определения того, как будет работать завершение по табуляции для определённой команды. Порты иногда поставляются со своими собственными файлами завершения, или разработчики портов могут создавать их самостоятельно. + +Если доступны файлы завершения, их всегда следует устанавливать. Нет необходимости создавать для этого опцию. Однако если опция используется, всегда включайте её в `OPTIONS_DEFAULT`. + +[[shell-completion-paths]] +.Полные имена файлов завершения оболочки +[cols="1,1,1", frame="none"] +|=== +|`bash` +|[.filename]#${PREFIX}/etc/bash_completion.d# or [.filename]#${PREFIX}/share/bash-completion/completions# +|(любые уникальные имена файлов в одной из этих папок) + +|`fish` +|[.filename]#${PREFIX}/share/fish/completions/${PORTNAME}.fish# +| + +|`zsh` +|[.filename]#${PREFIX}/share/zsh/site-functions/_${PORTNAME}# +| +|=== + +Не регистрируйте зависимости от самих оболочек. |