diff options
Diffstat (limited to 'documentation/content/ru/books/porters-handbook/makefiles/_index.adoc')
| -rw-r--r-- | documentation/content/ru/books/porters-handbook/makefiles/_index.adoc | 4265 |
1 files changed, 3405 insertions, 860 deletions
diff --git a/documentation/content/ru/books/porters-handbook/makefiles/_index.adoc b/documentation/content/ru/books/porters-handbook/makefiles/_index.adoc index f831873e56..51a032507e 100644 --- a/documentation/content/ru/books/porters-handbook/makefiles/_index.adoc +++ b/documentation/content/ru/books/porters-handbook/makefiles/_index.adoc @@ -1,15 +1,17 @@ --- -title: Глава 5. Настройка файла Makefile -prev: books/porters-handbook/slow-porting +description: 'Настройка Makefile для портов FreeBSD' next: books/porters-handbook/special +params: + path: /books/porters-handbook/makefiles/ +prev: books/porters-handbook/slow-porting showBookMenu: true +tags: ["makefiles", "configuring", "naming", "versions"] +title: 'Глава 5. Настройка Makefile' weight: 5 -params: - path: "/books/porters-handbook/makefiles/" --- [[makefiles]] -= Настройка файла Makefile += Настройка Makefile :doctype: book :toc: macro :toclevels: 1 @@ -20,7 +22,7 @@ params: :partnums: :source-highlighter: rouge :experimental: -:gcc-plus-plus: g++ +:g-plus-plus: g++ :images-path: books/porters-handbook/ ifdef::env-beastie[] @@ -47,118 +49,325 @@ toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] -Настройка файла [.filename]#Makefile# достаточно проста, и мы снова предполагаем, что перед тем, как начать, вы посмотрите на существующие примеры. К тому же в этом руководстве имеется <<porting-samplem,примерный Makefile>>, так что взгляните на него и, пожалуйста, следуйте порядку переменных и разделов в этом образце, чтобы облегчить чтение вашего порта другими людьми. +Настройка [.filename]#Makefile# довольно проста, и мы снова рекомендуем изучить существующие примеры перед началом. Также в этом руководстве есть crossref:porting-samplem[porting-samplem,пример Makefile], поэтому ознакомьтесь с ним и, пожалуйста, соблюдайте порядок переменных и разделов в этом шаблоне, чтобы порт был удобнее для чтения другими. -Итак, расположим решаемые задачи в порядке их возникновения при создании вашего нового файла [.filename]#Makefile#: +Рассмотрите эти проблемы последовательно при разработке нового [.filename]#Makefile#: [[makefile-source]] -== Оригинальные исходный код +== Оригинальный исходный код -Находится ли он в каталоге `DISTDIR` в виде стандартного упакованного архиватором `gzip` tar-архива с именем типа [.filename]#foozolix-1.2.tar.gz#? Если это так, можно перейти к следующему шагу. Если нет, то вы должны попытаться переопределить некоторые из переменных `DISTVERSION`, `DISTNAME`, `EXTRACT_CMD`, `EXTRACT_BEFORE_ARGS`, `EXTRACT_AFTER_ARGS`, `EXTRACT_SUFX` или `DISTFILES` в зависимости от того, насколько необычен формат дистрибутивного файла. +Находится ли он в `DISTDIR` в виде стандартного архива ``gzip`` с именем вроде [.filename]#foozolix-1.2.tar.gz#? Если да, переходите к следующему шагу. Если нет, возможно, для формата имени файла дистрибутива потребуется переопределить одну или несколько переменных: `DISTVERSION`, `DISTNAME`, `EXTRACT_CMD`, `EXTRACT_BEFORE_ARGS`, `EXTRACT_AFTER_ARGS`, `EXTRACT_SUFX` или `DISTFILES`. -В худшем случае вы можете просто определить свою собственную цель `do-extract` для переопределения действий по умолчанию, хотя к этому нужно будет прибегать в очень редких случаях, если вообще придётся. +В худшем случае создайте пользовательскую цель `do-extract`, чтобы переопределить стандартную. Это редко, если вообще когда-либо, необходимо. [[makefile-naming]] == Именование -В первой части [.filename]#Makefile# порта ему даётся название, указывается его номер версии и принадлежность к правильной категории. +Первая часть [.filename]#Makefile# порта указывает его название, описывает номер версии и помещает его в соответствующую категорию. + +[[makefile-portname]] +=== `PORTNAME` + +Установите `PORTNAME` как базовое имя программы. Оно используется в качестве основы для пакета FreeBSD и для crossref:makefiles[makefile-distname,`DISTNAME`]. + +[IMPORTANT] +==== +Название пакета должно быть уникальным во всём дереве портов. Убедитесь, что `PORTNAME` ещё не используется существующим портом и что никакой другой порт уже не имеет такой же `PKGBASE`. Если имя уже занято, добавьте либо crossref:makefiles[porting-pkgnameprefix-suffix,`PKGNAMEPREFIX`, либо `PKGNAMESUFFIX`]. +==== + +[[makefile-versions]] +=== Версии, `DISTVERSION` _или_ `PORTVERSION` -=== `PORTNAME` и `PORTVERSION` +Установите `DISTVERSION` в номер версии программы. + +`PORTVERSION` — это версия, используемая для пакета FreeBSD. Она будет автоматически вычислена из `DISTVERSION` в соответствии со схемой версионирования пакетов FreeBSD. Если версия содержит _буквы_, может потребоваться задать `PORTVERSION` вместо `DISTVERSION`. + +[IMPORTANT] +==== +Только одна из переменных `PORTVERSION` и `DISTVERSION` может быть установлена одновременно. +==== + +Время от времени некоторые программы используют схему версионирования, которая несовместима с тем, как `DISTVERSION` преобразуется в `PORTVERSION`. + +[TIP] +==== +При обновлении порта можно использовать аргумент `-t` утилиты man:pkg-version[8], чтобы проверить, является ли новая версия больше или меньше предыдущей. Смотрите ниже, как использовать man:pkg-version[8] для сравнения версий. +==== -В переменной `PORTNAME` вы должны указать основную часть имени вашего порта, а в переменной `PORTVERSION` - номер версии. +[[makefile-versions-ex-pkg-version]] +.Использование man:pkg-version[8] для сравнения версий +[example] +==== +`pkg version -t` принимает две версии в качестве аргументов и возвращает `<`, `=` или `>`, если первая версия меньше, равна или больше второй версии соответственно. + +[source, shell] +.... +% pkg version -t 1.2 1.3 +< <.> +% pkg version -t 1.2 1.2 += <.> +% pkg version -t 1.2 1.2.0 += <.> +% pkg version -t 1.2 1.2.p1 +> <.> +% pkg version -t 1.2.a1 1.2.b1 +< <.> +% pkg version -t 1.2 1.2p1 +< <.> +.... + +<.> `1.2` идёт перед `1.3`. +<.> `1.2` и `1.2` равны, так как имеют одинаковую версию. +<.> `1.2` и `1.2.0` равны, так как ноль ничего не значит. +<.> `1.2` идёт после `1.2.p1`, так как `.p1` означает «pre-release 1» (предрелизная версия 1). +<.> `1.2.a1` предшествует `1.2.b1`, представьте "alpha" и "beta", где `a` идёт перед `b`. +<.> `1.2` находится перед `1.2p1`, так же как `2p1` (читается как "2, уровень исправления 1") — это версия, следующая после любой `2.X`, но перед `3`. + +[NOTE] +**** +Здесь `a`, `b` и `p` используются так, как если бы они означали "альфа", "бета" или "пре-релиз" и "уровень патча", но на самом деле это просто буквы, которые сортируются в алфавитном порядке, поэтому можно использовать любую букву, и они будут отсортированы соответствующим образом. +**** + +==== + +.Примеры `DISTVERSION` и производной `PORTVERSION` +[cols="10%,90%", frame="none", options="header"] +|=== +| DISTVERSION +| .PORTVERSION + +|0.7.1d +|0.7.1.d + +|10Alpha3 +|10.a3 + +|3Beta7-pre2 +|3.b7.p2 + +|8:f_17 +|8f.17 +|=== + +[[makefile-versions-ex1]] +.Использование `DISTVERSION` +[example] +==== +Если версия содержит только числа, разделённые точками, тире или подчёркиваниями, используйте `DISTVERSION`. + +[.programlisting] +.... +PORTNAME= nekoto +DISTVERSION= 1.2-4 +.... + +Это сгенерирует `PORTVERSION` равный `1.2.4`. +==== + +[[makefile-versions-ex2]] +.Использование `DISTVERSION` когда версия начинается с буквы или префикса +[example] +==== +Когда версия начинается или заканчивается буквой, или префиксом, или суффиксом, которые не являются частью версии, используйте `DISTVERSIONPREFIX`, `DISTVERSION` и `DISTVERSIONSUFFIX`. + +Если версия `v1.2-4`: + +[.programlisting] +.... +PORTNAME= nekoto +DISTVERSIONPREFIX= v +DISTVERSION= 1_2_4 +.... + +Некоторые проекты, использующие GitHub, могут включать своё название в версии. Например, версия может выглядеть как `nekoto-1.2-4`: + +[.programlisting] +.... +PORTNAME= nekoto +DISTVERSIONPREFIX= nekoto- +DISTVERSION= 1.2_4 +.... + +Эти проекты также иногда используют строку в конце версии, например, `1.2-4_RELEASE`: + +[.programlisting] +.... +PORTNAME= nekoto +DISTVERSION= 1.2-4 +DISTVERSIONSUFFIX= _RELEASE +.... + +Или они делают и то, и другое, например, `nekoto-1.2-4_RELEASE`: + +[.programlisting] +.... +PORTNAME= nekoto +DISTVERSIONPREFIX= nekoto- +DISTVERSION= 1.2-4 +DISTVERSIONSUFFIX= _RELEASE +.... + +`DISTVERSIONPREFIX` и `DISTVERSIONSUFFIX` не будут использоваться при формировании `PORTVERSION`, а только в `DISTNAME`. + +Все сгенерируют `PORTVERSION` равный `1.2.4`. +==== + +[[makefile-versions-ex3]] +.Использование `DISTVERSION`, когда версия содержит буквы, означающие "alpha", "beta" или "pre-release" +[example] +==== +Если версия содержит числа, разделённые точками, тире или подчёркиваниями, а буквы используются для обозначения "альфа", "бета" или "предварительной версии" (то есть до версии без букв), используйте `DISTVERSION`. + +[.programlisting] +.... +PORTNAME= nekoto +DISTVERSION= 1.2-pre4 +.... + +[.programlisting] +.... +PORTNAME= nekoto +DISTVERSION= 1.2p4 +.... + +Оба варианта создадут `PORTVERSION` равную `1.2.p4`, что предшествует версии 1.2. Для проверки этого факта можно использовать man:pkg-version[8]: + +[source, shell] +.... +% pkg version -t 1.2.p4 1.2 +< +.... + +==== + +[[makefile-versions-ex4]] +.Не использовать `DISTVERSION`, если версия содержит буквы, означающие "уровень патча" +[example] +==== +Если версия содержит буквы, которые не означают "alpha", "beta" или "pre", а скорее указывают на "уровень исправления" и следуют после версии без букв, используйте `PORTVERSION`. + +[.programlisting] +.... +PORTNAME= nekoto +PORTVERSION= 1.2p4 +.... + +В данном случае использование `DISTVERSION` невозможно, так как это приведёт к генерации версии `1.2.p4`, которая будет считаться более ранней, чем `1.2`, а не более поздней. man:pkg-version[8] подтвердит это: + +[source, shell] +.... +% pkg version -t 1.2 1.2.p4 +> <.> +% pkg version -t 1.2 1.2p4 +< <.> +.... + +<.> `1.2` идёт после `1.2.p4`, что в данном случае _неверно_. +<.> `1.2` находится перед `1.2p4`, что и требовалось. +==== + +Для более сложных примеров настройки `PORTVERSION`, когда версия программного обеспечения действительно несовместима с FreeBSD, или `DISTNAME`, когда файл дистрибутива не содержит саму версию, см. crossref:makefiles[makefile-distname, `DISTNAME`]. [[makefile-naming-revepoch]] === `PORTREVISION` и `PORTEPOCH` +[[makefile-portrevision]] ==== `PORTREVISION` -Переменная `PORTREVISION` представляет собой монотонно увеличивающееся число, которое обнуляется при каждом увеличении значения переменной `PORTVERSION` (то есть каждый раз, когда создателями выпускается новый официальный релиз), и добавляется к имени пакета, если оно не равно нулю. Изменения в `PORTREVISION` используются автоматизированными инструментами (например, `pkg version`, см. man:pkg-version[8]) для определения факта появления нового пакета. +`PORTREVISION` — это монотонно возрастающее значение, которое сбрасывается в 0 при каждом увеличении `DISTVERSION`, обычно при каждом новом официальном выпуске от поставщика. Если `PORTREVISION` не равен нулю, его значение добавляется к имени пакета. Изменения `PORTREVISION` используются автоматизированными инструментами, такими как man:pkg-version[8], для определения доступности нового пакета. -Значение `PORTREVISION` должно увеличиваться каждый раз, когда в порте FreeBSD делаются изменения, которые как-либо меняют получаемый пакет. Сюда относятся только изменения, затрагивающие построение пакета с <<makefile-options,параметрами>> по умолчанию. +`PORTREVISION` должен быть увеличен каждый раз, когда в порт вносятся изменения, которые так или иначе влияют на сгенерированный пакет. Это включает изменения, затрагивающие только пакеты, собранные с нестандартными crossref:makefiles[makefile-options,опциями]. -Примеры случаев, когда значение `PORTREVISION` должно быть увеличено: +Примеры случаев, когда необходимо увеличить `PORTREVISION`: -* Добавление патчей для исправления уязвимостей, ошибок, или добавления новой функциональности в порт. -* Изменения в файле [.filename]#Makefile# порта для включения и выключения параметров, определяемых при компиляции пакета. -* Изменения в списке упаковки или в поведении пакета во время его установки (например, изменение скрипта, генерирующего начальные данные для пакета, такие, как ssh-ключи для хоста). -* Увеличение версии динамической библиотеки, от которой зависит порт (в этом случае тот, кто попытается установить старый пакет после установки более новой версии библиотеки, не сможет этого сделать, потому что при этом будет делаться поиск старой библиотеки libfoo.x, а не libfoo.(x+1)). -* Большие функциональные изменения в дистрибутивном файле порта, происходящие без объявлений, и приводящие к большим изменениям, то есть изменения в дистрибутиве требуют корректировки файла [.filename]#distinfo# без соответствующего изменения `PORTVERSION`, когда как команда `diff -ru` между новой и старой версиями показывает нетривиальные изменения в коде. +* Добавление исправлений для устранения уязвимостей безопасности, ошибок или для добавления новой функциональности в порт. +* Изменения в [.filename]#Makefile# порта для включения или отключения параметров сборки в пакете. +* Изменения в списке файлов пакета или в поведении во время установки. Например, изменение скрипта, который генерирует начальные данные для пакета, такие как ключи хоста man:ssh[1]. +* Увеличение версии зависимости порта от общей библиотеки (в данном случае, попытка установить старый пакет после установки более новой версии зависимости завершится неудачей, так как будет искаться старая версия libfoo.x вместо libfoo.(x+1)). +* Тихие изменения в дистрибутивном файле порта, которые имеют значительные функциональные отличия. Например, изменения в дистрибутивном файле, требующие корректировки файла [.filename]#distinfo# без соответствующего изменения `DISTVERSION`, когда сравнение `diff -ru` старой и новой версий показывает нетривиальные изменения в коде. +* Изменения в `MAINTAINER`. -Примеры изменений, которые не требуют увеличения переменной `PORTREVISION`: +Примеры изменений, которые не требуют увеличения `PORTREVISION`: -* Изменения стиля в скелете порта без функциональных изменений в пакете. -* Изменения в переменной `MASTER_SITES` или другие функциональные изменения порта, которые не затрагивают получающегося пакета. -* Тривиальные патчи к дистрибутивному файлу, такие, как исправления опечаток, которые не так уж важны, что пользователи пакета должны озаботиться обновлением. -* Исправления, касающиеся этапа построения, которые делают возможным построение пакета, если ранее это было невозможно сделать (пока изменения не приводят к изменению работы на любых других платформах, на которых порт ранее строился). Так как `PORTREVISION` отражает содержимое пакета, то, если ранее пакет не строился, то нет нужды увеличивать `PORTREVISION` для отметки изменения. +* Стилевые изменения в каркасе портов без функциональных изменений в итоговом пакете. +* Изменения в `MASTER_SITES` или другие функциональные изменения порта, которые не влияют на итоговый пакет. +* Тривиальные исправления в дистрибутивном файле, такие как исправление опечаток, которые не настолько важны, чтобы пользователи пакета были вынуждены тратить время на обновление. +* Исправления сборки, которые позволяют пакету компилироваться там, где ранее это не удавалось. При условии, что изменения не вносят функциональных изменений на других платформах, где порт ранее собирался. Поскольку `PORTREVISION` отражает содержимое пакета, если пакет ранее не мог быть собран, то нет необходимости увеличивать `PORTREVISION` для обозначения изменений. -Правило, которому нужно приблизительно следовать, заключается в том, что нужно спрашивать себя, является ли вносимое в порт изменение таким, что от него выиграют все (в виде усовершенствования, исправления или благодаря тому, что новый пакет будет вообще работоспособным), и примите во внимание тот факт, что при этом все, кто регулярно обновляют своё дерево портов, будут обязаны это сделать. Если это так, то переменная `PORTREVISION` должна быть увеличена. +Эмпирическое правило заключается в том, чтобы решить, является ли изменение, внесённое в порт, чем-то, что принесёт пользу _некоторым_ пользователям. Будь то улучшение, исправление или просто факт, что новый пакет вообще будет работать. Затем необходимо сопоставить это с тем, что всем, кто регулярно обновляет своё дерево портов, придётся выполнить обновление. Если ответ положительный, необходимо увеличить `PORTREVISION`. + +[NOTE] +==== +Пользователи бинарных пакетов _никогда_ не увидят обновления, если `PORTREVISION` не увеличен. Без увеличения `PORTREVISION` сборщики пакетов не могут обнаружить изменение и, следовательно, не пересоберут пакет. +==== +[[makefile-portepoch]] ==== `PORTEPOCH` -Время от времени разработчик программного обеспечения или создатель порта FreeBSD делают что-то не так и выпускают версию программы, номер которой меньше предыдущей версии. Примером этого является порт, название которого меняется с foo-20000801 на foo-1.0 (изначально это не считалось бы более новой версией, так как 20000801 численно больше, чем 1). +Время от времени разработчики программного обеспечения или сопровождающие портов FreeBSD совершают ошибку и выпускают версию своего ПО, которая фактически имеет меньший номер по сравнению с предыдущей. Примером может служить переход с foo-20000801 на foo-1.0 (первая версия будет ошибочно считаться более новой, поскольку число 20000801 больше, чем 1.0). [TIP] ==== +Результаты сравнения номеров версий не всегда очевидны. Команда `pkg version` (см. man:pkg-version[8]) может быть использована для проверки сравнения двух строк с номерами версий. Например: -Результат сравнения номера версии не всегда очевиден. Для выполнения сравнения двух строк с номером версии можно использовать `pkg version` (см. man:pkg-version[8]). Например: - -[source,shell] +[source, shell] .... % pkg version -t 0.031 0.29 > .... -Строка `>` в выводе команды означает, что версия 0.031 считается выше, чем версия 0.29, что может быть не очевидно для того, кто выполняет портирование. +Символ `>` в выводе указывает, что версия 0.031 считается больше, чем версия 0.29, что могло быть неочевидно для сопровождающего. ==== -В ситуациях, подобных этой, должно быть увеличено значение `PORTEPOCH`. Если значение `PORTEPOCH` не равно нулю, то оно добавляется к имени пакета, как описано в разделе выше. Значение `PORTEPOCH` никогда не должно уменьшаться или сбрасываться в ноль, потому что это приведёт к ошибке сравнения с пакетом с меньшим номером эпохи (то есть то, что пакет устарел, обнаружено не будет): номер новой версии (например, `1.0,1` в примере выше) останется меньше, чем номер предыдущей версии (20000801), однако суффикс `,1` интерпретируется различными автоматизированными утилитами особым образом, и окажется больше, чем предполагаемый суффикс `,0` более раннего пакета). +В таких ситуациях необходимо увеличить `PORTEPOCH`. Если `PORTEPOCH` не равен нулю, он добавляется к имени пакета, как описано в разделе 0 выше. `PORTEPOCH` никогда не должен уменьшаться или сбрасываться до нуля, потому что это приведёт к ошибке при сравнении с пакетом из более ранней эпохи. Например, пакет не будет обнаружен как устаревший. Новый номер версии, `1.0,1` в приведённом выше примере, всё ещё численно меньше предыдущей версии, 20000801, но суффикс `,1` обрабатывается автоматизированными инструментами особым образом и считается большим, чем подразумеваемый суффикс `,0` у предыдущего пакета. -Некорректное уменьшение или сброс `PORTEPOCH` приводит к печальным последствиям; если вы не поняли, о чём шла речь ранее, пожалуйста, всё же разберитесь с этим, либо спросите в списках рассылки. +Неправильное удаление или сброс `PORTEPOCH` приводит к бесконечным проблемам. Если приведённое выше объяснение недостаточно ясно, обратитесь к {freebsd-ports}. -Предполагается, что в большинстве портов переменная `PORTEPOCH` использоваться не будет, но при корректном использовании `PORTVERSION` может появиться необходимость её иметь, если в будущих релизах программное обеспечение должно изменить структуру номера версии. Однако создателям портов для FreeBSD нужно быть внимательными, когда разработчик выпускает релиз без официального номера версии - эдакие "промежуточные" релизы. Имеется соблазн пометить релиз датой его выхода, что может вызвать проблемы, как и в примере выше, когда будет выпущен новый "официальный" релиз. +Ожидается, что `PORTEPOCH` не будет использоваться для большинства портов, и что разумное использование `DISTVERSION` или аккуратное применение `PORTVERSION` часто может предотвратить необходимость его использования, если будущий выпуск программного обеспечения изменит структуру версий. Однако разработчикам портов FreeBSD следует быть осторожными, когда вендор выпускает релиз без официального номера версии — например, релиз в виде "снимка" кода. Возникает соблазн обозначить такой релиз датой выпуска, что вызовет проблемы, как в примере выше, когда будет сделан новый "официальный" релиз. -Например, если промежуточный релиз помечен датой 20000917, а предыдущая версия программного обеспечения имела номер 1.2, то промежуточному релизу должно быть поставлено в соответствие значение `PORTVERSION`, равное 1.2.20000917 или что-то похожее, но не 20000917, так как последующий релиз, скажем, 1.3, должен иметь численно большее значение. +Например, если снимок выпущен на дату `20000917`, а предыдущая версия программного обеспечения была `1.2`, не следует использовать `20000917` для `DISTVERSION`. Правильным будет указать `DISTVERSION` как `1.2.20000917` или подобное, чтобы следующая версия, например `1.3`, оставалась численно большей. -==== Пример использования переменных `PORTREVISION` и `PORTEPOCH` +[[makefile-portrevision-example]] +==== Пример использования `PORTREVISION` и `PORTEPOCH` -Выполнен коммит порта `gtkmumble`, версии `0.10`, в коллекцию портов. +Порт `gtkmumble` версии `0.10` добавлен в коллекцию портов: [.programlisting] .... PORTNAME= gtkmumble -PORTVERSION= 0.10 +DISTVERSION= 0.10 .... -Значение `PKGNAME` станет равным `gtkmumble-0.10`. +`PKGNAME` становится `gtkmumble-0.10`. -Обнаружена брешь в безопасности, исправление которой потребовало создания локального патча для FreeBSD. Соответственно было увеличено значение переменной `PORTREVISION`. +Обнаружена уязвимость в безопасности, требующая локального исправления FreeBSD. `PORTREVISION` соответствующим образом увеличивается. [.programlisting] .... PORTNAME= gtkmumble -PORTVERSION= 0.10 +DISTVERSION= 0.10 PORTREVISION= 1 .... `PKGNAME` принимает значение `gtkmumble-0.10_1` -Разработчиком выпущена новая версия с номером `0.2` (оказалось, что под номером `0.10` автор имел в виду `0.1.0`, а не "то, что будет выпущено после версии 0.9" - извините, теперь уже поздно). Так как новый младший номер версии `2` по значению меньше, чем номер предыдущей версии `10`, то должно быть увеличено значение `PORTEPOCH` для того, чтобы заставить распознавать вновь создаваемый пакет как "более новый". Так как это новый релиз программы, то `PORTREVISION` обнуляется (или удаляется из файла [.filename]#Makefile#). +Выпущена новая версия от поставщика под номером `0.2` (оказывается, автор изначально подразумевал, что `0.10` на самом деле означает `0.1.0`, а не "то, что идет после 0.9" — увы, теперь уже поздно). Поскольку новая минорная версия `2` численно меньше предыдущей версии `10`, необходимо увеличить `PORTEPOCH`, чтобы вручную заставить систему распознавать новый пакет как "более новый". Так как это новый релиз кода от поставщика, `PORTREVISION` сбрасывается до 0 (или удаляется из [.filename]#Makefile#). [.programlisting] .... PORTNAME= gtkmumble -PORTVERSION= 0.2 +DISTVERSION= 0.2 PORTEPOCH= 1 .... -`PKGNAME` принимает значение `gtkmumble-0.2,1` +`PKGNAME` становится `gtkmumble-0.2,1` -Следующий релиз имеет номер версии 0.3. Так как значение переменной `PORTEPOCH` никогда не уменьшается, что переменные, определяющие версии, теперь выглядят так: +Следующий выпуск — 0.3. Поскольку `PORTEPOCH` никогда не уменьшается, переменные версий теперь выглядят так: [.programlisting] .... PORTNAME= gtkmumble -PORTVERSION= 0.3 +DISTVERSION= 0.3 PORTEPOCH= 1 .... @@ -166,152 +375,196 @@ PORTEPOCH= 1 [NOTE] ==== -Если значение `PORTEPOCH` этим обновлением было бы сброшено в `0`, то кто-нибудь, имеющий установленный пакет `gtkmumble-0.10_1`, не смог бы опознать пакет `gtkmumble-0.3` как более новый, так как `3` было бы меньше, чем `10`. Помните, что в первую очередь это касается `PORTEPOCH`. +Если бы `PORTEPOCH` был сброшен в `0` при этом обновлении, пользователь, установивший пакет `gtkmumble-0.10_1`, не увидел бы пакет `gtkmumble-0.3` как более новый, поскольку `3` всё ещё численно меньше, чем `10`. Помните, в этом и заключается вся суть `PORTEPOCH` изначально. ==== -=== Переменные `PKGNAMEPREFIX` и `PKGNAMESUFFIX` +[[porting-pkgnameprefix-suffix]] +=== `PKGNAMEPREFIX` и `PKGNAMESUFFIX` -Две необязательные переменные, `PKGNAMEPREFIX` и `PKGNAMESUFFIX`, объединяются со значениями `PORTNAME` и `PORTVERSION` для формирования `PKGNAME` в форме `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Добейтесь того, чтобы это соответствовало нашим <<porting-pkgname,рекомендациям по правильному выбору названий для пакетов>>. В частности, в переменной `PORTVERSION` _не разрешается_ использование дефиса (`-`). Кроме того, если в имени пакета присутствует часть _language-_ или _-compiled.specifics_ (смотрите ниже), то используйте переменные `PKGNAMEPREFIX` и `PKGNAMESUFFIX`, соответственно. Не делайте их частью значения переменной `PORTNAME`. +Две необязательные переменные, `PKGNAMEPREFIX` и `PKGNAMESUFFIX`, объединяются с `PORTNAME` и `PORTVERSION` для формирования `PKGNAME` в виде `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Убедитесь, что это соответствует нашим crossref:makefiles[porting-pkgname,рекомендациям по именованию пакетов]. В частности, использование дефиса (`-`) в `PORTVERSION` _не_ допускается. Кроме того, если имя пакета содержит часть _language-_ или _-compiled.specifics_ (см. ниже), используйте `PKGNAMEPREFIX` и `PKGNAMESUFFIX` соответственно. Не включайте их в `PORTNAME`. [[porting-pkgname]] -=== Соглашения по именованию пакетов +=== Соглашения о наименовании пакетов -Далее описаны некоторые соглашения, которым вы должны следовать в именовании ваших пакетов. Они были разработаны для облегчения просмотра каталога, так как имеется уже тысячи пакетов, а пользователи отвернутся от нас, если список не понравится их взору! +Вот соглашения, которым следует придерживаться при наименовании пакетов. Это сделано для того, чтобы каталог пакетов было легко просматривать, поскольку там уже тысячи пакетов, и пользователи могут отказаться от их использования, если это будет напрягать их глаза! -Имя пакета должно иметь вид [.filename]#language_region-name-compiled.specifics-version.numbers#. +Имена пакетов имеют формат [.filename]#language_region-name-compiled.specifics-version.numbers#. -Имя пакета определяется как `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Вы должны задавать значения переменных в соответствии с этим форматом. +Имя пакета определяется как `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Убедитесь, что переменные заданы в соответствии с этим форматом. + +[[porting-pkgname-language]] +[.filename]#language_region-#:: +FreeBSD стремится поддерживать родной язык своих пользователей. Часть _language-_ представляет собой двухбуквенное сокращение естественного языка, определённое стандартом ISO-639, когда порт относится к определённому языку. Примерами являются `ja` для японского, `ru` для русского, `vi` для вьетнамского, `zh` для китайского, `ko` для корейского и `de` для немецкого. ++ +Если порт относится к определённому региону в языковой зоне, добавьте также двухбуквенный код страны. Например, `en_US` для американского английского и `fr_CH` для швейцарского французского. ++ +Часть _language-_ задается в `PKGNAMEPREFIX`. -. FreeBSD пытается поддерживать языки, на которых разговаривают её пользователи. Часть _language-_ должна быть двухсимвольным сокращением от названия языка по стандарту ISO-639, если порт специфичен для конкретного языка. Примерами являются `ja` для японского, `ru` для русского, `vi` для вьетнамского, `zh` для китайского, `ko` для корейского и `de` для немецкого языков. -+ -Если ваш порт специфичен для конкретного региона внутри области использования языка, добавьте также двухсимвольный код страны. Примерами являются `en_US` для US English и `fr_CH` для Swiss French. -+ -Часть _language-_ должна задаваться в переменной `PKGNAMEPREFIX`. -. Первая буква части [.filename]#name# должна быть в нижнем регистре. (Оставшаяся часть названия может содержать буквы в верхнем регистре, так что принимайте решение сами, когда преобразуете имя программного пакета, содержащего в имени некоторое количество заглавных букв.) Существует традиция именовать модули для `Perl 5`, добавляя впереди `p5-` и преобразуя пару двоеточий в дефис; например, модуль `Data::Dumper` будет именоваться `p5-Data-Dumper`. -. Убедитесь, что имя порта и версия четко отделены и размещаются в переменных `PORTNAME` и `PORTVERSION`. Единственная причина, по которой `PORTNAME` содержит версионную часть, это если полученный дистрибутив сам назван таким образом, как это сделано для портов [.filename]#textproc/libxml2# или [.filename]#japanese/kinput2-freewnn#. В противном случае `PORTNAME` не должен содержать никакой информации, указывающей на версию. То, что некоторые порты имеют одинаковый `PORTNAME`, является вполне нормальным, как для портов [.filename]#www/apache*#; в этом случае различные версии (и различные записи в индексе) отличаются по значениям `PKGNAMEPREFIX` и `PKGNAMESUFFIX`. -. Если порт может быть построен с различными <<makefile-masterdir,статически заданными значениями по умолчанию>> (обычно это часть имени каталога в семействе портов), то часть _-compiled.specifics_ должна определять вкомпилированные значения по умолчанию (дефис не обязателен). Примерами являются размеры бумаги и шрифтов. -+ -Часть _-compiled.specifics_ должна задаваться в переменной `PKGNAMESUFFIX`. -. Строка с номером версии должна следовать за дефисом (`-`) и являться списком разделенных двоеточием чисел и букв в нижнем регистре. В частности, не разрешается иметь еще один дефис внутри строки с обозначением номера версии. Единственным исключением является строчка `pl` (означающая "patchlevel"), которая может использоваться _только_ тогда, когда у программного обеспечения нет старшего и младшего номера версии. Если в номер версии программного обеспечения включена строчка типа "alpha", "beta", "rc" или "pre", возьмите из неё первую букву и поставьте её непосредственно после точки. Если после таких строк номер версии ещё продолжается, то после буквы должно следовать число без дополнительной разделяющей точки. -+ -Смысл такого формата заключается в удобстве сортировки портов по номеру версии. В частности, следите за тем, чтобы компоненты номера версии разделялись точкой, и если там присутствует дата, то используйте формат `0.0.yyyy.mm.dd`, но не `dd.mm.yyyy` или не совместимый с проблемой Y2K `yy.mm.dd`. Добавление к версии префикса `0.0.` является важным, в случае если выпущен релиз с присвоением настоящей версии, которая в числовом представлении, конечно же, будет ниже, чем `yyyy`. +[[porting-pkgname-name]] +[.filename]#name#:: +Убедитесь, что название порта и его версия четко разделены и указаны в `PORTNAME` и `DISTVERSION`. Единственная причина, по которой `PORTNAME` может содержать часть версии, — это если вышестоящее распространяемое ПО действительно так названо, как в портах package:textproc/libxml2[] или package:japanese/kinput2-freewnn[]. В противном случае `PORTNAME` не может содержать информацию о версии. Довольно нормально, когда несколько портов имеют одинаковый `PORTNAME`, как это делают порты package:www/apache*[]; в таком случае разные версии (и разные записи в индексе) различаются значениями `PKGNAMEPREFIX` и `PKGNAMESUFFIX`. ++ +Существует традиция называть модули `Perl 5`, добавляя префикс `p5-` и заменя разделитель в виде двойного двоеточия на дефис. Например, модуль `Data::Dumper` становится `p5-Data-Dumper`. +[[porting-pkgname-compiled-specifics]] +[.filename]#-compiled.specifics#:: +Если порт может быть собран с различными crossref:makefiles[makefile-masterdir,жестко заданными значениями по умолчанию] (обычно это часть имени каталога в семействе портов), часть _-compiled.specifics_ указывает скомпилированные значения по умолчанию. Дефис является необязательным. Примерами могут служить размер бумаги и единицы измерения шрифтов. ++ +Часть _-compiled.specifics_ задаётся в `PKGNAMESUFFIX`. -Вот несколько (реальных) примеров того, как преобразовать имя из оригинального, придуманного авторами, к подходящему для имени пакета: +[[porting-pkgname-version-numbers]] +[.filename]#-version.numbers#:: +Строка версии следует после тире (`-`) и представляет собой разделённый точками список целых чисел и строчных букв латинского алфавита. В частности, не допускается использование дополнительных тире внутри строки версии. Единственное исключение — строка `pl` (означающая "уровень исправления"), которую можно использовать _только_ в случае отсутствия у программного обеспечения номеров основной и дополнительной версий. Если в версии программного обеспечения встречаются строки типа "alpha", "beta", "rc" или "pre", следует взять первую букву и поместить её сразу после точки. Если после таких названий строка версии продолжается, числа следуют за буквой без дополнительной точки между ними (например, `1.0b2`). ++ +Идея заключается в упрощении сортировки портов за счёт анализа строки версии. В частности, необходимо убедиться, что компоненты номера версии всегда разделены точкой, а если дата является частью строки, использовать формат `d__yyyy.mm.dd__`, а не `_dd.mm.yyyy_` или не соответствующий стандарту Y2K формат `_yy.mm.dd_`. Важно добавлять перед версией букву, в данном случае `d` (от слова "дата"), на случай, если будет выпущена версия с фактическим номером, который численно окажется меньше `_yyyy_`. -[.informaltable] -[cols="1,1,1,1,1,1", frame="none", options="header"] +[IMPORTANT] +==== +Название пакета должно быть уникальным среди всех портов в дереве. Убедитесь, что порт с таким же `PORTNAME` ещё не существует, и если он есть, добавьте один из crossref:makefiles[porting-pkgnameprefix-suffix,`PKGNAMEPREFIX` или `PKGNAMESUFFIX`]. +==== + +Вот несколько (реальных) примеров преобразования названия, указанного авторами программного обеспечения, в подходящее имя пакета. В каждой строке указана только одна из переменных `DISTVERSION` или `PORTVERSION`, в зависимости от того, какая используется в [.filename]#Makefile# порта: + +.Примеры наименования пакетов +[cols="1,1,1,1,1,1,1", frame="none", options="header"] |=== | Имя дистрибутива | PKGNAMEPREFIX | PORTNAME | PKGNAMESUFFIX -| PORTVERSION -| Обоснование +| DISTVERSION +| .PORTVERSION +| Причина или комментарий |mule-2.2.2 |(пусто) |mule |(пусто) |2.2.2 -|Изменений не потребовалось +| +|Никаких изменений не требуется + +|mule-1.0.1 +|(пусто) +|mule +|1 +|1.0.1 +| +|Это версия 1 mule, а версия 2 уже существует |EmiClock-1.0.2 |(пусто) |emiclock |(пусто) |1.0.2 -|Для отдельных программ имена с заглавными буквами запрещены +| +|Нет имен в верхнем регистре для отдельных программ |rdist-1.3alpha |(пусто) |rdist |(пусто) -|1.3.a -|Строчки типа `alpha` запрещены +|1.3alpha +| +|Версия будет `1.3.a` |es-0.9-beta1 |(пусто) |es |(пусто) -|0.9.b1 -|Строчки типа `beta` запрещены +|0.9-beta1 +| +|Версия будет `0.9.b1` |mailman-2.0rc3 |(пусто) |mailman |(пусто) -|2.0.r3 -|Строчки типа `rc` запрещены +|2.0rc3 +| +|Версия будет `2.0.r3` |v3.3beta021.src |(пусто) |tiff |(пусто) +| |3.3 -|Что это такое было вообще? +|Что это вообще было? |tvtwm |(пусто) |tvtwm |(пусто) -|pl11 -|Всегда требуется указание номера версии +| +|p11 +|Нет версии в имени файла, используйте то, что указано в исходном коде |piewm |(пусто) |piewm |(пусто) |1.0 -|Всегда требуется указание номера версии +| +|Нет версии в имени файла, используйте то, что указано в исходном коде |xvgr-2.10pl1 |(пусто) |xvgr |(пусто) -|2.10.1 -|`pl` разрешено только при отсутствии старшего/младшего номера версии +| +|2.10.pl1 +|В таком случае, `pl1` означает уровень патча, поэтому использование DISTVERSION невозможно. |gawk-2.15.6 |ja- |gawk |(пусто) |2.15.6 -|Версия на японском языке +| +|Японская языковая версия |psutils-1.13 |(пусто) |psutils |-letter |1.13 -|Размер бумаги задается статически во время построения пакета +| +|Размер бумаги жестко задан во время сборки пакета |pkfonts |(пусто) |pkfonts |300 |1.0 -|пакет для шрифтов 300dpi +| +|Пакет для шрифтов с разрешением 300dpi |=== -Если в исходном коде абсолютно нет информации о номере версии и не похоже, что автор собирается выпускать другую версию, то в качестве номера версии задайте просто `1.0` (как в примере с `piewm` выше). В противном случае спросите автора программы или используйте дату (`0.0.yyyy.mm.dd`) в качестве номера версии. +Если в исходном источнике полностью отсутствует информация о версии и маловероятно, что автор когда-либо выпустит новую версию, просто укажите строку версии как `1.0` (как в примере с `piewm` выше). В противном случае, спросите автора или используйте дату выпуска исходного файла в формате `d__yyyy.mm.dd__` или `d__yyyymmdd__` в качестве версии. + +[TIP] +==== +Используйте любую букву. Здесь `d` означает дату, если источник — это репозиторий Git, часто используется `g` с последующей датой коммита, также распространено использование `s` для снимка. +==== [[makefile-categories]] -== Разделение по категориям +== Категоризация +[[makefile-categories-definition]] === `CATEGORIES` -В процессе создания пакета он помещается в каталог [.filename]#/usr/ports/packages/All#, а в одном или более подкаталогов из [.filename]#/usr/ports/packages# создаются на него ссылки. Имена этих подкаталогов определяются переменной `CATEGORIES`. Такая схема нужна для облегчения жизни пользователя, когда он сталкивается с массой пакетов на FTP-сервере или компакт-диске. Пожалуйста, посмотрите на <<porting-categories,текущий список категорий>> и выберите те из них, которые более всего подходят к вашему порту. +При создании пакета он помещается в [.filename]#/usr/ports/packages/All#, и ссылки на него создаются в одной или нескольких поддиректориях [.filename]#/usr/ports/packages#. Имена этих поддиректорий задаются переменной `CATEGORIES`. Это предназначено для облегчения поиска пакетов пользователем при просмотре большого количества пакетов на FTP-сайте или CDROM. Пожалуйста, ознакомьтесь с crossref:makefiles[porting-categories,текущим списком категорий] и выберите подходящие для данного порта. -Этот список также определяет, куда в дереве портов будет помещен порт. Если вы укажете здесь более одной категории, то предполагается, что файлы порта будут помещены в подкаталог с именем первой категории. Посмотрите <<choosing-categories,ниже>> для получения подробной информации о том, как правильно выбрать категории. +Этот список также определяет, где в дереве портов будет размещён порт. Если здесь указано несколько категорий, файлы порта должны быть помещены в подкаталог с названием первой категории. Дополнительные сведения о выборе подходящих категорий см. в crossref:makefiles[choosing-categories,ниже]. [[porting-categories]] === Текущий список категорий -Вот текущий список категорий. Те, которые отмечены звёздочкой (`*`), являются _виртуальными_ категориями-они не имеют собственного подкаталога в дереве портов. Они используются только в качестве вторичных категорий, и только для поиска. +Вот текущий список категорий портов. Категории, помеченные звёздочкой (`*`), являются _виртуальными_ — они не имеют соответствующего подкаталога в дереве портов. Они используются только как вторичные категории и исключительно для целей поиска. [NOTE] ==== -Для невиртуальных категорий имеется однострочное описание в `COMMENT` в [.filename]#Makefile# соответствующего подкаталога. +Для невиртуальных категорий в `COMMENT` в [.filename]#Makefile# соответствующего подкаталога содержится однострочное описание. ==== [.informaltable] @@ -319,462 +572,596 @@ PORTEPOCH= 1 |=== | Категория | Описание -| Примечания +| Заметки |[.filename]#accessibility# |Порты для помощи пользователям с ограниченными возможностями. -| +| -|[.filename]#afterstep*# -|Порты, поддерживающие менеджер окон http://www.afterstep.org[AfterStep]. -| +|[.filename]#afterstep#`*` +|Порты для поддержки оконного менеджера http://www.afterstep.org/[AfterStep]. +| |[.filename]#arabic# |Поддержка арабского языка. -| +| |[.filename]#archivers# -|Инструменты для работы с архивами. -| +|Инструменты для архивирования. +| |[.filename]#astro# -|Приложения, связанные с астрономией. -| +|Астрономические порты. +| |[.filename]#audio# -|Поддержка работы со звуком. -| +|Поддержка звука. +| |[.filename]#benchmarks# -|Утилиты для измерения производительности системы. -| +|Утилиты для тестирования производительности. +| |[.filename]#biology# |Программное обеспечение, связанное с биологией. -| +| |[.filename]#cad# -|Инструменты Систем Автоматизированного Проектирования. -| +|Компьютерные средства автоматизированного проектирования. +| |[.filename]#chinese# |Поддержка китайского языка. -| +| |[.filename]#comms# -|Коммуникационное программное обеспечение. -|В основном программы для работы с последовательным портом. +|Программное обеспечение для связи. +|В основном программное обеспечение для работы с последовательным портом. |[.filename]#converters# -|Утилиты для преобразования символьных форматов. -| +|Преобразователи символьных кодировок. +| |[.filename]#databases# |Базы данных. -| +| |[.filename]#deskutils# -|То, что было на столе до изобретения компьютеров. -| +|Вещи, которые раньше находились на рабочем столе до изобретения компьютеров. +| |[.filename]#devel# -|Утилиты для разработки программного обеспечения. -|Не помещайте сюда библиотеки просто потому, что это библиотеки-если они подпадают под какую-то другую категорию, то их быть здесь не должно. +|Средства разработки. +|Не размещайте библиотеки здесь только потому, что они являются библиотеками. Они _не_ должны быть в этой категории, если только они действительно не подходят никуда больше. |[.filename]#dns# -|Программное обеспечение для работы DNS. -| +|Программное обеспечение, связанное с DNS. +| -|[.filename]#docs*# +|[.filename]#docs#`*` |Мета-порты для документации FreeBSD. -| +| |[.filename]#editors# -|Редакторы общего назначения. -|Специализированные редакторы относят к разделу для соответствующих инструментов (например, редактор математических формул попадает в категорию [.filename]#math#). +|Общие редакторы. +|Специализированные редакторы помещаются в раздел соответствующих инструментов. Например, редактор математических формул будет помещён в [.filename]#math#, а [.filename]#editors# будет для него второй категорией. -|[.filename]#elisp*# -|Порты для Emacs lisp. -| +|[.filename]#education#`*` +|Программное обеспечение для образования. +|Это включает приложения, утилиты или игры, разработанные в первую очередь или в значительной степени для помощи пользователю в изучении конкретной темы или обучении в целом. Также сюда входят приложения для создания курсов, приложения для предоставления курсов и приложения для управления классом или школой + +|[.filename]#elisp#`*` +|Порты Emacs-lisp. +| |[.filename]#emulators# |Эмуляторы других операционных систем. -|Эмуляторы терминалов сюда _не_ относятся-те, которые разработаны для X, должны быть в категории [.filename]#x11#, а текстовые в [.filename]#comms# или [.filename]#misc#, в зависимости от конкретного их предназначения. +|Терминальные эмуляторы _не_ относятся сюда. Основанные на X идут в [.filename]#x11#, а текстовые — либо в [.filename]#comms#, либо в [.filename]#misc#, в зависимости от конкретной функциональности. + +|[.filename]#enlightenment#`*` +|Порты, связанные с оконным менеджером Enlightenment. +| + +|[.filename]#filesystems# +|Файловые системы и связанные утилиты. +| |[.filename]#finance# -|Приложения для работы с деньгами, финансами и всем, что с этим связано. -| +|Монетарные, финансовые и связанные с ними приложения. +| |[.filename]#french# |Поддержка французского языка. -| +| |[.filename]#ftp# -|Клиенты и серверы FTP. -|Если ваш порт понимает как FTP, так и HTTP, поместите его в категорию [.filename]#ftp# и укажите вторичную категорию [.filename]#www#. +|Клиентские и серверные утилиты FTP. +|Если порт поддерживает как FTP, так и HTTP, поместите его в [.filename]#ftp# с дополнительной категорией [.filename]#www#. |[.filename]#games# |Игры. -| +| -|[.filename]#geography*# +|[.filename]#география#`*` |Программное обеспечение, связанное с географией. -| +| |[.filename]#german# |Поддержка немецкого языка. -| +| -|[.filename]#gnome*# -|Порты Проекта http://www.gnome.org[GNOME]. -| +|[.filename]#gnome#`*` +|Порты из проекта https://www.gnome.org/[GNOME]. +| -|[.filename]#gnustep*# -|Программное обеспечение для окружения рабочего стола GNUstep. -| +|[.filename]#gnustep#`*` +|Программное обеспечение, связанное со средой рабочего стола GNUstep. +| |[.filename]#graphics# |Графические утилиты. -| +| -|[.filename]#hamradio*# -|Программное обеспечение для любительского радио -| +|[.filename]#hamradio#`*` +|Программное обеспечение для радиолюбителей. +| -|[.filename]#haskell*# +|[.filename]#haskell#`*` |Программное обеспечение, связанное с языком Haskell. -| +| |[.filename]#hebrew# |Поддержка иврита. -| +| |[.filename]#hungarian# -|Поддержка венгерского языка. -| - -|[.filename]#ipv6*# -|Программное обеспечение, связанное с IPv6. -| +|Венгерская языковая поддержка. +| |[.filename]#irc# -|Утилиты для Internet Relay Chat. -| +|Утилиты Internet Relay Chat. +| |[.filename]#japanese# |Поддержка японского языка. -| +| |[.filename]#java# |Программное обеспечение, связанное с языком Java(TM). -|Категория [.filename]#java# ни в коем случае не должна быть единственной для порта. Оставьте для портов, непосредственно имеющих отношение к языку Java, портерам также рекомендуется не использовать [.filename]#java# как основную категорию порта. +|Категория [.filename]#java# не должна быть единственной для порта. За исключением портов, непосредственно связанных с языком Java, разработчикам также рекомендуется не использовать [.filename]#java# в качестве основной категории для порта. + +|[.filename]#kde#`*` +|Порты проекта https://www.kde.org/[KDE] (общие). +| + +|[.filename]#kde-приложения#`*` +|Приложения от проекта https://www.kde.org/[KDE]. +| + +|[.filename]#kde-frameworks#`*` +|Дополнительные библиотеки от проекта https://www.kde.org/[KDE] для программирования с использованием Qt. +| -|[.filename]#kde*# -|Порты проекта http://www.kde.org[KDE]. -| +|[.filename]#kde-plasma#`*` +|Рабочий стол от проекта https://www.kde.org/[KDE]. +| -|[.filename]#kld*# +|[.filename]#kld#`*` |Загружаемые модули ядра. -| +| |[.filename]#korean# |Поддержка корейского языка. -| +| |[.filename]#lang# |Языки программирования. -| +| -|[.filename]#linux*# -|Linux приложения и утилиты. -| +|[.filename]#linux#`*` +|Приложения и вспомогательные утилиты Linux. +| -|[.filename]#lisp*# +|[.filename]#lisp#`*` |Программное обеспечение, связанное с языком Lisp. -| +| |[.filename]#mail# -|Программы для работы с почтой. -| +|Почтовое программное обеспечение. +| + +|[.filename]#mate#`*` +|Порты, связанные с окружением рабочего стола MATE, форком GNOME 2. +| |[.filename]#math# -|Программное обеспечение для численных вычислений и другие утилиты, связанные с математикой. -| +|Численные расчеты и другие математические утилиты. +| -|[.filename]#mbone*# -|Приложения для MBone. -| +|[.filename]#mbone#`*` +|Приложения MBone. +| |[.filename]#misc# |Различные утилиты -|В общем, то, что не попадает в другие категории. Если это возможно, попробуйте найти более подходящую, чем `misc`, категорию для вашего порта, так как здесь порты теряются. +|Вещи, которые не подходят никуда больше. По возможности, попытайтесь найти для порта категорию лучше, чем `misc`, так как порты здесь часто остаются без внимания. |[.filename]#multimedia# -|Программное обеспечение для работы с мультимедиа. -| +|Мультимедийное программное обеспечение. +| |[.filename]#net# |Различное сетевое программное обеспечение. -| +| |[.filename]#net-im# -|Программы мгновенного обмена сообщениями. -| +|Программное обеспечение для обмена мгновенными сообщениями. +| |[.filename]#net-mgmt# -|Программное обеспечение для сетевого управления. -| +|Программное обеспечение для управления сетями. +| |[.filename]#net-p2p# -|Приложения для пиринговых сетей. -| +|Одноранговые сетевые приложения. +| -|[.filename]#news# -|Программное обеспечение для работы с конференциями USENET. -| +|[.filename]#сеть-vpn#`*` +|Виртуальные частные сети. +| -|[.filename]#palm# -|Программная поддержка http://www.palm.com/[Palm(TM)]. -| +|[.filename]#news# +|Программное обеспечение для USENET-новостей. +| -|[.filename]#parallel*# -|Приложения, связанные с параллельными вычислениями. -| +|[.filename]#parallel#`*` +|Приложения, работающие с параллелизмом в вычислениях. +| -|[.filename]#pear*# -|Порты, относящиеся к технологии Pear PHP. -| +|[.filename]#pear#`*` +|Порты, связанные с PHP-фреймворком Pear. +| -|[.filename]#perl5*# -|Порты, которым для работы требуется Perl версии 5. -| +|[.filename]#perl5#`*` +|Порты, требующие Perl версии 5 для работы. +| -|[.filename]#plan9*# -|Различные программы из http://www.cs.bell-labs.com/plan9dist/[Plan9]. -| +|[.filename]#plan9#`*` +|Различные программы с https://9p.io/wiki/plan9/Download/index.html[Plan9]. +| |[.filename]#polish# |Поддержка польского языка. -| +| |[.filename]#ports-mgmt# |Порты для управления, установки и разработки портов и пакетов FreeBSD. -| +| |[.filename]#portuguese# |Поддержка португальского языка. -| +| |[.filename]#print# |Программное обеспечение для печати. -|Инструменты для вёрстки (просмотрщики и тому подобное) тоже относятся сюда. +|Инструменты для настольных издательских систем (превьюеры и т. д.) также относятся сюда. -|[.filename]#python*# -|Программное обеспечение, связанное с языком http://www.python.org/[Python]. -| +|[.filename]#python#`*` +|Программное обеспечение, связанное с языком https://www.python.org/[Python]. +| -|[.filename]#ruby*# -|Программное обеспечение, связанное с языком http://www.ruby-lang.org/[Ruby]. -| +|[.filename]#ruby#`*` +|Программное обеспечение, связанное с языком https://www.ruby-lang.org/[Ruby]. +| -|[.filename]#rubygems*# -|Порты для пакетов http://www.rubygems.org/[RubyGems]. -| +|[.filename]#rubygems#`*` +|Порты пакетов https://www.rubygems.org/[RubyGems]. +| |[.filename]#russian# |Поддержка русского языка. -| +| -|[.filename]#scheme*# +|[.filename]#scheme#`*` |Программное обеспечение, связанное с языком Scheme. -| +| |[.filename]#science# -|Научные программы, которые не подпадают под другие категории, скажем, [.filename]#astro#, [.filename]#biology# или [.filename]#math#. -| +|Научные порты, которые не входят в другие категории, такие как [.filename]#astro#, [.filename]#biology# и [.filename]#math#. +| |[.filename]#security# -|Программы, обеспечивающие безопасность системы. -| +|Средства обеспечения безопасности. +| |[.filename]#shells# -|Различные командные процессоры. -| +|Командные оболочки. +| + +|[.filename]#spanish#`*` +|Поддержка испанского языка. +| |[.filename]#sysutils# |Системные утилиты. -| +| -|[.filename]#spanish*# -|Поддержка испанского языка. -| - -|[.filename]#tcl*# -|Порты, для работы которых нужен Tcl. -| +|[.filename]#tcl#`*` +|Порты, использующие Tcl для запуска. +| |[.filename]#textproc# -|Утилиты для обработки текстов. -|Инструменты для вёрстки помещаются в категорию [.filename]#print#, а не сюда. +|Средства обработки текста. +|Он не включает инструменты для настольных издательских систем, которые помещаются в [.filename]#print#. -|[.filename]#tk*# -|Порты, для работы которых нужен Tk. -| +|[.filename]#tk#`*` +|Порты, использующие Tk для работы. +| |[.filename]#ukrainian# |Поддержка украинского языка. -| +| |[.filename]#vietnamese# |Поддержка вьетнамского языка. -| +| + +|[.filename]#wayland#`*` +|Порты для поддержки сервера дисплея Wayland. +| -|[.filename]#windowmaker*# -|Порты для поддержки менеджера окон WindowMaker. -| +|[.filename]#windowmaker#`*` +|Порты для поддержки оконного менеджера Window Maker. +| |[.filename]#www# -|Программное обеспечение, связанное со всемирной паутиной. -|Поддержка языка HTML относится сюда же. +|Программное обеспечение, связанное с Всемирной паутиной. +|Поддержка языка HTML также относится сюда. |[.filename]#x11# -|X Window System и иже с ними. -|Эта категория предназначена только для программного обеспечения, которое поддерживает саму оконную систему. Не помещайте сюда обычные приложения для X: большинство из них должны быть перенесены в другие категории [.filename]#x11-*# (смотрите ниже). +|Система X Window и связанные компоненты. +|Эта категория предназначена только для программного обеспечения, которое напрямую поддерживает оконную систему. Не помещайте сюда обычные X-приложения. Большинство из них относятся к другим категориям [.filename]#x11-*# (см. ниже). |[.filename]#x11-clocks# -|Часы для X11. -| +|Часы X11. +| |[.filename]#x11-drivers# |Драйверы X11. -| +| |[.filename]#x11-fm# -|Менеджеры файлов для X11. -| +|Менеджеры файлов X11. +| |[.filename]#x11-fonts# -|Шрифты для X11 и утилиты для работы с ними. -| +|Шрифты и утилиты для работы со шрифтами в X11. +| |[.filename]#x11-servers# -|Серверы для X11. -| +|Серверы X11. +| |[.filename]#x11-themes# -|Темы для X11. -| +|Темы X11. +| |[.filename]#x11-toolkits# -|Пакеты разработчика для X11. -| +|Инструментарии X11. +| |[.filename]#x11-wm# -|Оконные менеджеры для X11. -| +|Оконные менеджеры X11. +| -|[.filename]#xfce*# -|Порты, связанные с окружением рабочего стола http://www.xfce.org/[Xfce]. -| +|[.filename]#xfce#`*` +|Порты, связанные с окружением рабочего стола https://www.xfce.org/[Xfce]. +| -|[.filename]#zope*# -|Поддержка http://www.zope.org/[Zope]. -| +|[.filename]#zope#`*` +|https://www.zope.org/[Zope] поддержка. +| |=== [[choosing-categories]] -=== Выбор правильной категории +=== Выбор подходящей категории -Так как многие категории перекрываются, вам часто необходимо будет выбирать, какая их них должна быть основной для вашего порта. Есть несколько правил, по которым можно решить этот вопрос. Вот список приоритетов, в уменьшающейся степени предпочтения: +Поскольку многие категории пересекаются, выбор основной категории для порта может быть утомительным. Существует несколько правил, регулирующих этот вопрос. Вот список приоритетов в порядке убывания важности: -* Первая категория должна быть физической категорий (смотрите <<porting-categories,выше>>). Это необходимо для создания пакетов. После этого виртуальные и физические категории могут смешиваться. -* Сначала всегда идут категории, специфичные для языков. Например, если ваш порт устанавливает японские шрифты для X11, то строчка `CATEGORIES` должна иметь вид [.filename]#japanese x11-fonts#. -* Более конкретные категории идут первыми перед более общими. В частности, редактор HTML должен быть описан как [.filename]#www editors#, а не наоборот. Кроме того, вы не должны указывать категорию [.filename]#net#, если порт относится к одной из категорий [.filename]#irc#, [.filename]#mail#, [.filename]#news#, [.filename]#security# или [.filename]#www#, так как [.filename]#net# включается автоматически. -* [.filename]#x11# используется как вторичная категория только в случае, если в качестве основной категории указан естественный язык. В частности, вам не нужно указывать [.filename]#x11# в качестве категории для приложений X. -* Режимы для редактора Emacs должны помещаться в ту же категорию, что и приложение, которое поддерживается этим режимом, а не в [.filename]#editors#. Например, режим Emacs для редактирования исходного кода некоторого языка программирования должен быть помещен в категорию [.filename]#lang#. -* Порты, устанавливающие загружаемые модули ядра, должны содержать виртуальную категорию [.filename]#kld# в строке `CATEGORIES`. Это одно из действий, выполняемых автоматически с добавлением `kmod` в строке `USES`. -* [.filename]#misc# не должна указываться вместе с любой другой невиртуальной категорией. Если вы указываете `misc` вместе с чем-то ещё в строке `CATEGORIES`, это значит, что вы можете спокойно удалить `misc` и просто поместить порт в этот другой подкаталог! -* Если ваш порт решительным образом не подпадает ни под какую категорию, поместите его в [.filename]#misc#. +* Первая категория должна быть физической (см. crossref:makefiles[porting-categories,выше]). Это необходимо для работы упаковки. Виртуальные категории и физические категории могут чередоваться после этого. +* Языковые категории всегда указываются первыми. Например, если порт устанавливает японские шрифты для X11, то строка `CATEGORIES` будет выглядеть так: [.filename]#japanese x11-fonts#. +* Конкретные категории перечислены перед менее специфичными. Например, HTML-редактор указывается как [.filename]#www editors#, а не наоборот. Также не следует указывать [.filename]#net#, если порт принадлежит к любой из категорий [.filename]#irc#, [.filename]#mail#, [.filename]#news#, [.filename]#security# или [.filename]#www#, так как [.filename]#net# подразумевается автоматически. +* [.filename]#x11# используется как вторичная категория только в случае, когда основной категорией указан естественный язык. В частности, не указывайте [.filename]#x11# в строке категории для X-приложений. +* Режимы Emacs размещаются в той же категории портов, что и приложение, поддерживаемое данным режимом, а не в [.filename]#editors#. Например, режим Emacs для редактирования исходных файлов какого-либо языка программирования попадает в [.filename]#lang#. +* Порты, устанавливающие загружаемые модули ядра, также имеют виртуальную категорию [.filename]#kld# в строке `CATEGORIES`. Это одна из вещей, автоматически обрабатываемых при добавлении `USES=kmod`. +* [.filename]#misc# не встречается вместе с другими невиртуальными категориями. Если `misc` указан вместе с чем-то еще в `CATEGORIES`, это означает, что `misc` можно безопасно удалить, а порт разместить только в другом подкаталоге. +* Если порт действительно не подходит никуда больше, поместите его в [.filename]#misc#. -Если вы не уверены в правильности выбора категории, пожалуйста, отметьте это в вашем сообщении man:send-pr[1], чтобы мы могли обсудить это до того, как включить порт в Коллекцию. Если вы являетесь коммиттером, пошлите замечание на адрес {freebsd-ports}, чтобы мы могли обсудить это. Зачастую новые порты помещаются не в ту категорию только для того, чтобы их оттуда сразу же удалили. Это приводит к излишнему и ненужному росту основного хранилища исходных текстов. +Если категория не определена четко, пожалуйста, укажите это в комментарии при https://bugs.freebsd.org/submit/[отправке порта] в баг-трекере, чтобы мы могли обсудить её перед импортом. Как коммиттер, отправьте сообщение в рассылку {freebsd-ports}, чтобы мы сначала обсудили это. Слишком часто новые порты импортируются в неправильную категорию, после чего их сразу же приходится перемещать. [[proposing-categories]] === Предложение новой категории -Поскольку со временем Коллекция Портов увеличилась, то в связи с этим были добавлены различные новые категории. Новые категории могут быть или _виртуальными_ категориями-которые не имеют соответствующего подкаталога в дереве портов-или _физическими_ категориями-у которых он есть. Следующий текст содержит обсуждение вопросов, возникающих при создании новой физической категории, чтобы вы могли понимать их, когда предложите новую категорию. +По мере роста Коллекции портов со временем были введены различные новые категории. Новые категории могут быть _виртуальными_ — те, у которых нет соответствующего подкаталога в дереве портов, или _физическими_ — те, у которых он есть. В этом разделе обсуждаются вопросы, связанные с созданием новой физической категории. Внимательно ознакомьтесь с ним, прежде чем предлагать новую. -В соответствие с существующей практикой мы избегаем создания новой физической категории, пока достаточно большое число портов логически ей не принадлежит или же порты, которые могли бы ей принадлежать, не являются логически обособленной группой, представляющей для всех ограниченный интерес (в частности, категории, относящиеся к естественным языкам); предпочтительно выполнение обоих условий. +Наша текущая практика заключается в том, чтобы избегать создания новой физической категории, если только либо большое количество портов логически принадлежит к ней, либо порты, которые к ней относятся, представляют собой логически обособленную группу, представляющую ограниченный общий интерес (например, категории, связанные с разговорными человеческими языками), или, желательно, оба условия одновременно. -Основной причиной для этого является то, что такое изменение создает extref:{committers-guide}[изрядное количество работы, ports] и для коммиттеров, и для всех тех пользователей, которые отслеживают изменения в Коллекции Портов. В дополнение, предложенная категория создает естественное разногласие. (Пожалуй, потому что не существует четкого соглашения, является ли категория "слишком большой", или должны ли категории предоставлять себя для просмотра (и, таким образом, какое количество категорий было бы идеальным значением), и так далее.) +Обоснование этого заключается в том, что такое изменение создает extref:{committers-guide}[значительный объем работы, ports] как для коммиттеров, так и для всех пользователей, которые отслеживают изменения в Коллекции портов. Кроме того, предлагаемые изменения категорий, как правило, вызывают споры. (Возможно, это связано с отсутствием четкого консенсуса относительно того, когда категория становится «слишком большой», а также относительно того, должны ли категории способствовать удобству просмотра (и, следовательно, какое количество категорий было бы идеальным), и так далее.) -Процедура: +Вот процедура: [.procedure] -==== -. Предложите новую категорию на {freebsd-ports}. Вам следует включить для новой категории детальное обоснование, в том числе почему вы считаете, что существующие категории не являются достаточными, и список существующих портов, предложенных для перемещения. (Если есть новые порты, ожидающие в GNATS и попадающие в эту категорию, то укажите их тоже.) Если вы являетесь сопровождающим и/или отправителем, то укажите это соответственно, так как это может помочь вам в вашем деле. -. Принимайте участие в обсуждении. -. Если кажется, что для вашей идеи появилась поддержка, отправьте PR, который будет включать обоснование и список существующих портов, которые надо переместить. В идеале этот PR должен также включать патчи для следующего: +. Предложите новую категорию на {freebsd-ports}. Включите подробное обоснование для новой категории, объясните, почему существующие категории недостаточны, и укажите список существующих портов, предлагаемых к перемещению. (Если в Bugzilla есть ожидающие рассмотрения новые порты, которые подходят под эту категорию, также перечислите их.) Если вы являетесь сопровождающим и/или подающим предложение, укажите это, так как это может помочь в рассмотрении. +. Участвуйте в обсуждении. +. Если кажется, что идея находит поддержку, оформите PR, включающий как обоснование, так и список существующих портов, которые необходимо переместить. В идеале, этот PR также должен содержать следующие исправления: -** [.filename]#Makefile#'ы для новых портов в результате репозиторного копирования -** [.filename]#Makefile# для категорий старых портов -** [.filename]#Makefile#'ы для портов, зависящих от старых портов -** (в дополнение, вы можете включить другие файлы, требующие изменений, согласно процедуре из Руководства Коммиттера.) +** [.filename]##Makefile## для новых портов после копирования их репозитория +** [.filename]#Makefile# для новой категории +** [.filename]#Makefile# для старых категорий портов +** [.filename]##Makefile## для портов, зависящих от старых портов +** (для дополнительной оценки включите другие файлы, которые необходимо изменить, в соответствии с процедурой, описанной в Руководстве коммиттера.) -. Поскольку это затрагивает инфраструктуру портов и охватывает не только выполнение репозиторного копирования, но также, возможно, и выполнение регрессивных тестов на кластере построения, то PR должна назначать себе {portmgr}. -. Если этот PR одобрен, то коммиттеру нужно продолжить остальную часть процедуры, которая extref:{committers-guide}[изложена в Руководстве Коммиттера, ports]. -==== +. Поскольку это затрагивает инфраструктуру портов и включает перемещение и исправление многих портов, а также, возможно, проведение регрессионных тестов на сборочном кластере, назначьте PR для {portmgr}. +. Если этот PR будет одобрен, коммиттер должен будет выполнить оставшуюся часть процедуры, extref:{committers-guide}[описанной в Руководстве коммиттера,ports]. -Предложение новой виртуальной категории должно быть схожим с вышеизложенным, но при этом затрагивать намного меньше, поскольку ни один из портов не будет перемещен в действительности. В этом случае единственными патчами, включенными в PR, будут те, что добавляют новую категорию в `CATEGORIES` каждого из затрагиваемых портов. +Предложение новой виртуальной категории аналогично описанному выше, но гораздо менее трудоёмко, так как фактически не потребуется перемещать порты. В этом случае единственные патчи, которые нужно включить в PR, — это добавление новой категории в `CATEGORIES` затронутых портов. [[proposing-reorg]] -=== Предложение реорганизации всех категорий +=== Предложение о реорганизации всех категорий -Время от времени кто-нибудь предлагает произвести реорганизацию категорий либо до двухуровневой, либо другого типа на основе ключевых слов. На данный момент из этих предложений ничего не получилось, потому что, хотя они просты в реализации, но предполагаемая переделка всей коллекции портов по меньшей мере приводит в уныние. Пожалуйста, прочтите историю этих предложений в архивах рассылок перед тем, как присылать свои соображения; более того, вы должны быть готовы представить работающий прототип. +Изредка кто-то предлагает реорганизовать категории, используя либо двухуровневую структуру, либо какую-либо другую структуру ключевых слов. На сегодняшний день ни одно из этих предложений не было реализовано, потому что, хотя их очень легко выдвинуть, усилия, необходимые для переработки всей существующей коллекции портов в рамках любой реорганизации, пугают, мягко говоря. Пожалуйста, ознакомьтесь с историей этих предложений в архивах списка рассылки, прежде чем публиковать эту идею. Более того, будьте готовы к тому, что вас попросят предоставить рабочий прототип. [[makefile-distfiles]] -== Дистрибутивные файлы +== Файлы дистрибутива -Во второй части [.filename]#Makefile# задаётся, какие файлы и откуда должны быть сгружены для того, чтобы построить порт. +Вторая часть [.filename]#Makefile# описывает файлы, которые необходимо загрузить для сборки порта, и места, откуда их можно скачать. -=== `DISTVERSION/DISTNAME` +[[makefile-distname]] +=== `DISTNAME` -В переменной `DISTNAME` указывается имя порта так, как назвали его создатели программного обеспечения. Значение `DISTNAME` по умолчанию совпадает с `${PORTNAME}-${PORTVERSION}`, так что переопределяете её значение только в случае необходимости. `DISTNAME` используется только в двух местах. Во-первых, список дистрибутивных файлов (`DISTFILES`) по умолчанию состоит из `${DISTNAME}${EXTRACT_SUFX}`. И во-вторых, предполагается, что дистрибутивный файл будет распакован в подкаталог с именем `WRKSRC`, значение которого по умолчанию есть не что иное, как [.filename]#work/${DISTNAME}#. +`DISTNAME` — это имя порта, используемое авторами программного обеспечения. По умолчанию `DISTNAME` имеет значение `${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}`, а если не задано, `DISTVERSION` по умолчанию принимает значение `${PORTVERSION}`, поэтому переопределяйте `DISTNAME` только при необходимости. `DISTNAME` используется только в двух случаях. Во-первых, список файлов дистрибутива (`DISTFILES`) по умолчанию имеет значение `${DISTNAME}${EXTRACT_SUFX}`. Во-вторых, ожидается, что файл дистрибутива распакуется в подкаталог с именем `WRKSRC`, который по умолчанию равен [.filename]#work/${DISTNAME}#. -Названия некоторых дистрибутивов, которые не укладываются в `${PORTNAME}-${PORTVERSION}`-схему, могут быть автоматически обработаны посредством установки переменной `DISTVERSION`. `PORTVERSION` и `DISTNAME` будут унаследованы автоматически, но конечно же могут быть переопределены. Следующая таблица демонстрирует некоторые примеры: +Некоторые названия дистрибутивов от поставщиков, которые не соответствуют схеме `${PORTNAME}-${PORTVERSION}`, могут обрабатываться автоматически путем установки `DISTVERSIONPREFIX`, `DISTVERSION` и `DISTVERSIONSUFFIX`. `PORTVERSION` будет автоматически вычисляться из `DISTVERSION`. -[.informaltable] -[cols="1,1", frame="none", options="header"] -|=== -| DISTVERSION -| PORTVERSION +[IMPORTANT] +==== +Только одна из переменных `PORTVERSION` и `DISTVERSION` может быть установлена одновременно. Если `DISTVERSION` не определяет корректную `PORTVERSION`, не используйте `DISTVERSION`. +==== -|0.7.1d -|0.7.1.d +Если схема версий исходного проекта может быть преобразована в схему, совместимую с портами, установите некоторую переменную в версию исходного проекта, _не используйте_ имя переменной `DISTVERSION`. Установите `PORTVERSION` в вычисленную версию на основе созданной вами переменной и задайте `DISTNAME` соответствующим образом. -|10Alpha3 -|10.a3 +Если схема версионирования вышестоящего проекта не может быть легко преобразована в значение, совместимое с портами, установите `PORTVERSION` в разумное значение и задайте `DISTNAME` как `PORTNAME` с дословной версией вышестоящего проекта. -|3Beta7-pre2 -|3.b7.p2 +[[makefile-distname-ex1]] +.Получение `PORTVERSION` вручную +[example] +==== +BIND9 использует схему версионирования, несовместимую с версиями портов (в версиях используется `-`), и её нельзя получить с помощью `DISTVERSION`, так как после выпуска 9.9.9 выходят «уровни исправлений» в формате `9.9.9-P1`. `DISTVERSION` преобразует это в `9.9.9.p1`, что в схеме версионирования портов означает 9.9.9 pre-release 1, то есть версию, предшествующую 9.9.9, а не следующую за ней. Поэтому `PORTVERSION` вручную формируется из переменной `ISCVERSION`, чтобы получить `9.9.9p1`. -|8:f_17 -|8f.17 -|=== +Порядок, в котором система портов и pkg будут сортировать версии, проверяется с помощью аргумента `-t` из man:pkg-version[8]: + +[source, shell] +.... +% pkg version -t 9.9.9 9.9.9.p1 +> <.> +% pkg version -t 9.9.9 9.9.9p1 +< <.> +.... + +<.> Знак `>` означает, что первый аргумент, переданный в `-t`, больше второго аргумента. `9.9.9` находится после `9.9.9.p1`. +<.> Знак `<` означает, что первый аргумент, переданный в `-t`, меньше второго аргумента. `9.9.9` находится перед `9.9.9p1`. + +В файле [.filename]#Makefile# порта, например package:dns/bind99[], это достигается с помощью: + +[.programlisting] +.... +PORTNAME= bind +PORTVERSION= ${ISCVERSION:S/-P/P/:S/b/.b/:S/a/.a/:S/rc/.rc/} +CATEGORIES= dns net +MASTER_SITES= ISC/bind9/${ISCVERSION} +PKGNAMESUFFIX= 99 +DISTNAME= ${PORTNAME}-${ISCVERSION} + +MAINTAINER= mat@FreeBSD.org +COMMENT= BIND DNS suite with updated DNSSEC and DNS64 +WWW= https://www.isc.org/bind/ + +LICENSE= ISCL + +# ISC releases things like 9.8.0-P1 or 9.8.1rc1, which our versioning does not like +ISCVERSION= 9.9.9-P6 +.... + +Определите версию вышестоящего пакета в `ISCVERSION`, с комментарием, объясняющим, _почему_ это необходимо. Используйте `ISCVERSION` для получения совместимого с портами `PORTVERSION`. Используйте `ISCVERSION` напрямую для получения правильного URL для загрузки файла дистрибутива. Используйте `ISCVERSION` напрямую для именования дистрибутивного файла. +==== + +[[makefile-distname-ex2]] +.Получить `DISTNAME` из `PORTVERSION` +[example] +==== +Время от времени имя файла дистрибутива имеет мало отношения или вообще никакого отношения к версии программного обеспечения. + +В пакете package:comms/kermit[], в файле дистрибутива присутствует только последний элемент версии: + +[.programlisting] +.... +PORTNAME= kermit +PORTVERSION= 9.0.304 +CATEGORIES= comms ftp net +MASTER_SITES= ftp://ftp.kermitproject.org/kermit/test/tar/ +DISTNAME= cku${PORTVERSION:E}-dev20 +.... + +Модификатор `:E` man:make[1] возвращает суффикс переменной, в данном случае `304`. Файл дистрибутива корректно создаётся как `cku304-dev20.tar.gz`. +==== + +[[makefile-distname-ex3]] +.Экзотический случай 1 +[example] +==== +Иногда нет связи между названием программы, её версией и файлом дистрибутива, в котором она распространяется. + +Из пакета package:audio/libworkman[]: + +[.programlisting] +.... +PORTNAME= libworkman +PORTVERSION= 1.4 +CATEGORIES= audio +MASTER_SITES= LOCAL/jim +DISTNAME= ${PORTNAME}-1999-06-20 +.... + +==== + +[[makefile-distname-ex4]] +.Экзотический случай 2 +[example] +==== +В пакете package:comms/librs232[] файл дистрибутива не имеет версии, поэтому необходимо использовать crossref:makefiles[makefile-dist_subdir,`DIST_SUBDIR`]: + +[.programlisting] +.... +PORTNAME= librs232 +PORTVERSION= 20160710 +CATEGORIES= comms +MASTER_SITES= http://www.teuniz.net/RS-232/ +DISTNAME= RS-232 +DIST_SUBDIR= ${PORTNAME}-${PORTVERSION} +.... + +==== [NOTE] ==== -Значения переменных `PKGNAMEPREFIX` и `PKGNAMESUFFIX` не влияют на значение `DISTNAME`. Заметьте также, что если значение `WRKSRC` равно [.filename]#work/${PORTNAME}-${PORTVERSION}#, и в случае, когда оригинальный архив называется по имени, отличном от `${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}`, скорее всего, вы должны оставить `DISTNAME` как есть- лучше переопределить `DISTFILES`, чем задавать значения как `DISTNAME`, так и `WRKSRC` (и, возможно, ещё и `EXTRACT_SUFX`). +`PKGNAMEPREFIX` и `PKGNAMESUFFIX` не влияют на `DISTNAME`. Также обратите внимание, что если `WRKSRC` равно [.filename]#${WRKDIR}/${DISTNAME}#, а исходный архив с исходным кодом называется иначе, чем `${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}`, оставьте `DISTNAME` без изменений — определение только `DISTFILES` проще, чем определение и `DISTNAME`, и `WRKSRC` (а возможно, и `EXTRACT_SUFX`). ==== +[[makefile-master_sites]] === `MASTER_SITES` -Содержит часть с каталогом FTP/HTTP-URL, которая указывает на оригинальный архив на сервере `MASTER_SITES`. Не забудьте лидирующий слэш ([.filename]#/#)! +Запишите именем каталога из FTP/HTTP-URL, указывающего на исходный tarball, в `MASTER_SITES`. Не забудьте завершающий слэш ([.filename]#/#)! + +Макросы `make` будут пытаться использовать эту спецификацию для загрузки файла дистрибутива с помощью `FETCH`, если не смогут найти его уже в системе. + +Рекомендуется включать в этот список несколько сайтов, желательно с разных континентов. Это обеспечит защиту от проблем в глобальной сети. + +[IMPORTANT] +==== +`MASTER_SITES` не должен быть пустым. Он должен указывать на реальный сайт, где размещены файлы дистрибутива. Он не может указывать на веб-архивы или кэшированные сайты с файлами дистрибутива FreeBSD. Единственное исключение из этого правила — порты, у которых нет файлов дистрибутива. Например, мета-порты не имеют файлов дистрибутива, поэтому `MASTER_SITES` не нужно задавать. +==== + +[[makefile-master_sites-shorthand]] +==== Использование переменных `MASTER_SITE_*` -Макрос команды `make` будет пытаться воспользоваться этой переменной для получения дистрибутивного файла с помощью программы `FETCH`, если он не будет найден в системе. +Для популярных архивов, таких как SourceForge (`SOURCEFORGE`), GNU (`GNU`) или Perl CPAN (`PERL_CPAN`), доступны сокращённые обозначения. `MASTER_SITES` может использовать их напрямую: -Рекомендуется помещать в список много сайтов, предпочтительно с разных континентов. Это поможет при наличии проблем с мировой сетью. Мы даже планируем добавить поддержку автоматического определения ближайшего сайта и сгрузки файлов оттуда; наличие нескольких сайтов будет способствовать этому начинанию. +[.programlisting] +.... +MASTER_SITES= GNU/make +.... -Если оригинальный архив находится на одном из таких популярных серверов, как SourceForge, GNU или Perl CPAN, то указывайте эти сайты в простой форме при помощи `MASTER_SITE_*` (к примеру, `MASTER_SITE_SOURCEFORGE`, `MASTER_SITE_GNU` или `MASTER_SITE_PERL_CPAN`. Просто укажите в переменной `MASTER_SITES` одно из этих значений, а в переменной `MASTER_SITE_SUBDIR` задайте путь к архиву. Вот пример: +Старый расширенный формат по-прежнему работает, но все порты были преобразованы в компактный формат. Расширенный формат выглядит следующим образом: [.programlisting] .... @@ -782,30 +1169,78 @@ MASTER_SITES= ${MASTER_SITE_GNU} MASTER_SITE_SUBDIR= make .... -Или можно использовать сокращенный формат: +Эти значения и переменные определены в https://cgit.freebsd.org/ports/tree/Mk/bsd.sites.mk[Mk/bsd.sites.mk]. Новые записи добавляются часто, поэтому обязательно проверяйте последнюю версию этого файла перед отправкой порта. + +[TIP] +==== +Для любой переменной `MASTER_SITE_FOO` можно использовать сокращение `_FOO_`. Например, используйте: [.programlisting] .... -MASTER_SITES= GNU/make +MASTER_SITES= FOO +.... + +Если требуется `MASTER_SITE_SUBDIR`, используйте следующее: + +[.programlisting] .... +MASTER_SITES= FOO/bar +.... + +==== + +[NOTE] +==== +Некоторые имена `MASTER_SITE_*` довольно длинные, и для удобства использования были определены сокращения: + +[[makefile-master_sites-shortcut]] +.Сокращения для макросов `MASTER_SITE_*` +[cols="1,1", frame="none", options="header"] +|=== +| Макрос +| Сокращение -Эти переменные определены в файле [.filename]#/usr/ports/Mk/bsd.sites.mk#. Всё время добавляются новые записи, так что обращайтесь к последней версии этого файла перед тем, как послать нам свой порт. +|`PERL_CPAN` +|`CPAN` + +|`GITHUB` +|`GH` + +|`GITHUB_CLOUD` +|`GHC` + +|`LIBREOFFICE_DEV` +|`LODEV` + +|`NETLIB` +|`NL` + +|`RUBYGEMS` +|`RG` + +|`SOURCEFORGE` +|`SF` +|=== +==== -Для популярных сайтов существует несколько _магических_ макросов с заранее известной структурой каталогов. Используйте для них сокращения, и система попытается угадать для вас правильный подкаталог. +[[makefile-master_sites-magic]] +==== Волшебные макросы MASTER_SITES + +Существует несколько "волшебных" макросов для популярных сайтов с предсказуемой структурой каталогов. Для них достаточно использовать сокращение, и система автоматически выберет подкаталог. Например, для порта с именем `Stardict`, версии `1.2.3`, размещенного на SourceForge, добавьте следующую строку: [.programlisting] .... MASTER_SITES= SF .... -Если попытка угадать не удалась, то это может быть переписано следующим образом. +подразумевает подкаталог с именем `/project/stardict/stardict/1.2.3`. Если подразумеваемый каталог указан неверно, его можно переопределить: [.programlisting] .... MASTER_SITES= SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION} .... -Что также можно записать в таком виде: +Это также можно записать как [.programlisting] .... @@ -813,87 +1248,697 @@ MASTER_SITES= SF MASTER_SITE_SUBDIR= stardict/WyabdcRealPeopleTTS/${PORTVERSION} .... -.Популярные магические макросы для `MASTER_SITES` +[[makefile-master_sites-popular]] +.Волшебные макросы `MASTER_SITES` [cols="1,1", frame="none", options="header"] |=== | Макрос -| Предполагаемый подкаталог +| Предполагаемая поддиректория + +|`APACHE_COMMONS_BINARIES` +|`${PORTNAME:S,commons-,,}` + +|`APACHE_COMMONS_SOURCE` +|`${PORTNAME:S,commons-,,}` |`APACHE_JAKARTA` -|`/dist/jakarta/${PORTNAME:S,-,,/,}/source` +|`${PORTNAME:S,-,/,}/source` |`BERLIOS` -|`/${PORTNAME:L}` +|`${PORTNAME:tl}.berlios` |`CHEESESHOP` -|`/packages/source/source/${DISTNAME:C/(.).\*/\1/}/${DISTNAME:C/(.*)-[0-9].*/\1/}` +|`source/${DISTNAME:C/(.).\*/\1/}/${DISTNAME:C/(.*)-[0-9].*/\1/}` + +|`CPAN` +|`${PORTNAME:C/-.*//}` |`DEBIAN` -|`/debian/pool/main/${PORTNAME:C/^((lib)?.).*$/\1/}/${PORTNAME}` +|`pool/main/${PORTNAME:C/^((lib)?.).*$/\1/}/${PORTNAME}` + +|`FARSIGHT` +|`${PORTNAME}` + +|`FESTIVAL` +|`${PORTREVISION}` |`GCC` -|`/pub/gcc/releases/${DISTNAME}` +|`releases/${DISTNAME}` + +|`GENTOO` +|`distfiles` + +|`GIMP` +|`${PORTNAME}/${PORTVERSION:R}/` + +|`GH` +|`${GH_ACCOUNT}/${GH_PROJECT}/tar.gz/${GH_TAGNAME}?dummy=/` + +|`GHC` +|`${GH_ACCOUNT}/${GH_PROJECT}/` |`GNOME` -|`/pub/GNOME/sources/${PORTNAME}/${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}` +|`sources/${PORTNAME}/${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}` |`GNU` -|`/gnu/${PORTNAME}` +|`${PORTNAME}` + +|`GNUPG` +|`${PORTNAME}` + +|`GNU_ALPHA` +|`${PORTNAME}` + +|`HORDE` +|`${PORTNAME}` + +|`LODEV` +|`${PORTNAME}` + +|`MATE` +|`${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}` |`MOZDEV` -|`/pub/mozdev/${PORTNAME:L}` +|`${PORTNAME:tl}` -|`PERL_CPAN` -|`/pub/CPAN/modules/by-module/${PORTNAME:C/-.*//}` +|`NL` +|`${PORTNAME}` -|`PYTHON` -|`/ftp/python/${PYTHON_PORTVERSION:C/rc[0-9]//}` +|`QT` +|`archive/qt/${PORTVERSION:R}` -|`RUBYFORGE` -|`/${PORTNAME:L}` +|`SAMBA` +|`${PORTNAME}` |`SAVANNAH` -|`/${PORTNAME:L}` +|`${PORTNAME:tl}` |`SF` -|`/project/${PORTNAME:L}/${PORTNAME:L}/${PORTVERSION}` +|`${PORTNAME:tl}/${PORTNAME:tl}/${PORTVERSION}` +|=== + +[[makefile-master_sites-github]] +=== `USE_GITHUB` + +Если файл дистрибутива получен из определённого коммита или тега на https://github.com/[GitHub], для которого нет официально выпущенного файла, существует простой способ автоматически установить правильные значения `DISTNAME` и `MASTER_SITES`. + +[WARNING] +==== +По состоянию на 2023-02-21 link:https://github.blog/2023-02-21-update-on-the-future-stability-of-source-code-archives-and-hashes/[GitHub] объявили, что загрузки исходного кода будут стабильными в течение года. Пожалуйста, переключитесь на ресурсы выпусков (release assets), а если они недоступны, запросите их создание у вышестоящих разработчиков. +==== + +Доступны следующие переменные: + +[[makefile-master_sites-github-description]] +.`USE_GITHUB` Описание +[cols="1,1,1", options="header"] +|=== +| Переменная +| Описание +| По умолчанию + +|`GH_ACCOUNT` +|Имя учётной записи пользователя GitHub, который размещает проект +|`${PORTNAME}` + +|`GH_PROJECT` +|Название проекта на GitHub +|`${PORTNAME}` + +|`GH_TAGNAME` +|Имя тега для загрузки (2.0.1, хэш, ...) Использование имени ветки здесь некорректно. Также можно использовать хэш идентификатора коммита для создания снимка состояния. +|`${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}` + +|`GH_SUBDIR` +|Когда программному обеспечению требуется дополнительный файл дистрибутива для извлечения в +`${WRKSRC}`, можно использовать эту переменную. Примеры можно найти в +crossref:makefiles[makefile-master_sites-github-multiple, Загрузка нескольких файлов из GitHub] для получения дополнительной информации. +|(отсутствует) + +|`GH_TUPLE` +|`GH_TUPLE` позволяет объединить `GH_ACCOUNT`, `GH_PROJECT`, `GH_TAGNAME` и `GH_SUBDIR` в одну переменную. Формат следующий: _account_`:`_project_`:`_tagname_`:`_group_`/`_subdir_. Часть `/`_subdir_ является необязательной. Это полезно, когда требуется получить несколько проектов с GitHub. +| +|=== + +[IMPORTANT] +==== +Не используйте `GH_TUPLE` для файла дистрибутива по умолчанию, так как у него нет значения по умолчанию. +==== + +[[makefile-master_sites-github-ex1]] +.Простое использование `USE_GITHUB` +[example] +==== + +При попытке создать порт для версии `1.2.7` pkg от пользователя FreeBSD на github, по адресу https://github.com/freebsd/pkg/[], файл [.filename]#Makefile# в итоге будет выглядеть следующим образом (незначительно сокращено для примера): + +[.programlisting] +.... +PORTNAME= pkg +DISTVERSION= 1.2.7 + +USE_GITHUB= yes +GH_ACCOUNT= freebsd +.... + +Он автоматически получит `MASTER_SITES` установленным в `GH` и `WRKSRC` в `${WRKDIR}/pkg-1.2.7`. +==== + +[[makefile-master_sites-github-ex2]] +.Более полное использование `USE_GITHUB` +[example] +==== +При попытке создать порт для самой последней версии pkg от пользователя FreeBSD на github, по адресу https://github.com/freebsd/pkg/[], файл [.filename]#Makefile# в итоге выглядит следующим образом (незначительно сокращено для примера): + +[.programlisting] +.... +PORTNAME= pkg-devel +DISTVERSION= 1.3.0.a.20140411 + +USE_GITHUB= yes +GH_ACCOUNT= freebsd +GH_PROJECT= pkg +GH_TAGNAME= 6dbb17b +.... + +Он автоматически получит `MASTER_SITES` со значением `GH` и `WRKSRC` со значением `${WRKDIR}/pkg-6dbb17b`. + +[TIP] +**** +`20140411` — это дата коммита, указанного в `GH_TAGNAME`, а не дата редактирования файла [.filename]#Makefile# или дата создания коммита. +**** + +==== + +[[makefile-master_sites-github-ex3]] +.Использование `USE_GITHUB` с `DISTVERSIONPREFIX` +[example] +==== +Время от времени `GH_TAGNAME` немного отличается от `DISTVERSION`. Например, если версия `1.0.2`, то тег будет `v1.0.2`. В таких случаях можно использовать `DISTVERSIONPREFIX` или `DISTVERSIONSUFFIX`: + +[.programlisting] +.... +PORTNAME= foo +DISTVERSIONPREFIX= v +DISTVERSION= 1.0.2 + +USE_GITHUB= yes +.... + +Он автоматически установит `GH_TAGNAME` в `v1.0.2`, в то время как `WRKSRC` останется `${WRKDIR}/foo-1.0.2`. +==== + +[[makefile-master_sites-github-ex4]] +.Использование `USE_GITHUB` при отсутствии версий у исходного проекта +[example] +==== +Если никогда не было версии вышестоящего репозитория, не изобретайте её, например `0.1` или `1.0`. Создайте порт с `DISTVERSION` в формате `g__YYYYMMDD__`, где `g` означает Git, а `_YYYYMMDD_` представляет дату коммита, указанного в `GH_TAGNAME`. + +[.programlisting] +.... +PORTNAME= bar +DISTVERSION= g20140411 + +USE_GITHUB= yes +GH_TAGNAME= c472d66b +.... + +Это создаёт схему версионирования, которая увеличивается со временем и всё ещё находится до версии `0`. Подробности об использовании man:pkg-version[8] для сравнения версий смотрите в crossref:makefiles[makefile-versions-ex-pkg-version, этой секции]: + +[source, shell] +.... +% pkg version -t g20140411 0 +< +.... + +Что означает, что использование `PORTEPOCH` не потребуется, если вышестоящий проект решит сократить версии в будущем. +==== + +[[makefile-master_sites-github-ex5]] +.Использование `USE_GITHUB` для доступа к коммиту между двумя версиями +[example] +==== +Если текущая версия программного обеспечения использует тег Git, и порт необходимо обновить до более новой промежуточной версии без тега, используйте man:git-describe[1], чтобы определить версию для использования: + +[source, shell] +.... +% git describe --tags f0038b1 +v0.7.3-14-gf0038b1 +.... + +`v0.7.3-14-gf0038b1` можно разделить на три части: + +`v0.7.3`:: +Это последний тег Git, который появляется в истории коммитов перед запрошенным коммитом. + +`-14`:: +Это означает, что запрошенный коммит `f0038b1` является 14-м коммитом после тега `v0.7.3`. + +`-gf0038b1`:: +`-g` означает "Git", а `f0038b1` — это хеш коммита, на который указывает данная ссылка. + +[.programlisting] +.... +PORTNAME= bar +DISTVERSIONPREFIX= v +DISTVERSION= 0.7.3-14 +DISTVERSIONSUFFIX= -gf0038b1 + +USE_GITHUB= yes +.... + +Это создаёт схему версионирования, которая увеличивается со временем (точнее, с коммитами) и не конфликтует с созданием версии `0.7.4`. Подробности об использовании man:pkg-version[8] для сравнения версий смотрите в crossref:makefiles[makefile-versions-ex-pkg-version, этой секции] : + +[source, shell] +.... +% pkg version -t 0.7.3 0.7.3.14 +< +% pkg version -t 0.7.3.14 0.7.4 +< +.... + +[NOTE] +**** +Если запрошенный коммит совпадает с тегом, по умолчанию отображается более короткое описание. Полная версия эквивалентна: + +[source, shell] +.... +% git describe --tags c66c71d +v0.7.3 + +% git describe --tags --long c66c71d +v0.7.3-0-gc66c71d +.... + +**** + +==== + +[[makefile-master_sites-github-multiple]] +==== Извлечение нескольких файлов из GitHub + +Фреймворк `USE_GITHUB` также поддерживает загрузку нескольких файлов дистрибутива из разных мест в GitHub. Он работает очень похоже на crossref:makefiles[porting-master-sites-n, Файлы дистрибуции или патчей из нескольких мест]. + +В `GH_ACCOUNT`, `GH_PROJECT` и `GH_TAGNAME` добавляются несколько значений. Каждому различному значению присваивается группа. Основное значение может не иметь группы или принадлежать группе `:DEFAULT`. Значение может быть опущено, если оно совпадает со значением по умолчанию, указанным в crossref:makefiles[makefile-master_sites-github-description,описании `USE_GITHUB`]. + +`GH_TUPLE` также можно использовать, когда имеется множество файлов дистрибутива. Это помогает сохранять учётные данные, проект, имя тега и информацию о группе в одном месте. + +Для каждой группы создаётся вспомогательная переменная `${WRKSRC_group}`, содержащая каталог, в который был извлечён файл. Переменные `${WRKSRC_group}` могут использоваться для перемещения каталогов во время `post-extract`, добавления в `CONFIGURE_ARGS` или любых других действий, необходимых для корректной сборки программного обеспечения. + +[CAUTION] +==== +Часть `:__group__` _должна_ использоваться _только для одного_ файла дистрибутива. Она служит уникальным ключом, и её повторное использование приведёт к перезаписи предыдущих значений. +==== + +[NOTE] +==== +Поскольку это всего лишь синтаксический сахар над `DISTFILES` и `MASTER_SITES`, имена групп должны соответствовать ограничениям на имена групп, описанным в crossref:makefiles[porting-master-sites-n, Файлы дистрибутивов или патчей из нескольких источников] +==== + +При получении нескольких файлов из GitHub иногда файл дистрибутива по умолчанию не загружается из GitHub. Чтобы отключить загрузку файла дистрибутива по умолчанию, установите: + +[.programlisting] +.... +USE_GITHUB= nodefault +.... + +[IMPORTANT] +==== +При использовании `USE_GITHUB=nodefault` в [.filename]#Makefile# необходимо указать `DISTFILES` в его crossref:porting-order[porting-order-portname,верхнем блоке]. Определение должно быть следующим: + +[.programlisting] +.... +DISTFILES= ${DISTNAME}${EXTRACT_SUFX} +.... + +==== + +[[makefile-master_sites-github-multi]] +.Использование `USE_GITHUB` с несколькими файлами дистрибутива +[example] +==== +Время от времени возникает необходимость загрузить более одного файла дистрибутива. Например, когда вышестоящий репозиторий git использует подмодули. Это можно легко сделать с помощью групп в переменных `GH_*`: + +[.programlisting] +.... +PORTNAME= foo +DISTVERSION= 1.0.2 + +USE_GITHUB= yes +GH_ACCOUNT= bar:icons,contrib +GH_PROJECT= foo-icons:icons foo-contrib:contrib +GH_TAGNAME= 1.0:icons fa579bc:contrib +GH_SUBDIR= ext/icons:icons + +CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} +.... + +Это загрузит три файла дистрибутива с github. Стандартный берется из [.filename]#foo/foo# и имеет версию `1.0.2`. Второй, с группой `icons`, берется из [.filename]#bar/foo-icons# и имеет версию `1.0`. Третий берется из [.filename]#bar/foo-contrib# и использует Git-коммит `fa579bc`. Файлы дистрибутива называются [.filename]#foo-foo-1.0.2_GH0.tar.gz#, [.filename]#bar-foo-icons-1.0_GH0.tar.gz# и [.filename]#bar-foo-contrib-fa579bc_GH0.tar.gz#. + +Все файлы дистрибутива извлекаются в `${WRKDIR}` в соответствующих подкаталогах. Основной файл по-прежнему извлекается в `${WRKSRC}`, в данном случае, [.filename]#${WRKDIR}/foo-1.0.2#. Каждый дополнительный файл дистрибутива извлекается в `${WRKSRC_group}`. Здесь, для группы `icons`, он называется `${WRKSRC_icons}` и содержит [.filename]#${WRKDIR}/foo-icons-1.0#. Файл с группой `contrib` называется `${WRKSRC_contrib}` и содержит `${WRKDIR}/foo-contrib-fa579bc`. + +Система сборки программы ожидает найти иконки в подкаталоге [.filename]#ext/icons# в её исходниках, поэтому используется `GH_SUBDIR`. `GH_SUBDIR` гарантирует, что [.filename]#ext# существует, но [.filename]#ext/icons# ещё не существует. Затем он выполняет следующее: + +[.programlisting] +.... +post-extract: + @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons +.... + +==== + +[[makefile-master_sites-github-multi2]] +.Использование `USE_GITHUB` с несколькими файлами дистрибутива с помощью `GH_TUPLE` +[example] +==== + +Это функционально эквивалентно crossref:makefiles[makefile-master_sites-github-multi,Использованию `USE_GITHUB` с несколькими файлами дистрибутива], но с использованием `GH_TUPLE`: + +[.programlisting] +.... +PORTNAME= foo +DISTVERSION= 1.0.2 + +USE_GITHUB= yes +GH_TUPLE= bar:foo-icons:1.0:icons/ext/icons \ + bar:foo-contrib:fa579bc:contrib + +CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} +.... + +В предыдущем примере использовалась группировка с `bar:icons,contrib`. В `GH_TUPLE` присутствует избыточная информация, так как группировка невозможна. +==== + +[[makefile-master_sites-github-submodules]] +.Как использовать `USE_GITHUB` с подмодулями Git? +[example] +==== +Порты, использующие GitHub в качестве вышестоящего репозитория, иногда применяют подмодули. Подробнее см. man:git-submodule[1]. + +Проблема с подмодулями заключается в том, что каждый из них является отдельным репозиторием. Таким образом, каждый из них должен быть загружен отдельно. + +В качестве примера используем пакет package:finance/moneymanagerex[], его репозиторий на GitHub находится по адресу https://github.com/moneymanagerex/moneymanagerex/[]. В корне репозитория есть файл https://github.com/moneymanagerex/moneymanagerex/blob/master/.gitmodules[.gitmodules]. Этот файл описывает все подмодули, используемые в данном репозитории, и перечисляет дополнительные необходимые репозитории. Этот файл покажет, какие дополнительные репозитории требуются: + +[.programlisting] +.... +[submodule "lib/wxsqlite3"] + path = lib/wxsqlite3 + url = https://github.com/utelle/wxsqlite3.git +[submodule "3rd/mongoose"] + path = 3rd/mongoose + url = https://github.com/cesanta/mongoose.git +[submodule "3rd/LuaGlue"] + path = 3rd/LuaGlue + url = https://github.com/moneymanagerex/LuaGlue.git +[submodule "3rd/cgitemplate"] + path = 3rd/cgitemplate + url = https://github.com/moneymanagerex/html-template.git +[...] +.... + +Единственная информация, отсутствующая в этом файле, — это хэш коммита или тег, который следует использовать в качестве версии. Эта информация находится после клонирования репозитория: + +[source, shell] +.... +% git clone --recurse-submodules https://github.com/moneymanagerex/moneymanagerex.git +Cloning into 'moneymanagerex'... +remote: Counting objects: 32387, done. +[...] +Submodule '3rd/LuaGlue' (https://github.com/moneymanagerex/LuaGlue.git) registered for path '3rd/LuaGlue' +Submodule '3rd/cgitemplate' (https://github.com/moneymanagerex/html-template.git) registered for path '3rd/cgitemplate' +Submodule '3rd/mongoose' (https://github.com/cesanta/mongoose.git) registered for path '3rd/mongoose' +Submodule 'lib/wxsqlite3' (https://github.com/utelle/wxsqlite3.git) registered for path 'lib/wxsqlite3' +[...] +Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/LuaGlue'... +Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/cgitemplate'... +Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/mongoose'... +Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/lib/wxsqlite3'... +[...] +Submodule path '3rd/LuaGlue': checked out 'c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b' +Submodule path '3rd/cgitemplate': checked out 'cd434eeeb35904ebcd3d718ba29c281a649b192c' +Submodule path '3rd/mongoose': checked out '2140e5992ab9a3a9a34ce9a281abf57f00f95cda' +Submodule path 'lib/wxsqlite3': checked out 'fb66eb230d8aed21dec273b38c7c054dcb7d6b51' +[...] +% cd moneymanagerex +% git submodule status + c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b 3rd/LuaGlue (heads/master) + cd434eeeb35904ebcd3d718ba29c281a649b192c 3rd/cgitemplate (cd434ee) + 2140e5992ab9a3a9a34ce9a281abf57f00f95cda 3rd/mongoose (6.2-138-g2140e59) + fb66eb230d8aed21dec273b38c7c054dcb7d6b51 lib/wxsqlite3 (v3.4.0) +[...] +.... + +Это также можно найти на GitHub. Каждый подкаталог, который является подмодулем, отображается как `_директория @ хэш_`, например, `mongoose @ 2140e59`. + +[NOTE] +**** +Хотя получение информации из GitHub кажется более простым, данные, полученные с помощью `git submodule status`, будут более информативными. Например, здесь хеш коммита ``lib/wxsqlite3`` `fb66eb2` соответствует `v3.4.0`. Оба варианта можно использовать взаимозаменяемо, но если доступен тег, предпочтительнее использовать его. +**** + +Теперь, когда вся необходимая информация собрана, можно написать [.filename]#Makefile# (показаны только строки, связанные с GitHub): + +[.programlisting] +.... +PORTNAME= moneymanagerex +DISTVERSIONPREFIX= v +DISTVERSION= 1.3.0 + +USE_GITHUB= yes +GH_TUPLE= utelle:wxsqlite3:v3.4.0:wxsqlite3/lib/wxsqlite3 \ + moneymanagerex:LuaGlue:c51d11a:lua_glue/3rd/LuaGlue \ + moneymanagerex:html-template:cd434ee:html_template/3rd/cgitemplate \ + cesanta:mongoose:2140e59:mongoose/3rd/mongoose \ + [...] +.... + +==== + +[[makefile-master_sites-gitlab]] +=== `USE_GITLAB` + +Подобно GitHub, если файл дистрибутива поставляется с https://gitlab.com/[gitlab.com] или использует программное обеспечение GitLab, эти переменные доступны для использования и могут потребовать установки. + +[[makefile-master_sites-gitlab-description]] +.Описание `USE_GITLAB` +[cols="1,1,1", options="header"] +|=== +| Переменная +| Описание +| По умолчанию + +|`GL_SITE` +|Название сайта, на котором размещен проект GitLab +|https://gitlab.com/ + +|`GL_ACCOUNT` +|Имя учётной записи пользователя GitLab, размещающего проект +|`${PORTNAME}` + +|`GL_PROJECT` +|Название проекта на GitLab +|`${PORTNAME}` + +|`GL_COMMIT` +|Хэш коммита для загрузки. Должен быть полным 160-битным, 40-символьным шестнадцатеричным хэшем sha1. Это обязательная переменная для GitLab. +|`(нет)` + +|`GL_SUBDIR` +|Когда программному обеспечению требуется дополнительный файл дистрибутива для извлечения в +`${WRKSRC}`, можно использовать эту переменную. Примеры можно найти в + crossref:makefiles[makefile-master_sites-gitlab-multiple, Загрузка нескольких файлов из GitLab] для получения дополнительной информации. +|(отсутствует) + +|`GL_TUPLE` +|`GL_TUPLE` позволяет объединить `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT`, `GL_COMMIT` и `GL_SUBDIR` в одну переменную. Формат записи: _сайт_`:`_учётная запись_`:`_проект_`:`_коммит_`:`_группа_`/`_поддиректория_. Части _сайт_`:` и `/`_поддиректория_ являются необязательными. Это полезно, когда требуется загрузить данные из нескольких проектов GitLab. +| |=== +[[makefile-master_sites-gitlab-ex1]] +.Простое использование `USE_GITLAB` +[example] +==== +Пытаясь создать порт для версии `1.14` библиотеки libsignon-glib от пользователя accounts-sso на gitlab.com, по адресу https://gitlab.com/accounts-sso/libsignon-glib/[], файл [.filename]#Makefile# будет выглядеть следующим образом для загрузки дистрибутивных файлов: + +[.programlisting] +.... +PORTNAME= libsignon-glib +DISTVERSION= 1.14 + +USE_GITLAB= yes +GL_ACCOUNT= accounts-sso +GL_COMMIT= e90302e342bfd27bc8c9132ab9d0ea3d8723fd03 +.... + +Он автоматически получит `MASTER_SITES`, установленный на https://gitlab.com/[gitlab.com], и `WRKSRC` на `${WRKDIR}/libsignon-glib-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03`. +==== + +[[makefile-master_sites-gitlab-ex2]] +.Более полное использование `USE_GITLAB` +[example] +==== + +Более полный пример использования вышеописанного, если порт не имеет версионирования и foobar принадлежит пользователю foo в проекте bar на самостоятельно размещенном сайте GitLab `https://gitlab.example.com/`, тогда [.filename]#Makefile# будет выглядеть следующим образом для загрузки дистрибутивных файлов: + +[.programlisting] +.... +PORTNAME= foobar +DISTVERSION= g20170906 + +USE_GITLAB= yes +GL_SITE= https://gitlab.example.com +GL_ACCOUNT= foo +GL_PROJECT= bar +GL_COMMIT= 9c1669ce60c3f4f5eb43df874d7314483fb3f8a6 +.... + +В нем будет установлено `MASTER_SITES` в `"https://gitlab.example.com"` и `WRKSRC` в `${WRKDIR}/bar-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6`. + +[TIP] +====== +`20170906` — это дата коммита, указанного в `GL_COMMIT`, а не дата редактирования файла [.filename]#Makefile# или дата коммита в дерево портов FreeBSD. +====== + +[NOTE] +====== +Протокол, порт и корневая директория веб-сервера ``GL_SITE`` могут быть изменены в той же переменной. +====== + +==== + +[[makefile-master_sites-gitlab-multiple]] +==== Извлечение нескольких файлов из GitLab + +Фреймворк `USE_GITLAB` также поддерживает загрузку нескольких файлов дистрибутивов из различных мест GitLab и сайтов, размещённых на GitLab. Он работает очень похоже на crossref:makefiles[porting-master-sites-n, Несколько файлов дистрибутивов или патчей из разных местоположений] и crossref:makefiles[makefile-master_sites-gitlab-multiple, Загрузка нескольких файлов из GitLab]. + +В `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT` и `GL_COMMIT` добавляются множественные значения. Каждое уникальное значение назначается группе. crossref:makefiles[makefile-master_sites-gitlab-description,Описание `USE_GITLAB`]. + +`GL_TUPLE` также может использоваться, когда имеется множество файлов дистрибутива. Это помогает хранить информацию о сайте, учётной записи, проекте, коммите и группе в одном месте. + +Для каждой группы создаётся вспомогательная переменная `${WRKSRC_group}`, содержащая каталог, в который был извлечён файл. Переменные `${WRKSRC_group}` могут использоваться для перемещения каталогов во время `post-extract`, добавления в `CONFIGURE_ARGS` или любых других действий, необходимых для корректной сборки программного обеспечения. + +[CAUTION] +==== +Часть `:__group__` _должна_ использоваться _только для одного_ файла дистрибутива. Она служит уникальным ключом, и её повторное использование приведёт к перезаписи предыдущих значений. +==== + +[NOTE] +==== +Поскольку это всего лишь синтаксический сахар над `DISTFILES` и `MASTER_SITES`, имена групп должны соответствовать ограничениям на имена групп, описанным в crossref:makefiles[porting-master-sites-n, Файлы дистрибутивов или патчей из нескольких источников] +==== + +При получении нескольких файлов с использованием GitLab иногда файл дистрибутива по умолчанию не загружается с сайта GitLab. Чтобы отключить загрузку файла дистрибутива по умолчанию, установите: + +[.programlisting] +.... +USE_GITLAB= nodefault +.... + +[IMPORTANT] +==== +При использовании `USE_GITLAB=nodefault`, [.filename]#Makefile# должен устанавливать `DISTFILES` в своем crossref:makefiles[porting-order-portname,верхнем блоке]. Определение должно быть следующим: + +[.programlisting] +.... +DISTFILES= ${DISTNAME}${EXTRACT_SUFX} +.... + +==== + +[[makefile-master_sites-gitlab-multi]] +.Использование `USE_GITLAB` с несколькими файлами дистрибутива +[example] +==== +Время от времени возникает необходимость загрузить более одного файла дистрибутива. Например, когда вышестоящий git-репозиторий использует подмодули. Это можно легко сделать с помощью групп в переменных `GL_*`: + +[.programlisting] +.... +PORTNAME= foo +DISTVERSION= 1.0.2 + +USE_GITLAB= yes +GL_SITE= https://gitlab.example.com:9434/gitlab:icons +GL_ACCOUNT= bar:icons,contrib +GL_PROJECT= foo-icons:icons foo-contrib:contrib +GL_COMMIT= c189207a55da45305c884fe2b50e086fcad4724b ae7368cab1ca7ca754b38d49da064df87968ffe4:icons 9e4dd76ad9b38f33fdb417a4c01935958d5acd2a:contrib +GL_SUBDIR= ext/icons:icons + +CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} +.... + +Это загрузит два файла дистрибутива с gitlab.com и один с `gitlab.example.com`, где размещается GitLab. По умолчанию файл берется из [.filename]#https://gitlab.com/foo/foo#, а коммит — `c189207a55da45305c884fe2b50e086fcad4724b`. Второй файл, из группы `icons`, берется из [.filename]#https://gitlab.example.com:9434/gitlab/bar/foo-icons#, а коммит — `ae7368cab1ca7ca754b38d49da064df87968ffe4`. Третий файл берется из [.filename]#https://gitlab.com/bar/foo-contrib#, а коммит — `9e4dd76ad9b38f33fdb417a4c01935958d5acd2a`. Файлы дистрибутива называются [.filename]#foo-foo-c189207a55da45305c884fe2b50e086fcad4724b_GL0.tar.gz#, [.filename]#bar-foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4_GL0.tar.gz# и [.filename]#bar-foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a_GL0.tar.gz#. + +Все файлы дистрибутива извлекаются в `${WRKDIR}` в соответствующих подкаталогах. Основной файл по-прежнему извлекается в `${WRKSRC}`, в данном случае это [.filename]#${WRKDIR}/foo-c189207a55da45305c884fe2b50e086fcad4724b-c189207a55da45305c884fe2b50e086fcad4724b#. Каждый дополнительный файл дистрибутива извлекается в `${WRKSRC_group}`. Здесь для группы `icons` он называется `${WRKSRC_icons}` и содержит [.filename]#${WRKDIR}/foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4-ae7368cab1ca7ca754b38d49da064df87968ffe4#. Файл группы `contrib` называется `${WRKSRC_contrib}` и содержит `${WRKDIR}/foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a`. + +Система сборки программного обеспечения ожидает найти иконки в подкаталоге [.filename]#ext/icons# в своих исходниках, поэтому используется `GL_SUBDIR`. `GL_SUBDIR` гарантирует, что [.filename]#ext# существует, но [.filename]#ext/icons# ещё не существует. Затем она выполняет следующее: + +[.programlisting] +.... +post-extract: + @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons +.... + +==== + +[[makefile-master_sites-gitlab-multi2]] +.Использование `USE_GITLAB` с несколькими файлами дистрибуции с помощью `GL_TUPLE` +[example] +==== +Это функционально эквивалентно crossref:makefiles[makefile-master_sites-gitlab-multi,Использование `USE_GITLAB` с несколькими файлами дистрибуции], но с использованием `GL_TUPLE`: + +[.programlisting] +.... +PORTNAME= foo +DISTVERSION= 1.0.2 + +USE_GITLAB= yes +GL_COMMIT= c189207a55da45305c884fe2b50e086fcad4724b +GL_TUPLE= https://gitlab.example.com:9434/gitlab:bar:foo-icons:ae7368cab1ca7ca754b38d49da064df87968ffe4:icons/ext/icons \ + bar:foo-contrib:9e4dd76ad9b38f33fdb417a4c01935958d5acd2a:contrib + +CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} +.... + +В предыдущем примере использовалась группировка с `bar:icons,contrib`. Некоторую избыточную информацию приходится указывать с `GL_TUPLE`, так как группировка невозможна. +==== + +[[makefile-extract_sufx]] === `EXTRACT_SUFX` -Если у вас имеется один дистрибутивный файл, и в его имени используется странное окончание для указания типа сжатия, задайте переменную `EXTRACT_SUFX`. +Если имеется один файл дистрибутива, и он использует нестандартное суффикс для указания механизма сжатия, установите `EXTRACT_SUFX`. -К примеру, если дистрибутивный файл носит имя [.filename]#foo.tgz#, а не более привычное [.filename]#foo.tar.gz#, вы должны написать: +Например, если файл дистрибутива был назван [.filename]#foo.tar.gzip# вместо более привычного [.filename]#foo.tar.gz#, напишите: [.programlisting] .... DISTNAME= foo -EXTRACT_SUFX= .tgz +EXTRACT_SUFX= .tar.gzip .... -Переменные `USE_BZIP2`, `USE_XZ` и `USE_ZIP` при необходимости автоматически устанавливают значение `EXTRACT_SUFX` в `.tar.bz2`, `.tar.xz` или `.zip`. Если ни одна из этих переменных не задана, то значение `EXTRACT_SUFX` по умолчанию устанавливается в `.tar.gz`. +`USES=tar[:__xxx__]`, `USES=lha` или `USES=zip` автоматически устанавливают `EXTRACT_SUFX` в наиболее распространённые расширения архивов при необходимости, подробнее см. crossref:uses[uses,Использование макросов `USES`]. Если ни один из них не задан, `EXTRACT_SUFX` по умолчанию принимает значение `.tar.gz`. [NOTE] ==== -Вам не нужно задавать значения `EXTRACT_SUFX` и `DISTFILES` одновременно. +Как `EXTRACT_SUFX` используется только в `DISTFILES`, следует задавать только один из них. ==== +[[makefile-distfiles-definition]] === `DISTFILES` -Иногда имена сгружаемых файлов не соответствуют имени порта. К примеру, файл может называться [.filename]#source.tar.gz# или подобным образом. В других случаях исходный код приложения может располагаться в нескольких отличающихся архивах, и все они должны быть сгружены. +Иногда названия файлов для загрузки не имеют ничего общего с именем порта. Например, файл может называться [.filename]#source.tar.gz# или подобным образом. В других случаях исходный код приложения может быть разбит на несколько различных архивов, все из которых необходимо загрузить. -Если это ваш случай, то задайте в переменной `DISTFILES` список разделённых пробелами имён файлов, которые нужно сгрузить. +Если это так, установите `DISTFILES` как список разделённых пробелами файлов, которые необходимо загрузить. [.programlisting] .... DISTFILES= source1.tar.gz source2.tar.gz .... -Если переменная `DISTFILES` не задана явно, то её значением по умолчанию будет `${DISTNAME}${EXTRACT_SUFX}`. +Если явно не задано, `DISTFILES` по умолчанию равно `${DISTNAME}${EXTRACT_SUFX}`. +[[makefile-extract_only]] === `EXTRACT_ONLY` -Если только некоторые из `DISTFILES` должны быть распакованы-к примеру, часть из них является исходным кодом, а другие представляют собой неупакованную документацию-перечислите имена файлов, которые должны быть распакованы, в `EXTRACT_ONLY`. +Если необходимо извлечь только некоторые из `DISTFILES` — например, один из них является исходным кодом, а другой — несжатым документом — укажите имена файлов, которые нужно извлечь, в `EXTRACT_ONLY`. [.programlisting] .... @@ -901,7 +1946,7 @@ DISTFILES= source.tar.gz manual.html EXTRACT_ONLY= source.tar.gz .... -Если _ни один_ из `DISTFILES` не должен распаковываться, то установите пустое значение переменной `EXTRACT_ONLY`. +Если ни один из `DISTFILES` не требует распаковки, установите `EXTRACT_ONLY` в пустую строку. [.programlisting] .... @@ -911,77 +1956,103 @@ EXTRACT_ONLY= [[porting-patchfiles]] === `PATCHFILES` -Если вашему порту требуются некоторых дополнительные патчи, которые доступны по FTP или HTTP, задайте имена этих файлов в переменной `PATCHFILES`, а в переменной `PATCH_SITES` укажите URL того каталога, в котором они содержатся (формат такой же, как для `MASTER_SITES`). +Если порт требует дополнительных исправлений, доступных через FTP или HTTP, установите `PATCHFILES` в имена файлов, а `PATCH_SITES` — в URL каталога, содержащего их (формат такой же, как у `MASTER_SITES`). + +Если патч не относится к корню исходного дерева (то есть к `WRKSRC`), потому что содержит дополнительные пути, установите `PATCH_DIST_STRIP` соответствующим образом. Например, если все пути в патче имеют дополнительный префикс `foozolix-1.0/` перед именами файлов, задайте `PATCH_DIST_STRIP=-p1`. + +Не беспокойтесь, если патчи сжаты; они будут автоматически распакованы, если их имена заканчиваются на [.filename]#.Z#, [.filename]#.gz#, [.filename]#.bz2# или [.filename]#.xz#. + +Если патч распространяется вместе с другими файлами, такими как документация, в сжатом tarball, использование `PATCHFILES` невозможно. В таком случае добавьте имя и расположение tarball с патчами в `DISTFILES` и `MASTER_SITES`. Затем используйте `EXTRA_PATCHES`, чтобы указать на эти файлы, и [.filename]#bsd.port.mk# автоматически применит их. В частности, _не_ копируйте файлы патчей в [.filename]#${PATCHDIR}#. Этот каталог может быть недоступен для записи. + +[TIP] +==== +Если есть несколько патчей и для них требуются разные значения параметра strip, его можно добавить рядом с именем патча в `PATCHFILES`, например: + +[.programlisting] +.... +PATCHFILES= patch1 patch2:-p1 +.... -Если патч не относится к самому верху дерева исходных текстов (то есть `WRKSRC`), потому что он содержит некоторые дополнительные пути, установите соответственно значение переменной `PATCH_DIST_STRIP`. В частности, если все имена путей в патче имеют дополнительный путь `foozolix-1.0/` перед именем файла, то задайте `PATCH_DIST_STRIP=-p1`. +Это не конфликтует с crossref:makefiles[porting-master-sites-n,функцией группировки мастер-сайтов], добавление группы также работает: -Не волнуйтесь, если патчи упакованы; они будут распакованы автоматически, если имена файлов оканчиваются на [.filename]#.gz# или [.filename]#.Z#. +[.programlisting] +.... +PATCHFILES= patch2:-p1:source2 +.... -Если патч распространяется вместе с какими-то другими файлами, такими, как документация, в виде tar-архива `gzip`, вы не можете просто использовать `PATCHFILES`. Если это ваш случай, добавьте имя и местоположение архива с патчем к `DISTFILES` и `MASTER_SITES`. Затем воспользуйтесь переменной `EXTRA_PATCHES` для указания этих файлов, и [.filename]#bsd.port.mk# автоматически применит эти патчи. В частности, _не копируйте_ файлы с патчами в каталог `PATCHDIR`-этот каталог может быть недоступным для записи. +==== [NOTE] ==== -Архив будет распакован вне исходного кода, как обычно, и к тому же его не нужно явно распаковывать, если это обычный архив `gzip` или `compress`. Если вы сделаете последнее, приложите дополнительные усилия для того, чтобы не перезаписать что-либо, уже существующее в этом каталоге. Также не забудьте добавить команду для удаления скопированного патча в цели `pre-clean`. +Tarball уже будет распакован вместе с обычными исходными кодами, поэтому нет необходимости явно его распаковывать, если это обычный сжатый tarball. Будьте особенно осторожны, чтобы не перезаписать существующие файлы в этом каталоге при ручной распаковке. Также не забудьте добавить команду для удаления скопированного патча в цель `pre-clean`. ==== [[porting-master-sites-n]] -=== Несколько дистрибутивных файлов или патчей с различных серверов и подкаталогов (`MASTER_SITES:n`) +=== Несколько файлов дистрибутивов или исправлений из нескольких местоположений -(Этот раздел можно считать немного "повышенной трудности"; те, кто впервые знакомятся с этим текстом, могут пропустить этот раздел). +(Считайте, что это несколько «продвинутая тема»; тем, кто впервые читает этот документ, возможно, стоит сначала пропустить этот раздел). -В этом разделе находится информация о механизме сгрузки, известном как `MASTER_SITES:n` и `MASTER_SITES_NN`. Далее мы будем называть этот механизм `MASTER_SITES:n`. +Этот раздел содержит информацию о механизме загрузки, известном как `MASTER_SITES:n` и `MASTER_SITES_NN`. Мы будем называть этот механизм `MASTER_SITES:n`. -Сначала немного общей информации. В OpenBSD имеется полезная возможность, используемая в переменных `DISTFILES` и `PATCHFILES`, которая позволяет закреплять после имен файлов и патчей идентификаторы типа `:n`. Здесь `n` может быть из диапазона `[0-9]` и обозначать закреплённую группу. К примеру: +Небольшая предыстория. В OpenBSD есть удобная функция внутри `DISTFILES` и `PATCHFILES`, которая позволяет добавлять постфикс `:n` к файлам и патчам. Здесь `n` может быть любым словом, содержащим `[0-9a-zA-Z_]`, и обозначать группу. Например: [.programlisting] .... DISTFILES= alpha:0 beta:1 .... -В OpenBSD дистрибутивный файл [.filename]#alpha# будет связан с переменной `MASTER_SITES0`, но не с нашей общей переменной `MASTER_SITES`, а файл [.filename]#beta# с переменной `MASTER_SITES1`. +В OpenBSD файл дистрибутива [.filename]#alpha# будет связан с переменной `MASTER_SITES0`, а не с нашей общей `MASTER_SITES`, а [.filename]#beta# — с `MASTER_SITES1`. + +Это очень интересная функция, которая может сократить бесконечные поиски нужного сайта для загрузки. -Этот очень интересная возможность, которая может уменьшить этот бесконечный поиск работающего сайта для сгрузки. +Представьте 2 файла в `DISTFILES` и 20 сайтов в `MASTER_SITES`, причём сайты медленные как черепаха, где [.filename]#beta# есть на всех сайтах из `MASTER_SITES`, а [.filename]#alpha# можно найти только на 20-м сайте. Было бы так обидно проверять их все, если бы сопровождающий знал это заранее, не так ли? Не самое лучшее начало для чудесных выходных! -Просто представьте себе 2 файла в `DISTFILES` и 20 сайтов в `MASTER_SITES`; сайты очень медленные, причём [.filename]#beta# находится на всех сайтах из `MASTER_SITES`, а [.filename]#alpha# может быть найден только на 20-м сайте. Будет неправильно проверять их все, если создатель знает об этом, не правда ли? Неподходящее начало для таких прекрасных выходных! +Теперь, когда вы поняли идею, представьте больше `DISTFILES` и больше `MASTER_SITES`. Безусловно, наш "мастер по исследованию distfiles" оценил бы снижение нагрузки на сеть, которое это принесло бы. -Теперь, когда вы получили общее представление, просто представьте ещё большее количество `DISTFILES` и `MASTER_SITES`. Конечно, наш "магистр доступности дистрибутивов" представляет масштабы нагрузки на сеть, которую это даёт. +В следующих разделах будет приведена информация о реализации этой идеи в FreeBSD. Мы немного улучшили концепцию OpenBSD. -В последующих разделах информация будет даваться вместе с реализацией этой идеи во FreeBSD. Мы несколько улучшили концепцию OpenBSD. +[IMPORTANT] +==== +Имена групп не могут содержать дефисы (`-`), более того, они не могут содержать любые символы вне диапазона `[a-zA-Z0-9_]`. Это связано с тем, что, хотя man:make[1] допускает использование имён переменных с дефисами, man:sh[1] — нет. +==== -==== Упрощённая информация +[[porting-master-sites-n-simplified]] +==== Упрощенная информация -В этом разделе рассказывается, как быстро подготовить точную сгрузку нескольких дистрибутивных файлов и патчей с разных сайтов и каталогов. Мы описываем здесь случай упрощённого использования `MASTER_SITES:n`. Для большинства сценариев этого будет достаточно. Однако, если вам нужна дополнительная информация, обратитесь к следующему разделу. +В этом разделе объясняется, как быстро настроить детализированное получение нескольких файлов дистрибутивов и патчей с разных сайтов и подкаталогов. Здесь описывается случай упрощённого использования `MASTER_SITES:n`. Этого будет достаточно для большинства сценариев. Более подробная информация доступна в crossref:makefiles[ports-master-sites-n-detailed, Подробная Информация]. -Некоторые приложения состоят из многих дистрибутивных файлов, которые должны быть сгружены с нескольких различных сайтов. К примеру, Ghostscript состоит из основной программы и большого числа файлов драйверов, которые используются в зависимости от принтера пользователя. Некоторые из этих файлов драйверов поставляются с основной программой, но при этом многие другие должны быть сгружены с множества различных сайтов. +Некоторые приложения состоят из нескольких распространяемых файлов, которые необходимо загрузить с различных сайтов. Например, Ghostscript включает основную часть программы и множество драйверов, используемых в зависимости от принтера пользователя. Некоторые из этих драйверов поставляются вместе с основной частью, но многие другие необходимо загружать с различных сайтов. -Чтобы это поддерживать, за каждой записью в `DISTFILES` может следовать символ двоеточия и "имя метки". За каждым сайтом, перечисленным в `MASTER_SITES`, тоже следует двоеточие и метка, которая указывает, какие файлы дистрибутива должны быть сгружены с этого сайта. +Для поддержки этого, каждая запись в `DISTFILES` может сопровождаться двоеточием и "именем группы". Затем каждый сайт, указанный в `MASTER_SITES`, сопровождается двоеточием и группой, которая указывает, какие файлы дистрибутива загружаются с данного сайта. -Например, рассмотрим приложение, исходный код которого разделён на две части, [.filename]#source1.tar.gz# и [.filename]#source2.tar.gz#, которые должны быть сгружены с двух различных источников. Файл [.filename]#Makefile# порта будет содержать строчки типа <<ports-master-sites-n-example-simple-use-one-file-per-site>>. +Например, рассмотрим приложение, исходный код которого разделён на две части: [.filename]#source1.tar.gz# и [.filename]#source2.tar.gz#, которые необходимо загрузить с двух разных сайтов. В [.filename]#Makefile# порта будут присутствовать строки, подобные crossref:makefiles[ports-master-sites-n-example-simple-use-one-file-per-site,Упрощённое использование `MASTER_SITES:n` с одним файлом на сайт]. [[ports-master-sites-n-example-simple-use-one-file-per-site]] -.Упрощённое использование `MASTER_SITES:n` с 1 файлом на каждом сайте +.Упрощённое использование `MASTER_SITES:n` с одним файлом на сайт [example] ==== + [.programlisting] .... -MASTER_SITES= ftp://ftp.example1.com/:source1 \ - ftp://ftp.example2.com/:source2 +MASTER_SITES= ftp://ftp1.example.com/:source1 \ + http://www.example.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 .... ==== -Несколько дистрибутивных файлов могут иметь одну и ту же метку. Продолжая предыдущий пример, положим, что имеется и третий дистрибутивный файл, [.filename]#source3.tar.gz#, который должен быть сгружен с `ftp.example2.com`. Тогда файл [.filename]#Makefile# будет написан как <<ports-master-sites-n-example-simple-use-more-than-one-file-per-site>>. +Несколько файлов дистрибутивов могут принадлежать одной группе. Продолжая предыдущий пример, предположим, что существует третий файл дистрибутива [.filename]#source3.tar.gz#, который загружается с `ftp.example2.com`. Тогда [.filename]#Makefile# будет записан, как показано в crossref:makefiles[ports-master-sites-n-example-simple-use-more-than-one-file-per-site,Упрощённое использование `MASTER_SITES:n` с несколькими файлами на один сайт]. [[ports-master-sites-n-example-simple-use-more-than-one-file-per-site]] -.Упрощённое использование `MASTER_SITES:n` с более чем 1 файлом на каждом сервере +.Упрощённое использование `MASTER_SITES:n` с несколькими файлами на одном сайте [example] ==== + [.programlisting] .... -MASTER_SITES= ftp://ftp.example1.com/:source1 \ - ftp://ftp.example2.com/:source2 +MASTER_SITES= ftp://ftp.example.com/:source1 \ + http://www.example.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 \ source3.tar.gz:source2 @@ -989,86 +2060,88 @@ DISTFILES= source1.tar.gz:source1 \ ==== +[[ports-master-sites-n-detailed]] ==== Подробная информация -Прекрасно, но пример из предыдущего раздела не показал вам всё, что вам нужно? В этом разделе мы подробно опишем, как работает механизм `MASTER_SITES:n` точной сгрузки и как вы можете изменить ваши порты, чтобы это использовать. +Хорошо, значит, предыдущий пример не отражал потребности нового порта? В этом разделе мы подробно объясним, как работает механизм детализированного получения `MASTER_SITES:n` и как его можно использовать. -. За элементами могут следовать символы `:n`, где _n_ это `[^:,]+`, то есть _n_ может теоретически быть любой алфавитно-цифровой строкой, но пока мы будем ограничивать их `[a-zA-Z_][0-9a-zA-Z_]+`. -+ -Более того, совпадение строк чувствительно к регистру; другими словами, `n` отличается от `N`. -+ -Однако следующие слова не могут использоваться для этих нужд, так как они имеют особое значение: `default`, `all` и `ALL` (они используются для своих нужд в <<porting-master-sites-n-what-changes-in-port-targets,ii>>). Кроме того, `DEFAULT` является специальным ключевым словом (посмотрите <<porting-master-sites-n-DEFAULT-group,3>>). -. Элементы, за которыми следуют `:n`, принадлежат группе `n`, `:m` относится к группе `m` и так далее. +. Элементы могут иметь постфикс `:__n__`, где _n_ — это `[^:,]+`, то есть _n_ концептуально может быть любой буквенно-цифровой строкой, но пока мы ограничим её `[a-zA-Z_][0-9a-zA-Z_]+`. ++ +Более того, сравнение строк чувствительно к регистру; то есть, `n` отличается от `N`. ++ +Однако эти слова не могут использоваться для постфиксных целей, так как имеют специальное значение: `default`, `all` и `ALL` (они используются внутри системы, см. crossref:makefiles[porting-master-sites-n-what-changes-in-port-targets, ii]). Кроме того, `DEFAULT` является словом специального назначения (проверьте пункт crossref:makefiles[porting-master-sites-n-DEFAULT-group,3]). +. Элементы с постфиксом `:n` принадлежат группе `n`, `:m` — группе `m` и так далее. ++ [[porting-master-sites-n-DEFAULT-group]] -. Элементы без таких суффиксов не относятся ни к какой группе, то есть они принадлежат к особой группе `DEFAULT`. Если вы укажете суффиксом любого элемента `DEFAULT`, вы просто выполните излишнюю работу, если только вы не хотите отнесения элемента как к группе `DEFAULT`, так и какой-то другой в одно и то же время (посмотрите на пункт <<porting-master-sites-n-comma-operator,5>>). -+ -Следующие примеры равнозначны, но первый более предпочтителен: +. Элементы без постфикса не принадлежат к группам, все они относятся к специальной группе `DEFAULT`. Элементы с постфиксом `DEFAULT` избыточны, за исключением случаев, когда элемент одновременно принадлежит и к `DEFAULT`, и к другим группам (см. пункт crossref:makefiles[porting-master-sites-n-comma-operator,5]). ++ +Эти примеры эквивалентны, но первый предпочтительнее: + [.programlisting] .... MASTER_SITES= alpha .... - + [.programlisting] .... MASTER_SITES= alpha:DEFAULT .... -. Группы не являются эксклюзивными, элемент может принадлежать к нескольким отличающимся группам одновременно, а группа может либо иметь несколько различных элементов, либо не иметь их вовсе. Повторяющиеся элементы в одной и той же группе будут являться просто повторяющимися элементами. +. Группы не являются исключительными, элемент может принадлежать нескольким разным группам одновременно, а группа может содержать несколько разных элементов или не содержать их вовсе. ++ [[porting-master-sites-n-comma-operator]] -. Если в хотите, чтобы элемент принадлежал к нескольким группам одновременно, вы можете использовать запятую (`,`). -+ -Вместо того, чтобы повторять их несколько раз, каждый раз с разным постфиксом, мы можем перечислить несколько групп за раз в одном постфиксе. Например, `:m,n,o` определяет элемент, принадлежащий группам `m`, `n` и `o`. -+ -Все следующие примеры имеют один смысл, но последний является предпочтительным: +. Когда элемент принадлежит нескольким группам одновременно, используйте оператор запятую (`,`). ++ +Вместо повторения несколько раз, каждый раз с разным постфиксом, мы можем перечислить несколько групп сразу в одном постфиксе. Например, `:m,n,o` обозначает элемент, принадлежащий группам `m`, `n` и `o`. ++ +Все эти примеры эквивалентны, но последний является предпочтительным: + [.programlisting] .... MASTER_SITES= alpha alpha:SOME_SITE .... - + [.programlisting] .... MASTER_SITES= alpha:DEFAULT alpha:SOME_SITE .... - + [.programlisting] .... MASTER_SITES= alpha:SOME_SITE,DEFAULT .... - + [.programlisting] .... MASTER_SITES= alpha:DEFAULT,SOME_SITE .... -. Все серверы внутри определённой группы сортируются в соответствии с `MASTER_SORT_AWK`. Все группы в `MASTER_SITES` и `PATCH_SITES` тоже сортируются. +. Все сайты в заданной группе сортируются согласно `MASTER_SORT_AWK`. Все группы в `MASTER_SITES` и `PATCH_SITES` также сортируются. ++ [[porting-master-sites-n-group-semantics]] -. Семантика групп может использоваться в любой из следующих переменных `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR`, `PATCH_SITE_SUBDIR`, `DISTFILES` и `PATCHFILES` в соответствии со следующим синтаксисом: -.. Все элементы `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR` и `PATCH_SITE_SUBDIR` должны заканчиваться символом прямого слэша `/`. Если какие-то элементы принадлежат каким-то группам, постфикс группы `:n` должен следовать сразу после завершающего символа `/`. Механизм `MASTER_SITES:n` опирается на наличие завершающего символа `/` во избежание совпадающих элементов, где `:n` является корректной частью элемента с вхождениями, где `:n` обозначает группу `n`. Для целей совместимости, так как завершающий символ `/` ранее не требовался в элементах `MASTER_SITE_SUBDIR` и `PATCH_SITE_SUBDIR`, если символ, сразу предшествующий постфиксу, не является символом `/`, то `:n` будет считаться корректной частью элемента, а не постфиксом группы, даже если за элементом следует `:n`. Посмотрите <<ports-master-sites-n-example-detailed-use-master-site-subdir>> и <<ports-master-sites-n-example-detailed-use-complete-example-master-sites>>. +. Семантика групп может использоваться в любых переменных `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR`, `PATCH_SITE_SUBDIR`, `DISTFILES` и `PATCHFILES` согласно следующему синтаксису: +.. Все элементы `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR` и `PATCH_SITE_SUBDIR` должны заканчиваться символом дробной черты `/`. Если элементы принадлежат к какой-либо группе, постфикс группы `:__n__` должен следовать сразу после завершающего символа `/`. Механизм `MASTER_SITES:n` полагается на наличие завершающего символа `/`, чтобы избежать путаницы между элементами, где `:n` является допустимой частью элемента, и случаями, где `:n` обозначает группу `n`. В целях совместимости, поскольку ранее завершающий символ `/` не требовался в элементах `MASTER_SITE_SUBDIR` и `PATCH_SITE_SUBDIR`, если символ, непосредственно предшествующий постфиксу, не является `/`, то `:n` будет считаться допустимой частью элемента, а не постфиксом группы, даже если элемент оканчивается на `:n`. См. оба раздела crossref:makefiles[ports-master-sites-n-example-detailed-use-master-site-subdir,Подробное использование `MASTER_SITES:n` в `MASTER_SITE_SUBDIR`] и crossref:makefiles[ports-master-sites-n-example-detailed-use-complete-example-master-sites,Подробное использование `MASTER_SITES:n` с оператором запятая, несколькими файлами, несколькими сайтами и несколькими подкаталогами]. + [[ports-master-sites-n-example-detailed-use-master-site-subdir]] .Подробное использование `MASTER_SITES:n` в `MASTER_SITE_SUBDIR` [example] ==== + [.programlisting] .... MASTER_SITE_SUBDIR= old:n new/:NEW .... -*** Каталоги внутри группы `DEFAULT` -> old:n -*** Каталоги внутри группы `NEW` -> new +*** Каталоги в группе `DEFAULT` -> old:n +*** Каталоги в группе `NEW` -> new ==== + [[ports-master-sites-n-example-detailed-use-complete-example-master-sites]] -.Подробное использование `MASTER_SITES:n` с запятыми, несколькими файлами, несколькими серверами и несколькими подкаталогами +.Подробное использование `MASTER_SITES:n` с оператором запятая, несколькими файлами, сайтами и подкаталогами [example] ==== + [.programlisting] .... MASTER_SITES= http://site1/%SUBDIR%/ http://site2/:DEFAULT \ @@ -1081,13 +2154,13 @@ DISTFILES= file1 file2:DEFAULT file3:group3 \ file4:group4,group5,group6 file5:grouping \ file6:group7 MASTER_SITE_SUBDIR= directory-trial:1 directory-n/:groupn \ - directory-one/:group6,DEFAULT \ - directory + directory-one/:group6,DEFAULT \ + directory .... -Предыдущий пример приводит к следующей точной сгрузке. Серверы перечислены в точном порядке их использования. +Предыдущий пример приводит к такой детализированной загрузке файлов. Сайты перечислены в точном порядке их использования. -*** [.filename]#file1# будет сгружаться с +*** [.filename]#file1# будет загружен из **** `MASTER_SITE_OVERRIDE` **** http://site1/directory-trial:1/ @@ -1097,7 +2170,7 @@ MASTER_SITE_SUBDIR= directory-trial:1 directory-n/:groupn \ **** http://site7/ **** `MASTER_SITE_BACKUP` -*** [.filename]#file2# будет сгружаться точно также, как [.filename]#file1#, так как они оба относятся к одной и той же группе +*** [.filename]#file2# будет загружен точно так же, как [.filename]#file1#, поскольку они оба принадлежат к одной и той же группе **** `MASTER_SITE_OVERRIDE` **** http://site1/directory-trial:1/ @@ -1107,13 +2180,13 @@ MASTER_SITE_SUBDIR= directory-trial:1 directory-n/:groupn \ **** http://site7/ **** `MASTER_SITE_BACKUP` -*** [.filename]#file3# будет сгружен с +*** [.filename]#file3# будет загружен из **** `MASTER_SITE_OVERRIDE` **** http://site3/ **** `MASTER_SITE_BACKUP` -*** [.filename]#file4# будет сгружаться с +*** [.filename]#file4# будет загружен из **** `MASTER_SITE_OVERRIDE` **** http://site4/ @@ -1123,12 +2196,12 @@ MASTER_SITE_SUBDIR= directory-trial:1 directory-n/:groupn \ **** http://site8/directory-one/ **** `MASTER_SITE_BACKUP` -*** [.filename]#file5# будет сгружен с +*** [.filename]#file5# будет загружен из **** `MASTER_SITE_OVERRIDE` **** `MASTER_SITE_BACKUP` -*** [.filename]#file6# будет сгружаться с +*** [.filename]#file6# будет получен из **** `MASTER_SITE_OVERRIDE` **** http://site8/ @@ -1136,31 +2209,32 @@ MASTER_SITE_SUBDIR= directory-trial:1 directory-n/:groupn \ ==== -. Как мне группировать одну из специальных переменных из [.filename]#bsd.sites.mk#, например, `MASTER_SITE_SOURCEFORGE`? -+ -Посмотрите <<ports-master-sites-n-example-detailed-use-master-site-sourceforge>>. +. Как сгруппировать один из специальных макросов из [.filename]#bsd.sites.mk#, например, SourceForge (`SF`)? ++ +Это максимально упрощено. См. crossref:makefiles[ports-master-sites-n-example-detailed-use-master-site-sourceforge,Подробное использование `MASTER_SITES:n` с SourceForge (`SF`)]. + [[ports-master-sites-n-example-detailed-use-master-site-sourceforge]] -.Подробное использование `MASTER_SITES:n` с `MASTER_SITE_SOURCEFORGE` +.Подробное использование `MASTER_SITES:n` с SourceForge (`SF`) [example] ==== + [.programlisting] .... -MASTER_SITES= http://site1/ ${MASTER_SITE_SOURCEFORGE:S/$/:sourceforge,TEST/} +MASTER_SITES= http://site1/ SF/something/1.0:sourceforge,TEST DISTFILES= something.tar.gz:sourceforge .... +[.filename]#something.tar.gz# будет загружен со всех сайтов в пределах SourceForge. ==== -+ -[.filename]#something.tar.gz# будет сгружаться со всех сайтов из `MASTER_SITE_SOURCEFORGE`. -. Как мне использовать это с переменными `PATCH*`? -+ -Все примеры выполнялись с переменными `MASTER*`, и они работают точно так же и для `PATCH*`, как это можно видеть в <<ports-master-sites-n-example-detailed-use-patch-sites>>. +. Как использовать это с `PATCH*`? ++ +Все примеры были выполнены с `MASTER*`, но они работают точно так же для `PATCH*`, как можно увидеть в crossref:makefiles[ports-master-sites-n-example-detailed-use-patch-sites,Упрощённое использование `MASTER_SITES:n` с `PATCH_SITES`]. + [[ports-master-sites-n-example-detailed-use-patch-sites]] -.Упрощённое использование `MASTER_SITES:n` с `PATCH_SITES`. +.Упрощённое использование `MASTER_SITES:n` с `PATCH_SITES` [example] ==== + [.programlisting] .... PATCH_SITES= http://site1/ http://site2/:test @@ -1169,162 +2243,966 @@ PATCHFILES= patch1:test ==== -==== Что изменится для портов? А что не изменится? +[[port-master-sites-n-what-changed]] +==== Что меняется для портов? Что остается неизменным? [lowerroman] -. Все имеющиеся порты остаются без изменений. Код для механизма `MASTER_SITES:n` активируется, если только есть элементы, которые заканчиваются на `:n`, как и элементы в соответствии с вышеописанным синтаксисом, особенно как это показано в пункте <<porting-master-sites-n-group-semantics,7>>. +. Все текущие порты остаются без изменений. Функция `MASTER_SITES:n` активируется только при наличии элементов с постфиксом `:__n__`, соответствующих указанным выше синтаксическим правилам, в частности, как показано в пункте crossref:makefiles[porting-master-sites-n-group-semantics, 7]. ++ [[porting-master-sites-n-what-changes-in-port-targets]] -. Цели порт остаются теми же самыми: `checksum`, `makesum`, `patch`, `configure`, `build` и так далее. С обычными исключениями для `do-fetch`, `fetch-list`, `master-sites` и `patch-sites`. +. Порты сохраняют те же цели: `checksum`, `makesum`, `patch`, `configure`, `build` и т.д., за исключением очевидных случаев: `do-fetch`, `fetch-list`, `master-sites` и `patch-sites`. -** `do-fetch`: использует новую группировку с постфиксами в `DISTFILES` и `PATCHFILES` с соответствующими элементами групп в `MASTER_SITES` и `PATCH_SITES`, которые используют группы из `MASTER_SITE_SUBDIR` и `PATCH_SITE_SUBDIR`. Посмотрите <<ports-master-sites-n-example-detailed-use-complete-example-master-sites>>. -** `fetch-list`: работает так же, как старая цель `fetch-list` с тем исключением, что она группирует, как и `do-fetch`. -** `master-sites` и `patch-sites`: (несовместимы со старыми версиями) только возвращают элементы группы `DEFAULT`; на самом деле они выполняют цели `master-sites-default` и `patch-sites-default` соответственно. -+ -Более того, использование целей `master-sites-all` или `patch-sites-all` предпочтительно для непосредственной проверки `MASTER_SITES` или `PATCH_SITES`. Также работа прямой проверки в последующих версиях не гарантируется. Посмотрите <<porting-master-sites-n-new-port-targets-master-sites-all, B>> для получения более дополнительной информации об этих новых целях. +** `do-fetch`: развертывает новую группировку с постфиксом `DISTFILES` и `PATCHFILES` с соответствующими групповыми элементами в `MASTER_SITES` и `PATCH_SITES`, которые используют соответствующие групповые элементы в `MASTER_SITE_SUBDIR` и `PATCH_SITE_SUBDIR`. Проверьте crossref:makefiles[ports-master-sites-n-example-detailed-use-complete-example-master-sites,Подробное использование `MASTER_SITES:n` с оператором запятой, множественными файлами, множественными сайтами и множественными подкаталогами]. +** `fetch-list`: работает как старый `fetch-list`, за исключением того, что группировка происходит так же, как в `do-fetch`. +** `master-sites` и `patch-sites`: (несовместимо с более старыми версиями) возвращают только элементы группы `DEFAULT`; фактически они выполняют цели `master-sites-default` и `patch-sites-default` соответственно. ++ +Кроме того, предпочтительнее использовать цель `master-sites-all` или `patch-sites-all`, чем напрямую проверять `MASTER_SITES` или `PATCH_SITES`. Кроме того, прямая проверка не гарантирует работу в будущих версиях. Для получения дополнительной информации об этих новых целях портов см. пункт crossref:makefiles[porting-master-sites-n-new-port-targets-master-sites-all, B]. -. Новые цели построения портов -.. Имеются цели `master-sites-_n_` и `patch-sites-_n_`, которые будут перечислять элементы соответствующей группы _n_ из `MASTER_SITES` и `PATCH_SITES` соответственно. К примеру, `master-sites-DEFAULT` и `patch-sites-DEFAULT` обе будут возвращать элементы группы `DEFAULT`, `master-sites-test` и `patch-sites-test` группы `test` и так далее. +. Новые цели портов +.. Существуют цели `master-sites-_n_` и `patch-sites-_n_`, которые будут выводить элементы соответствующей группы _n_ в `MASTER_SITES` и `PATCH_SITES` соответственно. Например, и `master-sites-DEFAULT`, и `patch-sites-DEFAULT` вернут элементы группы `DEFAULT`, `master-sites-test` и `patch-sites-test` — группы `test`, и так далее. ++ [[porting-master-sites-n-new-port-targets-master-sites-all]] -.. Имеются новые цели `master-sites-all` и `patch-sites-all`, которые выполняют работу старых `master-sites` и `patch-sites`. Они возвращают элементы всех групп, как если бы они все принадлежали одной и той же группе с тем, что она перечисляет ровно столько `MASTER_SITE_BACKUP` и `MASTER_SITE_OVERRIDE`, как и группы, определённые в `DISTFILES` или `PATCHFILES`; соответственно для `master-sites-all` и `patch-sites-all`. +.. Существуют новые цели `master-sites-all` и `patch-sites-all`, которые выполняют работу старых `master-sites` и `patch-sites`. Они возвращают элементы всех групп, как если бы они все принадлежали одной группе, с оговоркой, что перечисляется столько же `MASTER_SITE_BACKUP` и `MASTER_SITE_OVERRIDE`, сколько определено групп в `DISTFILES` или `PATCHFILES`; соответственно для `master-sites-all` и `patch-sites-all`. +[[makefile-dist_subdir]] === `DIST_SUBDIR` -Не позволяйте вашему порту засорять [.filename]#/usr/ports/distfiles#. Если вашему порту требуется сгрузить много файлов, или он содержит имя файла, могущее вызвать конфликты с другими портами (например, [.filename]#Makefile#), то укажите в переменной `DIST_SUBDIR` имя порта (должны подойти `${PORTNAME}` или `${PKGNAMEPREFIX}${PORTNAME}`). Это изменит значение переменной `DISTDIR` со значения по умолчанию [.filename]#/usr/ports/distfiles# к значению [.filename]#/usr/ports/distfiles/DIST_SUBDIR#, и в результате всё, что требуется для порта, будет помещено в этот подкаталог. +Не допускайте захламления портом каталога [.filename]#/usr/ports/distfiles#. Если порт требует загрузки большого количества файлов или содержит файл с именем, которое может конфликтовать с другими портами (например, [.filename]#Makefile#), установите `DIST_SUBDIR` в имя порта (подойдут `${PORTNAME}` или `${PKGNAMEPREFIX}${PORTNAME}`). Это изменит `DISTDIR` со значения по умолчанию [.filename]#/usr/ports/distfiles# на [.filename]#/usr/ports/distfiles/${DIST_SUBDIR}#, фактически помещая все необходимые для порта файлы в этот подкаталог. + +Также будет проверяться подкаталог с тем же именем на основном резервном сайте по адресу http://distcache.FreeBSD.org[http://distcache.FreeBSD.org] (Явное указание `DISTDIR` в [.filename]#Makefile# не решит эту задачу, поэтому используйте `DIST_SUBDIR`.) + +[NOTE] +==== +Это не влияет на сайты в `MASTER_SITES`, определённые в [.filename]#Makefile#. +==== + +[[makefile-maintainer]] +== `MAINTAINER` + +Установите здесь свой адрес электронной почты. Пожалуйста. _:-)_ -Он заглянет также в подкаталог с тем же именем на основном резервном сервере [.filename]#ftp.FreeBSD.org#. (Явное задание переменной `DISTDIR` в вашем файле `Makefile` этого не сделает, так что, пожалуйста, воспользуйтесь `DIST_SUBDIR`.) +Только один адрес без комментария допускается в качестве значения `MAINTAINER`. Используемый формат: `user@hostname.domain`. Пожалуйста, не включайте в эту запись описательный текст, например, настоящее имя. Это только вносит путаницу в инфраструктуру Ports и большинство инструментов, которые её используют. + +Ответственный за поддержку порта обязан поддерживать порт в актуальном состоянии и обеспечивать его корректную работу. Подробное описание обязанностей ответственного за поддержку порта приведено в разделе extref:{contributing}[Задача для сопровождающих портов,maintain-port]. [NOTE] ==== -Это не коснётся тех сайтов `MASTER_SITES`, которые вы указали в вашем файле [.filename]#Makefile#. +Сопровождающий добровольно поддерживает порт в рабочем состоянии. Сопровождающие несут основную ответственность за свои порты, но не имеют исключительных прав на них. Порты существуют для пользы сообщества и, по сути, принадлежат сообществу. Это означает, что люди, не являющиеся сопровождающими, также могут вносить изменения в порт. Крупные изменения в коллекции портов могут потребовать правок во многих портах. Команда управления портами FreeBSD или члены других команд могут изменять порты для исправления проблем с зависимостями или других проблем, таких как обновление версии динамической библиотеки. + +Некоторые типы исправлений имеют "автоматическое согласование" от {portmgr}, что позволяет любому коммиттеру исправлять эти категории проблем в любом порте. Такие исправления не требуют одобрения от сопровождающего. + +Автоматическое согласование для большинства портов применяется к исправлениям, таким как изменения инфраструктуры, или тривиальным и _проверенным_ исправлениям сборки и выполнения. Текущий список доступен в extref:{committers-guide}[разделе Портов Руководства коммиттера, ports-qa-misc-blanket-approval]. ==== -=== `ALWAYS_KEEP_DISTFILES` +Другие изменения в порте будут отправлены сопровождающему на проверку и утверждение перед внесением. Если сопровождающий не отвечает на запрос об обновлении в течение двух недель (за исключением основных государственных праздников), это считается превышением времени ожидания сопровождающего, и обновление может быть внесено без его явного одобрения. Если сопровождающий не отвечает в течение трех месяцев или если произошло три последовательных превышения времени ожидания, то сопровождающий считается отсутствующим без уведомления, и все его порты могут быть возвращены в общий пул. Исключениями являются порты, сопровождаемые {portmgr} или {security-officer}. Никакие несанкционированные изменения не могут быть внесены в порты, сопровождаемые этими группами. + +Мы оставляем за собой право изменять представленные сопровождающим материалы, чтобы лучше соответствовать существующим политикам и стилю Коллекции портов, без явного одобрения отправителя или сопровождающего. Кроме того, масштабные инфраструктурные изменения могут привести к модификации порта без согласия сопровождающего. Подобные изменения никогда не повлияют на функциональность порта. + +{portmgr} оставляет за собой право отозвать или изменить права сопровождающего по любой причине, а {security-officer} оставляет за собой право отозвать или изменить права сопровождающего по соображениям безопасности. + +[[makefile-comment]] +== `COMMENT` + +Комментарий — это однострочное описание порта, отображаемое командой `pkg info`. При составлении придерживайтесь следующих правил: + +. Строка COMMENT должна быть не длиннее 70 символов. +. Не включайте название пакета или номер версии программного обеспечения. +. Комментарий должен начинаться с заглавной буквы и заканчиваться без точки. +. Не начинайте с неопределённого артикля (то есть A или An). +. Пишите названия с заглавной буквы, например: Apache, JavaScript или Perl. +. Используйте запятую для списков слов: "green, red, and blue." +. Проверяйте на наличие орфографических ошибок. + +Вот пример: + +[.programlisting] +.... +COMMENT= Cat chasing a mouse all over the screen +.... + +Переменная COMMENT следует сразу за переменной MAINTAINER в файле [.filename]#Makefile#. + +[[makefile-www]] +== Веб-сайт проекта + +Каждый порт должен указывать на веб-сайт, предоставляющий дополнительную информацию о программном обеспечении. + +Везде, где это возможно, следует использовать официальный сайт проекта, поддерживаемый разработчиками программного обеспечения. + +[.programlisting] +.... +WWW= https://ffmpeg.org/ +.... + +Но это также может быть каталог или ресурс в репозитории исходного кода: + +[.programlisting] +.... +WWW= https://sourceforge.net/projects/mpd/ +.... + +Переменная WWW следует сразу за переменной COMMENT в файле [.filename]#Makefile#. + +Если один и тот же контент доступен по HTTP и HTTPS, следует использовать URL, начинающийся с `https://`. Если URI является корнем веб-сайта или директории, он должен заканчиваться косой чертой. + +Эта информация ранее размещалась в последней строке файла [.filename]#pkg-descr#. Она была перенесена в Makefile для удобства обслуживания и обработки. Наличие строки `WWW:` в конце файла [.filename]#pkg-descr# считается устаревшим. + +[[licenses]] +== Лицензии + +Каждый порт должен содержать документацию о лицензии, под которой он распространяется. Если лицензия не одобрена OSI, необходимо также указать любые ограничения на распространение. -Если ваш порт использует двоичные дистрибутивные файлы и обладает лицензией, требующей, чтобы исходный код предоставлялся вместе с пакетами, распространяемыми в двоичной форме, например GPL, то `ALWAYS_KEEP_DISTFILES` даст кластеру построения FreeBSD указание сохранять копию файлов, указанных в `DISTFILES`. Пользователям таких портов эти файлы в основном не нужны, поэтому хорошей идеей является добавление в `DISTFILES` исходных дистрибутивных файлов, только когда определена переменная `PACKAGE_BUILDING`. +[[licenses-license]] +=== `LICENSE` -[[ports-master-sites-n-example-always-keep-distfiles]] -.Использование `ALWAYS_KEEP_DISTFILES`. +Краткое название лицензии или лицензий, если применяется более одной лицензии. + +Если это одна из лицензий, перечисленных в crossref:makefiles[licenses-license-list,Предопределенный список лицензий], можно задать только переменные `LICENSE_FILE` и `LICENSE_DISTFILES`. + +Если это лицензия, которая не определена в рамках портов (см. crossref:makefiles[licenses-license-list,Список предопределённых лицензий]), необходимо задать `LICENSE_PERMS` и `LICENSE_NAME`, а также `LICENSE_FILE` или `LICENSE_TEXT`. Также можно задать `LICENSE_DISTFILES` и `LICENSE_GROUPS`, но это не обязательно. + +Предопределенные лицензии показаны в crossref:makefiles[licenses-license-list,Список предопределенных лицензий]. Текущий список всегда доступен в [.filename]#Mk/bsd.licenses.db.mk#. + +[[licenses-license-ex1]] +.Простейшее использование, предопределённые лицензии [example] ==== + +Когда в файле [.filename]#README# какого-либо программного обеспечения указано: «Данное программное обеспечение распространяется на условиях GNU Lesser General Public License, опубликованной Free Software Foundation; либо версии 2.1 Лицензии, либо (по вашему выбору) любой более поздней версии», но сам файл лицензии не предоставлен, используйте следующее: + [.programlisting] .... -.if defined(PACKAGE_BUILDING) -DISTFILES+= foo.tar.gz -ALWAYS_KEEP_DISTFILES= yes -.endif +LICENSE= LGPL21+ +.... + +Когда программное обеспечение предоставляет файл лицензии, используйте это: + +[.programlisting] +.... +LICENSE= LGPL21+ +LICENSE_FILE= ${WRKSRC}/COPYING .... ==== -При добавлении дополнительных файлов в `DISTFILES` убедитесь, что вы их также добавляете в [.filename]#distinfo#. Кроме того, дополнительные файлы обычно распаковываются также в `WRKDIR`, что для некоторых портов может вызывать нежелательные подобные эффекты и требовать особую обработку. +Для предопределённых лицензий права по умолчанию: `dist-mirror dist-sell pkg-mirror pkg-sell auto-accept`. -[[makefile-maintainer]] -== `MAINTAINER` +[[licenses-license-list]] +.Предопределенный список лицензий +[cols="1,1,1,1", frame="none", options="header"] +|=== +| Короткое имя +| Имя +| Группа +| Разрешения + +|`AGPLv3` +|Универсальная общественная лицензия GNU Affero версии 3 +|`FSF GPL OSI` +|(по умолчанию) + +|`AGPLv3+` +|Универсальная общественная лицензия GNU Affero версии 3 (или позднее) +|`FSF GPL OSI` +|(по умолчанию) + +|`APACHE10` +|Apache License 1.0 +|`FSF` +|(по умолчанию) + +|`APACHE11` +|Apache License 1.1 +|`FSF OSI` +|(по умолчанию) + +|`APACHE20` +|Apache License 2.0 +|`FSF OSI` +|(по умолчанию) + +|`ART10` +|Художественная лицензия версия 1.0 +|`OSI` +|(по умолчанию) + +|`ART20` +|Художественная лицензия версии 2.0 +|`FSF GPL OSI` +|(по умолчанию) + +|`ARTPERL10` +|Художественная лицензия (perl) версия 1.0 +|`OSI` +|(по умолчанию) + +|`BSD` +|Лицензия BSD, общая версия (устарела) +|`FSF OSI COPYFREE` +|(по умолчанию) + +|`BSD2CLAUSE` +|BSD 2-пунктная лицензия "Упрощенная" +|`FSF OSI COPYFREE` +|(по умолчанию) + +|`BSD3CLAUSE` +|BSD 3-пунктная лицензия "Новая" или "Пересмотренная" +|`FSF OSI COPYFREE` +|(по умолчанию) + +|`BSD4CLAUSE` +|BSD 4-пунктная лицензия "Оригинальная" или "Старая" +|`FSF` +|(по умолчанию) + +|`BSL` +|Лицензия программного обеспечения Boost +|`FSF OSI COPYFREE` +|(по умолчанию) + +|`CC-BY-1.0` +|Creative Commons с указанием авторства 1.0 +| +|(по умолчанию) + +|`CC-BY-2.0` +|Creative Commons с указанием авторства 2.0 +| +|(по умолчанию) + +|`CC-BY-2.5` +|Creative Commons с указанием авторства 2.5 +| +|(по умолчанию) + +|`CC-BY-3.0` +|Creative Commons с указанием авторства 3.0 +| +|(по умолчанию) + +|`CC-BY-4.0` +|Creative Commons с указанием авторства 4.0 +| +|(по умолчанию) + +|`CC-BY-NC-1.0` +|Creative Commons с указанием авторства – некоммерческая 1.0 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-2.0` +|Creative Commons с указанием авторства – некоммерческая 2.0 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-2.5` +|Creative Commons с указанием авторства – некоммерческая 2.5 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-3.0` +|Creative Commons с указанием авторства – некоммерческая 3.0 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-4.0` +|Creative Commons с указанием авторства – некоммерческая 4.0 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-ND-1.0` +|Creative Commons с указанием авторства – некоммерческая – без производных 1.0 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-ND-2.0` +|Creative Commons с указанием авторства – некоммерческая – без производных 2.0 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-ND-2.5` +|Creative Commons с указанием авторства – некоммерческая – без производных 2.5 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-ND-3.0` +|Creative Commons с указанием авторства – некоммерческая – без производных 3.0 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-ND-4.0` +|Creative Commons с указанием авторства – некоммерческая – без производных 4.0 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-SA-1.0` +|Creative Commons с указанием авторства – некоммерческая – на тех же условиях 1.0 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-SA-2.0` +|Creative Commons с указанием авторства – некоммерческая – на тех же условиях 2.0 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-SA-2.5` +|Creative Commons с указанием авторства – некоммерческая – на тех же условиях 2.5 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-SA-3.0` +|Creative Commons с указанием авторства – некоммерческая – на тех же условиях 3.0 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-NC-SA-4.0` +|Creative Commons с указанием авторства – некоммерческая – на тех же условиях 4.0 +| +|`dist-mirror``pkg-mirror``auto-accept` + +|`CC-BY-ND-1.0` +|Creative Commons с указанием авторства – без производных 1.0 +| +|(по умолчанию) + +|`CC-BY-ND-2.0` +|Creative Commons с указанием авторства – без производных 2.0 +| +|(по умолчанию) + +|`CC-BY-ND-2.5` +|Creative Commons с указанием авторства – без производных 2.5 +| +|(по умолчанию) + +|`CC-BY-ND-3.0` +|Creative Commons с указанием авторства – без производных 3.0 +| +|(по умолчанию) + +|`CC-BY-ND-4.0` +|Creative Commons с указанием авторства – без производных 4.0 +| +|(по умолчанию) + +|`CC-BY-SA-1.0` +|Creative Commons с указанием авторства – на тех же условиях 1.0 +| +|(по умолчанию) + +|`CC-BY-SA-2.0` +|Creative Commons с указанием авторства – на тех же условиях 2.0 +| +|(по умолчанию) + +|`CC-BY-SA-2.5` +|Creative Commons с указанием авторства – на тех же условиях 2.5 +| +|(по умолчанию) + +|`CC-BY-SA-3.0` +|Creative Commons с указанием авторства – на тех же условиях 3.0 +| +|(по умолчанию) + +|`CC-BY-SA-4.0` +|Creative Commons с указанием авторства – на тех же условиях 4.0 +| +|(по умолчанию) + +|`CC0-1.0` +|Creative Commons Zero v1.0 Universal (Отказ от прав 1.0 Универсальная) +|`FSF GPL COPYFREE` +|(по умолчанию) + +|`CDDL` +|Лицензия на совместную разработку и распространение +|`FSF OSI` +|(по умолчанию) + +|`CPAL-1.0` +|Публичная лицензия общего распространения с указанием авторства +|`FSF OSI` +|(по умолчанию) + +|`ClArtistic` +|Уточнённая художественная лицензия +|`FSF GPL OSI` +|(по умолчанию) + +|`EPL` +|Публичная лицензия Eclipse +|`FSF OSI` +|(по умолчанию) + +|`GFDL` +|GNU Свободная лицензия на документацию +|`FSF` +|(по умолчанию) + +|`GMGPL` +|Модифицированная Общедоступная лицензия GNAT +|`FSF GPL OSI` +|(по умолчанию) + +|`GPLv1` +|Универсальная общественная лицензия GNU версии 1 +|`FSF GPL OSI` +|(по умолчанию) + +|`GPLv1+` +|Универсальная общественная лицензия GNU версии 1 (или более поздняя) +|`FSF GPL OSI` +|(по умолчанию) + +|`GPLv2` +|Универсальная общественная лицензия GNU версии 2 +|`FSF GPL OSI` +|(по умолчанию) + +|`GPLv2+` +|Универсальная общественная лицензия GNU версии 2 (или более поздняя) +|`FSF GPL OSI` +|(по умолчанию) + +|`GPLv3` +|Универсальная общественная лицензия GNU версии 3 +|`FSF GPL OSI` +|(по умолчанию) + +|`GPLv3+` +|Универсальная общественная лицензия GNU версии 3 (или более поздняя) +|`FSF GPL OSI` +|(по умолчанию) + +|`GPLv3RLE` +|Исключение для библиотеки времени выполнения GNU GPL версии 3 +|`FSF GPL OSI` +|(по умолчанию) + +|`GPLv3RLE+` +|Исключение для библиотеки времени выполнения GNU GPL версии 3 (или более поздняя) +|`FSF GPL OSI` +|(по умолчанию) + +|`ISCL` +|Лицензия Internet Systems Consortium +|`FSF GPL OSI COPYFREE` +|(по умолчанию) + +|`LGPL20` +|Общедоступная лицензия GNU для библиотек, версия 2.0 +|`FSF GPL OSI` +|(по умолчанию) + +|`LGPL20+` +|Общедоступная лицензия GNU для библиотек, версия 2.0 (или более поздняя) +|`FSF GPL OSI` +|(по умолчанию) + +|`LGPL21` +|Универсальная общественная лицензия GNU ограниченного применения, версия 2.1 +|`FSF GPL OSI` +|(по умолчанию) + +|`LGPL21+` +|Универсальная общественная лицензия GNU ограниченного применения, версия 2.1 (или более поздняя) +|`FSF GPL OSI` +|(по умолчанию) + +|`LGPL3` +|Универсальная общественная лицензия GNU ограниченного применения, версия 3 +|`FSF GPL OSI` +|(по умолчанию) + +|`LGPL3+` +|Универсальная общественная лицензия GNU ограниченного применения, версия 3 (или более поздней) +|`FSF GPL OSI` +|(по умолчанию) + +|`LPPL10` +|Публичная лицензия проекта LaTeX, версия 1.0 +|`FSF OSI` +|`dist-mirror dist-sell` + +|`LPPL11` +|Публичная лицензия проекта LaTeX, версия 1.1 +|`FSF OSI` +|`dist-mirror dist-sell` + +|`LPPL12` +|Публичная лицензия проекта LaTeX, версия 1.2 +|`FSF OSI` +|`dist-mirror dist-sell` + +|`LPPL13` +|Публичная лицензия проекта LaTeX, версия 1.3 +|`FSF OSI` +|`dist-mirror dist-sell` + +|`LPPL13a` +|Публичная лицензия проекта LaTeX, версия 1.3a +|`FSF OSI` +|`dist-mirror dist-sell` + +|`LPPL13b` +|Публичная лицензия проекта LaTeX, версия 1.3b +|`FSF OSI` +|`dist-mirror dist-sell` + +|`LPPL13c` +|Публичная лицензия проекта LaTeX, версия 1.3c +|`FSF OSI` +|`dist-mirror dist-sell` + +|`MIT` +|Лицензия MIT / Лицензия X11 +|`COPYFREE FSF GPL OSI` +|(по умолчанию) + +|`MPL10` +|Публичная лицензия Mozilla, версия 1.0 +|`FSF OSI` +|(по умолчанию) + +|`MPL11` +|Публичная лицензия Mozilla, версия 1.1 +|`FSF OSI` +|(по умолчанию) + +|`MPL20` +|Публичная лицензия Mozilla, версия 2.0 +|`FSF OSI` +|(по умолчанию) + +|`NCSA` +|Открытая лицензия Университета Иллинойса/NCSA +|`COPYFREE FSF GPL OSI` +|(по умолчанию) + +|`NONE` +|Лицензия не указана +| +|`none` + +|`OFL10` +|Лицензия SIL Open Font версия 1.0 (https://scripts.sil.org/OFL/) +|`FONTS` +|(по умолчанию) + +|`OFL11` +|Лицензия SIL Open Font версия 1.1 (https://scripts.sil.org/OFL/) +|`FONTS` +|(по умолчанию) + +|`OWL` +|Лицензия Открытых Произведений (owl.apotheon.org) +|`COPYFREE` +|(по умолчанию) + +|`OpenSSL` +|Лицензия OpenSSL +|`FSF` +|(по умолчанию) + +|`PD` +|Общественное достояние +|`GPL COPYFREE` +|(по умолчанию) + +|`PHP202` +|Лицензия PHP версии 2.02 +|`FSF OSI` +|(по умолчанию) + +|`PHP30` +|Лицензия PHP версии 3.0 +|`FSF OSI` +|(по умолчанию) + +|`PHP301` +|Лицензия PHP версии 3.01 +|`FSF OSI` +|(по умолчанию) + +|`PSFL` +|Лицензия Python Software Foundation +|`FSF GPL OSI` +|(по умолчанию) + +|`PostgreSQL` +|Лицензия PostgreSQL +|`FSF GPL OSI COPYFREE` +|(по умолчанию) + +|`RUBY` +|Лицензия Ruby +|`FSF` +|(по умолчанию) + +|`UNLICENSE` +|Отказ от лицензии (The Unlicense) +|`COPYFREE FSF GPL` +|(по умолчанию) + +|`WTFPL` +|Публичная лицензия "Делай что хочешь" версия 2 +|`GPL FSF COPYFREE` +|(по умолчанию) + +|`WTFPL1` +|Публичная лицензия "Делай что хочешь" версия 1 +|`GPL FSF COPYFREE` +|(по умолчанию) + +|`ZLIB` +|Лицензия zlib +|`GPL FSF OSI` +|(по умолчанию) + +|`ZPL21` +|Публичная лицензия Zope версия 2.1 +|`GPL OSI` +|(по умолчанию) +|=== -Укажите здесь ваш адрес электронной почты. Пожалуйста. _:-)_ +[[licenses-license_perms]] +=== `LICENSE_PERMS` и `LICENSE_PERMS_NAME_` -Заметьте, что в качестве значения для `MAINTAINER` допустимо использование только одного адреса без поля комментария. Должен использоваться формат `user@hostname.domain`. Пожалуйста, не включайте никакого описательного текста, например, вашего настоящего имени в эту строку-это несколько сбивает с толку [.filename]#bsd.port.mk#. +Разрешения. Используйте `none`, если пусто. -Сопровождающий ответственен за поддержание порта в актуальном состоянии и обеспечение правильной работы порта. За подробным описанием обязанностей сопровождающего порт обращайтесь к главе extref:{contributing}[The challenge for port maintainers, maintain-port]. +.Список разрешений лицензии +[[licenses-license_perms-dist-mirror]] +`dist-mirror`:: +Разрешается распространение дистрибутивных файлов. Дистрибутивные файлы будут добавлены в CDN `MASTER_SITE_BACKUP` FreeBSD. -Перед фиксацией в репозитории изменения в порте будут отправлены сопровождающему для просмотра и одобрения. Если сопровождающий порта не ответил на запрос пользователя об обновлении в течение двух недель (исключая большие праздники), то это можно считать тайм-аутом сопровождающего, и обновление может быть выполнено без явного подтверждения от сопровождающего. Если сопровождающий не отвечает в течение трёх месяцев, то считается, что он отсутствует, и как сопровождающий порта, о котором идёт речь, может быть заменён. Исключениями из этого правила является всё, что сопровождает {portmgr} или {security-officer}. Запрещено делать любые несанкционированные изменения в портах, которые ведут эти группы. +[[licenses-license_perms-no-dist-mirror]] +`no-dist-mirror`:: +Распространение дистрибутивных файлов запрещено. Это эквивалентно установке crossref:special[porting-restrictions-restricted,`RESTRICTED`]. Дистрибутивные файлы _не_ будут добавлены в CDN `MASTER_SITE_BACKUP` FreeBSD. -Мы оставляем за собой право изменять сообщение сопровождающего для лучшего соответствия существующим политикам и стилю Коллекции Портов без явного одобрения со стороны отправителя. Также, крупные изменения в инфраструктуре могут повлечь изменения в порте без согласия сопровождающего. Такой вид изменений никогда не будет затрагивать функциональность порта. +[[licenses-license_perms-dist-sell]] +`dist-sell`:: +Продажа файлов дистрибутива разрешена. Файлы дистрибутива будут присутствовать на образах установщика. -За {portmgr} оставляется право снять или назначить кого-либо сопровождающим по любой причине, а за {security-officer} оставляется право лишать или назначать права на сопровождение порта по соображениям информационной безопасности. +[[licenses-license_perms-no-dist-sell]] +`no-dist-sell`:: +Продажа файлов дистрибутива запрещена. Это эквивалентно установке crossref:special[porting-restrictions-no_cdrom,`NO_CDROM`]. -[[makefile-comment]] -== `COMMENT` +[[licenses-license_perms-pkg-mirror]] +`pkg-mirror`:: +Свободное распространение пакета разрешено. Пакет будет распространяться через CDN пакетов FreeBSD https://pkg.freebsd.org/[https://pkg.freebsd.org/]. -Содержит однострочное описание порта. Пожалуйста, соблюдайте следующие правила: +[[licenses-license_perms-no-pkg-mirror]] +`no-pkg-mirror`:: +Свободное распространение пакета запрещено. Эквивалентно установке crossref:special[porting-restrictions-no_package,`NO_PACKAGE`]. Пакет _не_ будет распространяться через FreeBSD CDN для пакетов https://pkg.freebsd.org/[https://pkg.freebsd.org/]. -. Старайтесь делать строку COMMENT длиной не больше, чем 70 символов, так как эта строка будет использована командой `pkg info` (см. man:pkg-info[8]) для отображения однострочного описания порта; -. _Не_ включайте сюда название пакета (или номер версии программного обеспечения); -. Комментарий должен начинаться с заглавной буквы и не заканчиваться точкой; -. Не начинайте комментарий с неопределённого артикля (A или An); -. Имена пишутся с заглавной буквы (например, Apache, JavaScript, Perl); -. Для перечислений используйте английскую Оксфордскую запятую (англ. Oxford comma) (например, green, red, and blue); -. Используйте программу проверки орфографии. +[[licenses-license_perms-pkg-sell]] +`pkg-sell`:: +Продажа пакета разрешена. Пакет будет присутствовать на образах установщика. -Вот пример: +[[licenses-license_perms-no-pkg-sell]] +`no-pkg-sell`:: +Продажа пакета запрещена. Это эквивалентно установке crossref:special[porting-restrictions-no_cdrom,`NO_CDROM`]. Пакет _не_ будет присутствовать на образах установщика. + +[[licenses-license_perms-auto-accept]] +`auto-accept`:: +Лицензия принимается по умолчанию. Запросы на принятие лицензии не отображаются, если пользователь не определил `LICENSES_ASK`. Используйте это, если в лицензии не указано, что пользователь должен принять условия лицензии. + +[[licenses-license_perms-no-auto-accept]] +`no-auto-accept`:: +Лицензия не принимается по умолчанию. Пользователь всегда будет запрошен на подтверждение принятия данной лицензии. Это должно использоваться, если лицензия требует, чтобы пользователь принял её условия. + +Когда присутствуют и `_permission_`, и `no-_permission_`, то `no-_permission_` отменяет `_permission_`. + +Когда `_permission_` отсутствует, это считается как `no-_permission_`. + +[WARNING] +==== +Некоторые отсутствующие разрешения могут сделать порт (и все зависящие от него порты) непригодными для использования пользователями пакетов: + +Порт без разрешения `auto-accept` никогда не будет собран, и все зависящие от него порты будут проигнорированы. + +Порт без разрешения `pkg-mirror`, а также любые порты, зависящие от него, будут удалены после сборки, что гарантирует их отсутствие в дистрибуции. +==== + +[[licenses-license_perms-ex1]] +.Нестандартная лицензия +[example] +==== +Прочитайте условия лицензии и переведите их, используя доступные разрешения. [.programlisting] .... -COMMENT= Cat chasing a mouse all over the screen +LICENSE= UNKNOWN +LICENSE_NAME= unknown +LICENSE_TEXT= This program is NOT in public domain.\ + It can be freely distributed for non-commercial purposes only. +LICENSE_PERMS= dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept +.... + +==== + +[[licenses-license_perms-ex2]] +.Стандартные и нестандартные лицензии +[example] +==== + +Прочитайте условия лицензии и укажите их, используя доступные разрешения. В случае сомнений обратитесь за разъяснениями на {freebsd-ports}. + +[.programlisting] +.... +LICENSE= WARSOW GPLv2 +LICENSE_COMB= multi +LICENSE_NAME_WARSOW= Warsow Content License +LICENSE_FILE_WARSOW= ${WRKSRC}/docs/license.txt +LICENSE_PERMS_WARSOW= dist-mirror pkg-mirror auto-accept +.... + +Когда разрешения лицензий GPLv2 и UNKNOWN смешиваются, порт получает `dist-mirror dist-sell pkg-mirror pkg-sell auto-accept dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept`. Опции `no-_разрешения_` отменяют соответствующие _разрешения_. Итоговый список разрешений: _dist-mirror pkg-mirror auto-accept_. Файлы дистрибутива и пакеты не будут доступны в образах установщика. +==== + +[[licenses-license_groups]] +=== `LICENSE_GROUPS` и `LICENSE_GROUPS_NAME` + +Группы, к которым принадлежит лицензия. + +.Список предопределенных групп лицензий +[[licenses-license_groups-FSF]] +`FSF`:: +Одобрено Free Software Foundation, см. https://www.fsf.org/licensing/[Команда по лицензированию и соответствию FSF]. + +[[licenses-license_groups-GPL]] +`GPL`:: +Совместимые с GPL + +[[licenses-license_groups-OSI]] +`OSI`:: +Одобрено OSI, см. страницу https://opensource.org/licenses/[Открытых лицензий]. + +[[licenses-license_groups-COPYFREE]] +`COPYFREE`:: +Соответствует определению стандарта Copyfree, см. страницу https://copyfree.org/standard/licenses/[лицензий Copyfree]. + +[[licenses-license_groups-FONTS]] +`FONTS`:: +Лицензии на шрифты + +[[licenses-license_name]] +=== `LICENSE_NAME` и `LICENSE_NAME_NAME` + +Полное название лицензии. + +[[licenses-license_name-ex1]] +.`LICENSE_NAME` +[example] +==== + +[.programlisting] +.... +LICENSE= UNRAR +LICENSE_NAME= UnRAR License +LICENSE_FILE= ${WRKSRC}/license.txt +LICENSE_PERMS= dist-mirror dist-sell pkg-mirror pkg-sell auto-accept .... -В файле [.filename]#Makefile# переменная COMMENT должна следовать сразу за переменной MAINTAINER. +==== + +[[licenses-license_file]] +=== `LICENSE_FILE` и `LICENSE_FILE_NAME` + +Полный путь к файлу, содержащему текст лицензии, обычно [.filename]#${WRKSRC}/some/file#. Если файл отсутствует в дистрибутиве, а его содержимое слишком длинное для размещения в crossref:makefiles[licenses-license_text,`LICENSE_TEXT`], поместите его в новый файл в [.filename]#${FILESDIR}#. + +[[licenses-license_file-ex1]] +.`LICENSE_FILE` +[example] +==== + +[.programlisting] +.... +LICENSE= GPLv3+ +LICENSE_FILE= ${WRKSRC}/COPYING +.... + +==== + +[[licenses-license_text]] +=== `LICENSE_TEXT` и `LICENSE_TEXT_NAME` + +Текст для использования в качестве лицензии. Полезно, когда лицензия отсутствует в файлах дистрибутива и её текст краток. + +[[licenses-license_text-ex1]] +.`LICENSE_TEXT` +[example] +==== +[.programlisting] +.... +LICENSE= UNKNOWN +LICENSE_NAME= unknown +LICENSE_TEXT= This program is NOT in public domain.\ + It can be freely distributed for non-commercial purposes only,\ + and THERE IS NO WARRANTY FOR THIS PROGRAM. +LICENSE_PERMS= dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept +.... + +==== + +[[licenses-license_distfiles]] +=== `LICENSE_DISTFILES` и `LICENSE_DISTFILES_NAME` + +Файлы дистрибутива, к которым применяются лицензии. По умолчанию — все файлы дистрибутива. + +[[licenses-license_distfiles-ex1]] +.`LICENSE_DISTFILES` +[example] +==== +Используется, когда файлы дистрибутива имеют разные лицензии. Например, один файл имеет лицензию на код, а другой содержит некоторые произведения искусства, которые нельзя распространять: + +[.programlisting] +.... +MASTER_SITES= SF/some-game +DISTFILES= ${DISTNAME}${EXTRACT_SUFX} artwork.zip + +LICENSE= BSD3CLAUSE ARTWORK +LICENSE_COMB= dual +LICENSE_NAME_ARTWORK= The game artwork license +LICENSE_TEXT_ARTWORK= The README says that the files cannot be redistributed +LICENSE_PERMS_ARTWORK= pkg-mirror pkg-sell auto-accept +LICENSE_DISTFILES_BSD3CLAUSE= ${DISTNAME}${EXTRACT_SUFX} +LICENSE_DISTFILES_ARTWORK= artwork.zip +.... + +==== + +[[licenses-license_comb]] +=== `LICENSE_COMB` + +Установите значение `multi`, если применяются все лицензии. Установите значение `dual`, если применяется любая из лицензий. По умолчанию используется значение `single`. + +[[licenses-license_comb-ex1]] +.Двойные лицензии +[example] +==== + +Когда порт содержит указание «Это программное обеспечение может распространяться под GNU General Public License или Artistic License», это означает, что можно использовать любую из этих лицензий. Используйте следующее: + +[.programlisting] +.... +LICENSE= ART10 GPLv1 +LICENSE_COMB= dual +.... + +Если предоставлены файлы лицензий, используйте это: + +[.programlisting] +.... +LICENSE= ART10 GPLv1 +LICENSE_COMB= dual +LICENSE_FILE_ART10= ${WRKSRC}/Artistic +LICENSE_FILE_GPLv1= ${WRKSRC}/Copying +.... + +==== + +[[licenses-license_comb-ex2]] +.Множественные лицензии +[example] +==== + +Если часть порта имеет одну лицензию, а другая часть — другую, используйте `multi`: + +[.programlisting] +.... +LICENSE= GPLv2 LGPL21+ +LICENSE_COMB= multi +.... + +==== [[makefile-portscout]] == `PORTSCOUT` -Portscout являет собой автоматизированное средство проверки доступности дистрибутивных файлов для Коллекции Портов FreeBSD, подробное описание которого предоставляет crossref:keeping-up[distfile-survey, Portscout: сканер дистрибутивных файлов портов FreeBSD]. +Portscout — это автоматизированная утилита проверки distfile для Коллекции портов FreeBSD, подробно описанная в crossref:keeping-up[distfile-survey,Portscout: сканирование distfile портов FreeBSD]. + +`PORTSCOUT` определяет специальные условия, в рамках которых работа сканера дистрибутивных файлов Portscout ограничена. -Переменная `PORTSCOUT` задаёт специальные условия, ограничивающие работу Portscout - сканера дистрибутивных файлов. +Ситуации, когда установлена переменная `PORTSCOUT`, включают: -Ситуации, при которых следует указывать переменную `PORTSCOUT`: +* Когда необходимо игнорировать distfiles для определённых версий. Например, чтобы исключить версию _8.2_ и версию _8.3_ из проверок версий distfiles, так как известно, что они неработоспособны, добавьте: ++ +[.programlisting] +.... +PORTSCOUT= skipv:8.2,8.3 +.... -* Когда должны игнорироваться дистрибутивные файлы для конкретных версий или младших ревизий. Например, чтобы исключить из проверок новых версий дистрибутивных файлов версию _8.2_ по причине того, что она является поломанной, добавьте следующее: +* Когда проверки версий distfile необходимо полностью отключить. Например, если порт больше не будет обновляться, добавьте: + [.programlisting] .... -PORTSCOUT= ignore:8.2 +PORTSCOUT= ignore:1 .... -* Когда должны проверяться конкретные версии или старшие и младшие ревизии дистрибутивных файлов. Например, если следует ограничиться проверкой версии _0.6.4_, потому что более новые версии имеют проблемы совместимости с FreeBSD, добавьте: +* Когда необходимо проверять конкретные версии или определенные мажорные и минорные редакции distfile. Например, если нужно отслеживать только версию _0.6.4_, потому что более новые версии имеют проблемы совместимости с FreeBSD, добавьте: + [.programlisting] .... PORTSCOUT= limit:^0\.6\.4 .... -* Когда URL, в которых указаны доступные версии, отличаются от URL их загрузки. Например, чтобы привязать проверку новых версий дистрибутивных файлов к странице загрузки для порта package:databases/pgtune[], добавьте: +* Когда URL-адреса, перечисляющие доступные версии, отличаются от URL-адресов загрузки. Например, чтобы ограничить проверку версий distfile страницей загрузки для пакета: package:databases/pgtune[] добавьте: + [.programlisting] .... -PORTSCOUT= site:http://pgfoundry.org/frs/?group_id=1000416 +PORTSCOUT= site:http://www.renpy.org/dl/release/ .... [[makefile-depend]] == Зависимости -Многие порты зависят от других портов. Это очень удобная замечательная особенность большинства Unix-подобных операционных систем, включая FreeBSD. Множество портов могут использовать общую зависимость совместно, а не включать её в состав каждого порта или пакета, который в ней нуждается. Имеется семь переменных, которые вы можете использовать для обеспечения того, что всё требуемое находится на машине пользователя. Имеется также несколько предопределённых переменных, отражающих зависимости для общих случаев, плюс ещё несколько для управления поведением зависимостей. +Многие порты зависят от других портов. Это очень удобная особенность большинства Unix-подобных операционных систем, включая FreeBSD. Несколько портов могут использовать общую зависимость вместо того, чтобы включать эту зависимость в каждый порт или пакет, который в ней нуждается. Существует семь переменных, которые можно использовать для обеспечения наличия всех необходимых компонентов на машине пользователя. Также есть предопределенные переменные зависимостей для распространенных случаев и несколько дополнительных для управления поведением зависимостей. + +[IMPORTANT] +==== +Когда у программного обеспечения есть дополнительные зависимости, предоставляющие дополнительные возможности, основные зависимости, перечисленные в `*_DEPENDS`, должны включать те дополнительные зависимости, которые будут полезны большинству пользователей. Основные зависимости никогда не должны быть "минимальным" набором зависимостей. Цель состоит не в том, чтобы включить все возможные зависимости. Включайте только те, которые будут полезны большинству людей. +==== +[[makefile-lib_depends]] === `LIB_DEPENDS` -Эта переменная указывает, от каких совместно используемых библиотек зависит порт. Это список пар lib:dir, где _lib_ - это имя библиотеки, _dir_ - это каталог, в котором можно ее найти в случае, если ее нет на машине. Например, +Эта переменная определяет разделяемые библиотеки, от которых зависит данный порт. Это список кортежей вида `_lib:dir_`, где `_lib_` — имя разделяемой библиотеки, а `_dir_` — директория, в которой её следует искать, если она недоступна. Например, [.programlisting] .... -LIB_DEPENDS= libjpeg.so:${PORTSDIR}/graphics/jpeg +LIB_DEPENDS= libjpeg.so:graphics/jpeg .... -проверит наличие библиотеки jpeg с любым номером версии и перейдет в подкаталог [.filename]#graphics/jpeg# вашего дерева портов для ее построения и установки, если библиотека отсутствует. +проверит наличие общей библиотеки jpeg с любой версией и перейдет в подкаталог [.filename]#graphics/jpeg# дерева портов, чтобы собрать и установить её, если она не найдена. -Зависимость проверяется дважды, один раз внутри цели `build`, а затем из цели `install`. Кроме того, имя зависимости помещается в пакет, так что `pkg install` (см. man:pkg-install[8]) будет автоматически её устанавливать, если её нет на пользовательской системе. +Зависимость проверяется дважды: один раз внутри цели `build` и затем внутри цели `install`. Также имя зависимости добавляется в пакет, чтобы `pkg install` (см. man:pkg-install[8]) автоматически установил её, если её нет в системе пользователя. +[[makefile-run_depends]] === `RUN_DEPENDS` -В этой переменной перечисляются выполнимые файлы или файлы, от которых зависит работа порта. Это список пар вида path:dir:target, где _path_ - это имя программы или файла, а _dir_ - каталог, в котором можно найти порт в случае, если его нет в системе, и _target_ - это цель, которую нужно вызвать в этом каталоге. Если _path_ начинается со слэша (`/`), он воспринимается как файл и его существование проверяется командой `test -e`; в противном случае предполагается, что это выполнимый файл, и для определения того, имеется ли программа в пути поиска, используется команда `which -s`. +Эта переменная определяет исполняемые файлы или файлы, от которых зависит порт во время выполнения. Это список кортежей ``_path:dir_``[:``_target_``], где `_path_` — это имя исполняемого файла или файла, _dir_ — директория, в которой его следует искать, если он недоступен, а _target_ — цель, которую нужно вызвать в этой директории. Если _path_ начинается с косой черты (`/`), он считается файлом, и его существование проверяется с помощью `test -e`; в противном случае предполагается, что это исполняемый файл, и `which -s` используется для проверки наличия программы в пути поиска. Например, [.programlisting] .... -RUN_DEPENDS= ${LOCALBASE}/news/bin/innd:${PORTSDIR}/news/inn \ - xmlcatmgr:${PORTSDIR}/textproc/xmlcatmgr +RUN_DEPENDS= ${LOCALBASE}/news/bin/innd:news/inn \ + xmlcatmgr:textproc/xmlcatmgr .... -проверит существование файла или каталога [.filename]#/usr/local/news/bin/innd#, и если ничего не будет найдено, то построит и установит порт из подкаталога [.filename]#news/inn# дерева портов. Также будет выполнена проверка, присутствует ли в пути поиска исполняемый файл с именем `xmlcatmgr`, и перейдет в подкаталог [.filename]#textproc/xmlcatmgr# вашего дерева портов для его построения и установки, если он не будет найден. +проверит, существует ли файл или каталог [.filename]#/usr/local/news/bin/innd#, и соберет и установит его из подкаталога [.filename]#news/inn# дерева портов, если он не найден. Также будет проверено, находится ли исполняемый файл `xmlcatmgr` в пути поиска, и если он не найден, будет выполнен переход в [.filename]#textproc/xmlcatmgr# для сборки и установки. [NOTE] ==== -В приведенном примере `innd` является выполнимым файлом; если выполнимый файл находится в месте, которое отсутствует в списке путей файлов, то вы должны указать полный путь к файлу. +В этом случае `innd` является исполняемым файлом; если исполняемый файл находится в месте, которое не ожидается в пути поиска, используйте полный путь. ==== [NOTE] ==== -Официальным значением переменной поиска `PATH`, используемым в кластере построения портов является +Официальный путь поиска `PATH`, используемый в кластере сборки портов [.programlisting] .... @@ -1333,361 +3211,333 @@ RUN_DEPENDS= ${LOCALBASE}/news/bin/innd:${PORTSDIR}/news/inn \ ==== -Зависимость проверяется внутри цели `install`. Кроме того, имя зависимости помещается в пакет, так что `pkg install` (см. man:pkg-install[8]) будет автоматически его устанавливать, если он не будет найден в пользовательской системе. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET`. +Зависимость проверяется внутри цели `install`. Также имя зависимости добавляется в пакет, чтобы команда `pkg install` (см. man:pkg-install[8]) автоматически установила её, если она отсутствует в системе пользователя. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET`. -Довольно распространенной является ситуация, когда `RUN_DEPENDS` буквально такая же как `BUILD_DEPENDS`, особенно если переносимое программное обеспечение написано на языке сценариев, или если оно требует такое же окружение для исполнения, как и используемое во время построения. В этом случае, очень заманчивым или довольно естественным является присвоение одного другому: +Довольно распространённая ситуация, когда `RUN_DEPENDS` буквально совпадает с `BUILD_DEPENDS`, особенно если портируемое программное обеспечение написано на скриптовом языке или требует одинаковой среды для сборки и выполнения. В этом случае возникает соблазн и интуитивное желание напрямую присвоить одно другому: [.programlisting] .... RUN_DEPENDS= ${BUILD_DEPENDS} .... -Тем не менее, подобные присвоения могут загрязнять зависимости времени исполнения содержимым, не заданным в `BUILD_DEPENDS` исходного порта. Такое случается из-за ленивого вычисления в man:make[1] присваиваемых переменных. Представьте [.filename]#Makefile# с переменными `USE_*`, которые обрабатываются в [.filename]#ports/Mk/bsd.*.mk# для пополнения первоначальных зависимостей построения. Например, `USES= gmake` добавляет package:devel/gmake[] в `BUILD_DEPENDS`. Для предотвращения загрязнения `RUN_DEPENDS` подобными дополнительными зависимостями проявляйте осторожность с присвоением с раскрытием, т.е. с раскрытием значения перед его присвоением переменной: +Однако такое присваивание может загрязнить зависимости во время выполнения записями, не определёнными в оригинальном `BUILD_DEPENDS` порта. Это происходит из-за ленивого вычисления присваивания переменных в man:make[1]. Рассмотрим [.filename]#Makefile# с `USE_*`, которые обрабатываются [.filename]#ports/Mk/bsd.*.mk# для добавления начальных зависимостей сборки. Например, `USES= gmake` добавляет package:devel/gmake[] в `BUILD_DEPENDS`. Чтобы предотвратить попадание таких дополнительных зависимостей в `RUN_DEPENDS`, создайте другую переменную с текущим содержимым `BUILD_DEPENDS` и присвойте её как `BUILD_DEPENDS`, так и `RUN_DEPENDS`: [.programlisting] .... -RUN_DEPENDS:= ${BUILD_DEPENDS} +MY_DEPENDS= some:devel/some \ + other:lang/other +BUILD_DEPENDS= ${MY_DEPENDS} +RUN_DEPENDS= ${MY_DEPENDS} .... +[IMPORTANT] +==== +_Не используйте_ `:=` для присваивания `BUILD_DEPENDS` в `RUN_DEPENDS` или наоборот. Все переменные раскрываются немедленно, что является совершенно неправильным и почти всегда приводит к ошибке. +==== + +[[makefile-build_depends]] === `BUILD_DEPENDS` -В этой переменной перечисляются выполнимые или обычные файлы, которые требуются порту для его построения. Как и `RUN_DEPENDS`, это список пар path:dir:target. Например, +Эта переменная указывает исполняемые файлы или файлы, необходимые для сборки данного порта. Как и `RUN_DEPENDS`, это список кортежей ``_path:dir_``[:``_target_``]. Например, [.programlisting] .... -BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip +BUILD_DEPENDS= unzip:archivers/unzip .... -будет проверять наличие выполнимого фала с именем `unzip` и перейдет в подкаталог [.filename]#archivers/unzip# вашего дерева портов для его построения и установки, если последний не будет найден. +проверит наличие исполняемого файла с именем `unzip` и перейдет в подкаталог [.filename]#archivers/unzip# дерева портов, чтобы собрать и установить его, если он не будет найден. [NOTE] ==== -Под "построением" здесь понимается всё, от распаковки до компиляции. Зависимость проверяется из цели `extract`. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET`. +"build" здесь означает все процессы от извлечения до компиляции. Зависимость проверяется внутри цели `extract`. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET` ==== +[[makefile-fetch_depends]] === `FETCH_DEPENDS` -В этой переменной перечисляются выполняемые файлы или просто файлы, которые требуются порту для сгрузки. Как и предыдущие две переменные, это список пар path:dir:target. Например, +Эта переменная определяет исполняемые файлы или файлы, необходимые для загрузки этого порта. Как и предыдущие две, это список кортежей ``_path:dir_``[:``_target_``]. Например, [.programlisting] .... -FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 +FETCH_DEPENDS= ncftp2:net/ncftp2 .... -будет проверять наличие выполняемого файла с именем `ncftp2` и перейдет в каталог [.filename]#net/ncftp2# вашего дерева портов для его построения и установки, если тот не будет найден. +проверит наличие исполняемого файла с именем `ncftp2` и перейдет в подкаталог [.filename]#net/ncftp2# дерева портов для сборки и установки, если файл не будет найден. -Зависимость проверяется при выполнении цели `fetch`. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET`. +Зависимость проверяется внутри цели `fetch`. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET`. +[[makefile-extract_depends]] === `EXTRACT_DEPENDS` -В этой переменной указываются программы или файлы, которые требуются для распаковки порта. Как и в предыдущих случаях, это список пар вида path:dir:target. Например, +Эта переменная указывает исполняемые файлы или файлы, которые требуются для извлечения данного порта. Как и предыдущая, это список кортежей ``_path:dir_``[:``_target_``]. Например, [.programlisting] .... -EXTRACT_DEPENDS= unzip:${PORTSDIR}/archivers/unzip +EXTRACT_DEPENDS= unzip:archivers/unzip .... -будет проверять наличие программы с именем `unzip`, и перейдёт в подкаталог [.filename]#archivers/unzip# вашего дерева портов для её построения и установки, если такой программы не будет найдено. +проверит наличие исполняемого файла с именем `unzip` и перейдет в подкаталог [.filename]#archivers/unzip# дерева портов, чтобы собрать и установить его, если он не будет найден. Зависимость проверяется внутри цели `extract`. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET`. [NOTE] ==== -Используйте эту переменную, только если распаковка не работает (по умолчанию предполагается использование `gzip`) и это не исправляется при помощи `USE_ZIP` или `USE_BZIP2`, которые описаны в <<use-vars>>. +Используйте эту переменную только если извлечение уже не работает (по умолчанию предполагается `tar`) и не может быть исправлено с помощью `USES=tar`, `USES=lha` или `USES=zip`, как описано в crossref:uses[uses,Использование макросов `USES`]. ==== +[[makefile-patch_depends]] === `PATCH_DEPENDS` -Эта переменная указывает на программы или файлы, которые нужны порту для применения патчей. Как и в предыдущих случаях, это список пар вида path:dir:target. Например, +Эта переменная указывает исполняемые файлы или файлы, которые требуются этому порту для применения патчей. Как и предыдущая, это список кортежей ``_path:dir_``[:``_target_``]. Например, [.programlisting] .... -PATCH_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/java/jfc:extract +PATCH_DEPENDS= ${NONEXISTENT}:java/jfc:extract .... -будет переходить в подкаталог [.filename]#java/jfc# вашего дерева портов для распаковки. +будет спускаться в подкаталог [.filename]#java/jfc# дерева портов для его извлечения. -Зависимость проверяется внутри цели `patch`. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET`. +Зависимость проверяется в рамках цели `patch`. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET`. -[[uses-makefiles]] +[[makefile-uses]] === `USES` -Могут быть добавлены параметры для определения различных характерных особенностей и зависимостей, которыми обладает данный порт. Они указываются путём добавления в [.filename]#Makefile# этой строки: +Параметры могут быть добавлены для определения различных функций и зависимостей, используемых портом. Они указываются путем добавления этой строки в [.filename]#Makefile#: [.programlisting] .... USES= feature[:arguments] .... -Для получения полного списка значений смотрите <<uses-makefiles>>. +Для полного списка значений обратитесь к crossref:uses[uses,Использование макросов `USES`]. [WARNING] ==== - -Значение `USES` нельзя присваивать после подключения [.filename]#bsd.port.pre.mk#. +`USES` нельзя назначать после включения [.filename]#bsd.port.pre.mk#. ==== -[[use-vars]] +[[makefile-use-vars]] === `USE_*` -Для определения общих зависимостей, совместно используемых многими портами, предназначено несколько переменных. Их использование является необязательным, но помогает упростить избыточность файлов [.filename]#Makefile# порта. Каждый из них оформляется как `USE_*`. Эти переменные можно использовать только в [.filename]#Makefile# порта и [.filename]#ports/Mk/bsd.*.mk#. Они не предназначены для установки пользователями параметров - используйте для этих целей `PORT_OPTIONS`. +Существует несколько переменных для определения общих зависимостей, используемых многими портами. Их использование необязательно, но помогает сократить многословность [.filename]##Makefile## портов. Каждая из них оформлена как `USE_*`. Эти переменные могут использоваться только в [.filename]##Makefile## портов и [.filename]#ports/Mk/bsd.*.mk#. Они не предназначены для настраиваемых пользователем опций — для этой цели используйте `PORT_OPTIONS`. [NOTE] ==== -Установка любых `USE_*` в [.filename]#/etc/make.conf# _всегда_ является ошибочным действием. В частности, установка +Всегда неправильно устанавливать любые `USE_*` в [.filename]#/etc/make.conf#. Например, установка [.programlisting] .... USE_GCC=X.Y .... -(где X.Y соответствует версии) добавит зависимость от gccXY к каждому порту, включая и сам `lang/gccXY`! +(где X.Y — номер версии) добавит зависимость от gccXY для каждого порта, включая сам `lang/gccXY`! ==== -.Переменные `USE_*` +[[makefile-use-vars-table]] +.`USE_*` [cols="1,1", frame="none", options="header"] |=== | Переменная | Значение -|`USE_BZIP2` -|tar-архивы порта упакованы при помощи `bzip2`. +|`USE_GCC` +a| -|`USE_ZIP` -|tar-архивы порта упакованы при помощи `zip`. +Порт требует GCC (`gcc` или `{g-plus-plus}`) для сборки. +Некоторые порты нуждаются в определённой, старой версии GCC, другие требуют современных, актуальных версий. +Обычно устанавливается в `yes` (означает всегда использовать стабильную, современную версию GCC из портов, согласно `GCC_DEFAULT` в [.filename]#Mk/bsd.default-versions.mk#). +Это также значение по умолчанию. +Точная версия также может быть указана, например, значением `10`. +GCC из базовой системы используется, если он удовлетворяет запрашиваемой версии, в противном случае подходящий компилятор собирается из портов, а `CC` и `CXX` корректируются соответствующим образом. +Аргумент `:build`, следующий за указанием версии, добавляет только зависимость во время сборки порта. + +Например: +[example] +==== +[.programlisting] +.... +USE_GCC=yes # порт требует текущей версии GCC +USE_GCC=11:build # порт требует GCC 11 только во время сборки +.... +==== + +[NOTE] +==== +`USE_GCC=any` устарел и не должен использоваться в новых портах +==== -|`USE_GCC` -|Для сборки порта требуется GCC (gcc или {gcc-plus-plus}). Некоторым портам подходит любая версия, для других требуются последние современные версии. Обычно используется со значением `any` (в этом случае используется встроенный GCC в тех версиях FreeBSD, в состав которых он всё ещё входит, или устанавливается порт `lang/gcc`, когда Clang является компилятором C/C++ по умолчанию) или `yes` (всегда используется стабильная современная версия GCC из порта `lang/gcc`). Также в значении переменной можно указать точную версию, например `4.7`. Минимально допустимую версию можно указать как `4.6+`. GCC из основной системы используется в случае, если его версия удовлетворяет запрошенной, иначе собирается подходящая версии компилятора из порта с соответствующей коррекцией переменных `CC` и `CXX`. |=== -Переменные, относящиеся к gmake и сценарию [.filename]#configure#, описаны в crossref:special[building, Механизмы построения], а autoconf, automake и libtool описаны в crossref:special[using-autotools, Использование GNU Autotools]. Переменные, связанные с Perl, описаны в crossref:special[using-perl, Использование Perl]. Переменные X11 перечислены в crossref:special[using-x11, Использование X11]. crossref:special[using-gnome, Использование GNOME] работает с переменными GNOME и crossref:special[using-kde, Использование KDE] с KDE. crossref:special[using-java, Использование Java] описывает переменные Java, а crossref:special[using-php, Веб-приложения, Apache и PHP] содержит информацию об Apache, PHP и модулях PEAR. Python обсуждается в crossref:special[using-python, Использование Python], а Ruby в crossref:special[using-ruby, Использование Ruby]. crossref:special[using-sdl, Использование SDL] предоставляет переменные, используемые для приложений SDL, и, наконец, crossref:special[using-xfce, Использование Xfce] содержит информацию о приложении Xfce. +Переменные, связанные с gmake и [.filename]#configure#, описаны в crossref:special[building,Механизмы сборки], тогда как autoconf, automake и libtool описаны в crossref:special[using-autotools,Использование GNU Autotools]. Переменные, связанные с Perl, описаны в crossref:special[using-perl,Использование Perl]. Переменные X11 перечислены в crossref:special[using-x11,Использование X11]. crossref:special[using-gnome,Использование GNOME] посвящено GNOME, а crossref:special[using-kde,Использование KDE] — переменным, связанным с KDE. crossref:special[using-java,Использование Java] документирует переменные Java, тогда как crossref:special[using-php,Веб-приложения, Apache и PHP] содержит информацию о модулях Apache, PHP и PEAR. Python обсуждается в crossref:special[using-python,Использование Python], а Ruby — в crossref:special[using-ruby,Использование Ruby]. crossref:special[using-sdl,Использование SDL] предоставляет переменные, используемые для приложений SDL, и, наконец, crossref:special[using-xfce,Использование Xfce] содержит информацию о Xfce. -=== Минимальная версия зависимости +[[makefile-version-dependency]] +=== Минимальная версия зависимого пакета -Минимальная версия зависимости может быть указана в любой переменной `*_DEPENDS`, за исключением `LIB_DEPENDS`, с использованием следующего синтаксиса: +Минимальная версия зависимого пакета может быть указана в любом `*_DEPENDS`, кроме `LIB_DEPENDS`, используя следующий синтаксис: [.programlisting] .... -p5-Spiffy>=0.26:${PORTSDIR}/devel/p5-Spiffy +p5-Spiffy>=0.26:devel/p5-Spiffy .... -Первое поле содержит название зависимого пакета, которое обязано совпадать с записью в базе данные пакетов, знак сравнения и версию пакета. Зависимость удовлетворяется, если на машине установлен p5-Spiffy-0.26 или новее. +Первое поле содержит имя зависимого пакета, которое должно соответствовать записи в базе данных пакетов, знак сравнения и версию пакета. Зависимость считается удовлетворённой, если на машине установлен p5-Spiffy-0.26 или новее. -=== Замечания касательно зависимостей +[[makefile-note-on-dependencies]] +=== Заметки о зависимостях -Как уже отмечено выше, целью, которая вызывается по умолчанию в случае, когда это требует зависимость, является `DEPENDS_TARGET`. Она по умолчанию есть `install`. Это пользовательская переменная; она нигде не определена в файле [.filename]#Makefile# порта. Если вашему порту требуется особый метод обработки зависимости, воспользуйтесь частью `:target` переменной `*_DEPENDS` вместо того, чтобы переопределять `DEPENDS_TARGET`. +Как упомянуто выше, цель по умолчанию, вызываемая при необходимости зависимости, — это `DEPENDS_TARGET`. По умолчанию она установлена в `install`. Это пользовательская переменная; она никогда не определяется в [.filename]#Makefile# порта. Если порту требуется особый способ обработки зависимости, используйте часть `:target` в `*_DEPENDS` вместо переопределения `DEPENDS_TARGET`. -Когда вы набираете команду `make clean`, эта операция также выполняется и над зависимостями этого порта. Если вы не хотите, чтобы это случилось, определите переменную `NOCLEANDEPENDS` в вашем окружении. Это может быть особенно нужным, если порт имеет нечто, что занимает много времени на построение, в своём списке зависимостей, например, KDE, GNOME или Mozilla. +При выполнении `make clean` зависимости портов также автоматически очищаются. Если это нежелательно, определите переменную `NOCLEANDEPENDS` в окружении. Это может быть особенно полезно, если среди зависимостей порта есть что-то, что требует много времени для пересборки, например KDE, GNOME или Mozilla. -Чтобы безусловно зависеть от другого порта, укажите переменную `${NONEXISTENT}` в качестве первого поля переменной `BUILD_DEPENDS` или `RUN_DEPENDS`. Пользуйтесь этим, только когда вам нужно иметь исходный код другого порта. Вы можете сэкономить время на компиляции, указав также и цель. Например, +Для безусловной зависимости от другого порта используйте переменную `${NONEXISTENT}` в качестве первого поля `BUILD_DEPENDS` или `RUN_DEPENDS`. Используйте это только в случае, когда необходим исходный код другого порта. Время компиляции можно сократить, указав также цель. Например [.programlisting] .... -BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract +BUILD_DEPENDS= ${NONEXISTENT}:graphics/jpeg:extract .... -всегда будет переходить в каталог с портом `jpeg` и распаковывать его. +всегда будет переходить к порту `jpeg` и извлекать его. -=== Зацикленные зависимости фатальны +[[makefile-circular-dependencies]] +=== Циклические зависимости фатальны [IMPORTANT] ==== -Не помещайте зацикливающиеся зависимости в дерево портов! +Не создавайте циклических зависимостей в дереве портов! ==== -Технология построения портов не защищена от зацикленных зависимостей. Если вы создадите такую, то у кого-нибудь и где-нибудь установка FreeBSD будет немедленно сломана, а у остальных сломается несколько позже. Это на самом деле очень трудно распознать; если вы сомневаетесь, то перед внесением изменений проверьте, что выполнили следующее: `cd /usr/ports; make index`. Этот процесс может быть достаточно медленным на старых машинах, хотя вы сможете спасти большое количество людей-включая себя-от грядущих бед. +Технология сборки портов не допускает циклических зависимостей. Если такая зависимость будет добавлена, у кого-то в мире почти сразу окажется сломанной установка FreeBSD, а за этим последуют многие другие. Подобные проблемы бывает очень сложно обнаружить. Если есть сомнения, перед внесением изменений обязательно выполните: `cd /usr/ports; make index`. Этот процесс может быть довольно медленным на старых машинах, но он способен избавить множество людей, включая вас, от серьёзных проблем. -=== Автоматические зависимости и проблемы, которые они вызывают +[[makefile-automatic-dependencies]] +=== Проблемы, вызванные автоматическими зависимостями -Зависимости должны быть указаны либо явно, либо с использованием <<makefile-options,фреймворка OPTIONS>>. Использование прочих методов, таких как автоматическое обнаружение зависимостей, усложняет индексирование, что вызывает проблемы в управлении портами и пакетами. +Зависимости должны быть объявлены явно или с использованием crossref:makefiles[makefile-options,OPTIONS framework]. Использование других методов, таких как автоматическое обнаружение, усложняет индексацию, что вызывает проблемы для управления портами и пакетами. -.Некорректное объявление необязательной зависимости +[[makefile-automatic-dependencies-bad]] +.Неправильное объявление необязательной зависимости [example] ==== + [.programlisting] .... .include <bsd.port.pre.mk> .if exists(${LOCALBASE}/bin/foo) -LIB_DEPENDS= libbar.so:${PORTSDIR}/foo/bar +LIB_DEPENDS= libbar.so:foo/bar .endif .... ==== -Проблема автоматического добавления зависимостей заключается в том, что файлы и настройки за пределами порта могут произвольно меняться. Пример: после построения индекса устанавливается набор портов. При этом один из них устанавливает проверяемый файл. На этом этапе индекс будет неправильным, потому что установленный порт неожиданно получит новую зависимость. Индекс может быть по прежнему неправильным даже после его перестроения, в случае если другие порты также определят дополнительные зависимости, основываясь на существовании других файлов. +Проблема с попыткой автоматического добавления зависимостей заключается в том, что файлы и настройки за пределами отдельного порта могут измениться в любой момент. Например: индекс строится, затем устанавливается группа портов. Но один из портов устанавливает проверяемый файл. Теперь индекс неверен, потому что у установленного порта неожиданно появилась новая зависимость. Индекс может оставаться неверным даже после пересборки, если другие порты также определяют свою потребность в зависимостях на основе существования других файлов. -.Корректное объявление необязательной зависимости +[[makefile-automatic-dependencies-good]] +.Правильное объявление необязательной зависимости [example] ==== + [.programlisting] .... OPTIONS_DEFINE= BAR -BAR_DESC= Bar support +BAR_DESC= Calling cellphones via bar -.include <bsd.port.options.mk> - -.if ${PORT_OPTIONS:MBAR} -LIB_DEPENDS= libbar.so:${PORTSDIR}/foo/bar -.endif +BAR_LIB_DEPENDS= libbar.so:foo/bar .... ==== -Правильным способом является проверка переменных параметров. Этот способ не приводит к несоответствиям в индексе набора портов, поскольку параметры определены до построения индекса. При этом можно использовать простые скрипты для автоматизации построения, установки и обновления этих портов и соответствующих им пакетов. - -[[use-want]] -=== `USE_` и `WANT_` - -Переменные `USE_` задаются мейнтейнером порта для определения программного обеспечения, от которого этот порт зависит. Порт, для которого нужен Firefox, укажет - -[.programlisting] -.... -USE_FIREFOX= yes -.... - -Некоторые переменные `USE_` могут принимать номера версий или другие параметры. Например, порт, который требует Apache 2.2, укажет +Проверка переменных опций является правильным методом. Это не вызовет несоответствий в индексе группы портов, при условии что опции были определены до сборки индекса. Затем можно использовать простые скрипты для автоматизации сборки, установки и обновления этих портов и их пакетов. -[.programlisting] -.... -USE_APACHE= 22 -.... - -В некоторых случаях для большего контроля над зависимостями используются переменные `WANT_`, которые позволяют указывать требования в более точной форме. Например, взгляните на порт package:mail/squirrelmail[]. Этому порту нужны несколько модулей PHP, которые перечислены в переменной `USE_PHP`: +[[makefile-masterdir]] +== Подчиненные порты и `MASTERDIR` -[.programlisting] -.... -USE_PHP= session mhash gettext mbstring pcre openssl xml -.... +Если порту необходимо собирать немного разные версии пакетов, используя переменную (например, разрешение или размер бумаги) с разными значениями, создайте по одному подкаталогу для каждого пакета, чтобы пользователям было проще понять, что делать, но старайтесь максимально использовать общие файлы между портами. Обычно, при грамотном использовании переменных, во всех каталогах, кроме одного, требуется лишь очень короткий [.filename]#Makefile#. В единственном [.filename]#Makefile# укажите директорию с остальными файлами с помощью `MASTERDIR`. Также используйте переменную как часть crossref:makefiles[porting-pkgname,`PKGNAMESUFFIX`], чтобы пакеты имели разные имена. -Эти модули доступны в версиях CLI и web, поэтому версия web выбрана с переменной `WANT_`: +Это лучше всего продемонстрировать на примере. Это часть файла [.filename]#print/pkfonts300/Makefile#; [.programlisting] .... -WANT_PHP_WEB= yes -.... - -Имеющиеся переменные `USE_` и `WANT_` определены в файлах в [.filename]#/usr/ports/Mk#. - -[[makefile-masterdir]] -== `MASTERDIR` - -Если вашему порту требуется построение довольно различающихся версий пакетов через переменную (задающую, например, разрешение, или размер бумаги), которая принимает различные значения, создайте для каждого пакета отдельный подкаталог, чтобы пользователям было легче определить, каким пакетом воспользоваться, но попробуйте использовать совместно между портами как можно больше файлов. В типичном случае вам потребуются только очень короткие файлы [.filename]#Makefile# во всех каталогах, кроме одного, если вы будете использовать переменные с умом. В отдельных файлах [.filename]#Makefile# вы можете использовать переменную `MASTERDIR` для указания каталога, в котором находятся все остальные файлы. Также используйте переменную как часть <<porting-pkgname,`PKGNAMESUFFIX`>>, чтобы пакеты имели разные имена. +PORTNAME= pkfonts${RESOLUTION} +PORTVERSION= 1.0 +DISTFILES= pk${RESOLUTION}.tar.gz -Продемонстрируем это на примере. Вот часть файла [.filename]#japanese/xdvi300/Makefile#: +PLIST= ${PKGDIR}/pkg-plist.${RESOLUTION} -[.programlisting] -.... -PORTNAME= xdvi -PORTVERSION= 17 -PKGNAMEPREFIX= ja- -PKGNAMESUFFIX= ${RESOLUTION} - : -# default -RESOLUTION?= 300 +.if !defined(RESOLUTION) +RESOLUTION= 300 +.else .if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \ - ${RESOLUTION} != 300 && ${RESOLUTION} != 400 + ${RESOLUTION} != 300 && ${RESOLUTION} != 360 && \ + ${RESOLUTION} != 400 && ${RESOLUTION} != 600 +.BEGIN: @${ECHO_MSG} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\"" - @${ECHO_MSG} "Possible values are: 118, 240, 300 (default) and 400." + @${ECHO_MSG} "Possible values are: 118, 240, 300, 360, 400 and 600." @${FALSE} .endif +.endif .... -Порт package:japanese/xdvi300[] содержит также все обычные патчи, файлы для пакета и так далее. Если вы введете здесь команду `make`, она возьмет в качестве разрешения значение по умолчанию (300) и построит порт обычным образом. +Пакет `package:print/pkfonts300[]` также содержит все обычные исправления, файлы пакетов и т.д. При запуске `make` в этом месте будет взято значение разрешения по умолчанию (300), и порт будет собран в обычном режиме. -Для другого разрешения приведем _полный_[.filename]#xdvi118/Makefile#: +Что касается других разрешений, это _полный_ [.filename]#print/pkfonts360/Makefile#: [.programlisting] .... -RESOLUTION= 118 -MASTERDIR= ${.CURDIR}/../xdvi300 +RESOLUTION= 360 +MASTERDIR= ${.CURDIR}/../pkfonts300 -.include "${MASTERDIR}/Makefile" +.include "${MASTERDIR}/Makefile" .... -([.filename]#xdvi240/Makefile# и [.filename]#xdvi400/Makefile# похожи). Задание `MASTERDIR` говорит [.filename]#bsd.port.mk#, что обычный набор подкаталогов типа `FILESDIR` и `SCRIPTDIR` находится в каталоге [.filename]#xdvi300#. Строчка `RESOLUTION=118` переопределят строку `RESOLUTION=300` в файле [.filename]#xdvi300/Makefile# и порт будет построен с разрешением 118. +([.filename]#print/pkfonts118/Makefile#, [.filename]#print/pkfonts600/Makefile# и все остальные аналогичны). Определение `MASTERDIR` указывает [.filename]#bsd.port.mk#, что стандартный набор подкаталогов, таких как `FILESDIR` и `SCRIPTDIR`, следует искать в [.filename]#pkfonts300#. Строка `RESOLUTION=360` переопределит строку `RESOLUTION=300` в [.filename]#pkfonts300/Makefile#, и порт будет собран с разрешением, установленным на 360. [[makefile-manpages]] -== Страницы Справочника +== Страницы Cправочника -Если ваш порт определяет корнем для файлов Справочника каталог, отличный от `PREFIX`, вы можете использовать переменную `MANDIRS`, чтобы указать эти каталоги. Обратите внимание, что файлы страниц справочника следует размещать в [.filename]#pkg-plist# наряду с остальными файлами. `MANDIRS` предназначена для автоматического сжатия страниц справочника, так чтобы имена файлов оканчивались на [.filename]#.gz#. +Если порт размещает дерево man в другом месте, отличном от `PREFIX`, используйте `MANDIRS` для указания этих каталогов. Обратите внимание, что файлы, соответствующие страницам руководства, должны быть добавлены в [.filename]#pkg-plist# вместе с остальными файлами. Назначение `MANDIRS` — обеспечить автоматическое сжатие страниц руководства, поэтому имена файлов имеют суффикс [.filename]#.gz#. [[makefile-info]] -== Файлы в формате info +== Файлы информации -Если в вашем пакете нужна установка файлов GNU info, они должны быть перечислены в переменной `INFO` (без окончания `.info`), по записи на документ. Предполагается, что эти файлы устанавливаются в [.filename]#PREFIX/INFO_PATH#. Вы можете изменить `INFO_PATH`, если ваш пакет использует другое место для размещения. Однако, это не рекомендуется делать. Эти записи всего лишь содержат путь относительно [.filename]#PREFIX/INFO_PATH#. Например, package:lang/gcc34[] устанавливает файлы info в [.filename]#PREFIX/INFO_PATH/gcc34#, и в `INFO` будет что-то вроде этого: +Если пакету требуется установить файлы GNU info, перечислите их в `INFO` (без завершающего `.info`), по одному документу на строку. Предполагается, что эти файлы будут установлены в [.filename]#PREFIX/INFO_PATH#. Измените `INFO_PATH`, если пакет использует другое расположение. Однако это не рекомендуется. Эти записи содержат только путь относительно [.filename]#PREFIX/INFO_PATH#. Например, пакет package:lang/gcc34[] устанавливает файлы info в [.filename]#PREFIX/INFO_PATH/gcc34#, и `INFO` будет выглядеть примерно так: [.programlisting] .... INFO= gcc34/cpp gcc34/cppinternals gcc34/g77 ... .... -Перед регистрацией пакета соответствующий код установки/удаления будет автоматически добавлен во временный [.filename]#pkg-plist#. +Соответствующий код установки/удаления будет автоматически добавлен во временный файл [.filename]#pkg-plist# перед регистрацией пакета. [[makefile-options]] -== Опции для Makefile - -Многие приложения могут быть построены в различных конфигурациях и с дополнительной функциональностью. Например, выбор естественного (человеческого) языка, GUI против командной строки или типа используемой базы данных. Пользователи могут нуждаться в различных конфигурациях, отличных от используемой по умолчанию, поэтому в системе портов предусмотрен механизм, позволяющий автору порта управлять сборкой того или иного варианта конфигурации. Правильная поддержка этих необязательных параметров облегчает пользователям жизнь и даёт два или более порта по цене одного. - -=== Knobs +== Параметры Makefile -==== `WITH__*_` и `WITHOUT__*_` - -Эти переменные предназначены для установки системным администратором. Многие из них стандартизованы в файле http://svnweb.FreeBSD.org/ports/head/KNOBS?view=markup[ports/KNOBS]. - -При создании порта не давайте имя для knob, специфичное для данного приложения. На примере порта Avahi, используйте `WITHOUT_MDNS` вместо `WITHOUT_AVAHI_MDNS`. - -[NOTE] -==== -Не стоит рассчитывать, что `WITH__*_` обязательно имеет соответствующую переменную `WITHOUT__*_`, и наоборот. В общем случае, предполагается значение по умолчанию. -==== - -[NOTE] -==== -Если обратное не указано, то проверяется только факт установки самих переменных, но не их конкретное значение типа `YES` или `NO`. -==== - -.Основные переменные `WITH__*_` и `WITHOUT__*_` -[cols="1,1", frame="none", options="header"] -|=== -| Переменная -| Значение - -|`WITH_OPENSSL_BASE` -|Использовать версию OpenSSL из базовой системы. - -|`WITH_OPENSSL_PORT` -|Устанавливает версию OpenSSL из package:security/openssl[], даже если в базовой системе последняя версия. -|=== - -==== Наименование KNOBS - -Портеры должны использовать так называемые knobs для помощи конечным пользователям и для поддержания количества наименований knobs в небольшом количестве. Список популярных названий knobs можно найти в файле http://svnweb.FreeBSD.org/ports/head/KNOBS?view=markup[KNOBS] - -Названия knobs должны отражать, что это такое и что выполняет. Если у порта имеется библиотечный префикс в `PORTNAME`, то он должен присутствовать в названии knobs. +Многие приложения могут быть собраны с дополнительными или различными конфигурациями. Примеры включают выбор естественного (человеческого) языка, графический интерфейс или командная строка, тип поддерживаемой базы данных. Пользователям может потребоваться конфигурация, отличная от стандартной, поэтому система портов предоставляет хуки, которые автор порта может использовать для управления вариантом сборки. Правильная поддержка этих опций сделает пользователей счастливыми и эффективно предоставит два или более порта по цене одного. +[[makefile-options-options]] === `OPTIONS` -==== Описание +[[makefile-options-background]] +==== Пояснения -При установке порта переменные `OPTIONS_*` предоставляют пользователю окно диалога с отображением доступных параметров, с записью выбранных параметров в файл [.filename]#/var/db/ports/${UNIQUENAME}/options#. Эти опции повторно используются при следующем построении порта. +`OPTIONS_*` предоставляют пользователю, устанавливающему порт, диалоговое окно с доступными опциями, после чего сохраняют выбранные опции в [.filename]#${PORT_DBDIR}/${OPTIONS_NAME}/options#. При следующей сборке порта эти опции будут использованы повторно. `PORT_DBDIR` по умолчанию имеет значение [.filename]#/var/db/ports#. `OPTIONS_NAME` соответствует имени порта (origin) с заменой разделителя на подчёркивания, например, для package:dns/bind99[] это будет `dns_bind99`. -Когда пользователь запускает `make config` (или запускает впервые `make build`), инфраструктура выполняет проверку существования файла [.filename]#/var/db/ports/${UNIQUENAME}/options#. Если этот файл не существует, то используются значения `OPTIONS_*` и отображается диалоговое окно, в котором эти параметры можно включить или выключить. Затем сохраняется файл опций [.filename]#options#, и выбранные переменные используются при построении порта. +Когда пользователь запускает `make config` (или впервые запускает `make build`), система проверяет наличие файла [.filename]#${PORT_DBDIR}/${OPTIONS_NAME}/options#. Если этот файл не существует, используются значения `OPTIONS_*`, и отображается диалоговое окно, где можно включить или отключить опции. Затем файл [.filename]#options# сохраняется, а настроенные переменные используются при сборке порта. -Если новая версия порта добавляет новые значения `OPTIONS`, то пользователю будет представлено окно диалога с сохраненными заполненными значениями старых `OPTIONS.` +Если новая версия порта добавляет новые `OPTIONS`, пользователю будет показан диалог с сохранёнными значениями старых `OPTIONS`, заполненными заранее. -`make showconfig` отображает сохраненную конфигурацию. Для удаления сохраненной конфигурации используйте `make rmconfig`. +`make showconfig` показывает сохранённую конфигурацию. Используйте `make rmconfig` для удаления сохранённой конфигурации. +[[makefile-options-syntax]] ==== Синтаксис -`OPTIONS_DEFINE` содержит список используемых `OPTIONS`. Они независимы друг от друга и не сгруппированы: +`OPTIONS_DEFINE` содержит список `OPTIONS`, которые будут использоваться. Они независимы друг от друга и не сгруппированы: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 .... -Далее после определения следует описание `OPTIONS` (не является обязательным, но настоятельно рекомендуется): +После определения `OPTIONS` описываются (необязательно, но настоятельно рекомендуется): [.programlisting] .... @@ -1699,19 +3549,19 @@ OPT5_DESC= Describe OPT5 OPT6_DESC= Describe OPT6 .... +[.filename]#ports/Mk/bsd.options.desc.mk# содержит описания для многих распространённых `OPTIONS`. Хотя они часто полезны, переопределите их, если описание недостаточно для порта. + [TIP] ==== - -[.filename]#ports/Mk/bsd.options.desc.mk# содержит описание множества наиболее используемых `OPTIONS`; переопределять их, как правило, не нужно. +При описании параметров рассматривайте их с точки зрения пользователя: «Какую функциональность это изменяет?» и «Зачем мне включать этот параметр?» Не просто повторяйте название. Например, описание параметра `NLS` как «включить поддержку NLS» не помогает пользователю, который уже видит название параметра, но может не знать, что оно означает. Описание вроде «Поддержка родного языка с помощью утилиты gettext» гораздо полезнее. ==== -[TIP] +[IMPORTANT] ==== - -При описании параметров старайтесь представить себя на месте пользователя: "Что это делает?" и "Для чего бы я захотел включить это?" Не делайте простое повторение названия. Например, описание параметра `NLS` как "include NLS support" ("включить поддержку NLS") не поможет пользователю, который уже видит название параметра, но может не знать, что это означает. Описав его как "Native Language Support via gettext utilities" ("Поддержка национального языка через утилиты gettext"), вы поможете пользователю гораздо больше. +Названия параметров всегда пишутся в верхнем регистре. Они не могут использовать смешанный регистр или нижний регистр. ==== -`OPTIONS` можно группировать в виде переключателей, для которых разрешен выбор единственного варианта в каждой группе: +`OPTIONS` могут быть сгруппированы как переключаемые варианты, где допускается только один выбор из каждой группы: [.programlisting] .... @@ -1719,7 +3569,12 @@ OPTIONS_SINGLE= SG1 OPTIONS_SINGLE_SG1= OPT3 OPT4 .... -`OPTIONS` можно группировать в виде переключателей, для которых разрешен выбор единственного варианта (или ни одного) в каждой группе: +[WARNING] +==== +В каждый момент времени _должна_ быть выбрана одна опция из каждой группы `OPTIONS_SINGLE`, чтобы параметры были действительными. Один вариант из каждой группы _должен_ быть добавлен в `OPTIONS_DEFAULT`. +==== + +`OPTIONS` могут быть сгруппированы как переключаемые варианты, где ни один или только один вариант из каждой группы разрешён: [.programlisting] .... @@ -1727,7 +3582,7 @@ OPTIONS_RADIO= RG1 OPTIONS_RADIO_RG1= OPT7 OPT8 .... -`OPTIONS` также можно группировать в виде списков со множественным выбором, для которых обязан быть включен _по крайней мере один_ из параметров: +`OPTIONS` также могут быть сгруппированы в виде списков "множественного выбора", где _хотя бы одна_ опция должна быть включена: [.programlisting] .... @@ -1735,7 +3590,7 @@ OPTIONS_MULTI= MG1 OPTIONS_MULTI_MG1= OPT5 OPT6 .... -`OPTIONS` также можно группировать в виде списков со множественным выбором, для которых могут быть включены любые параметры, включая отсутствие выбора: +`OPTIONS` также могут быть сгруппированы в виде списков "множественного выбора", где ни одна или любые опции могут быть включены: [.programlisting] .... @@ -1743,36 +3598,31 @@ OPTIONS_GROUP= GG1 OPTIONS_GROUP_GG1= OPT9 OPT10 .... -По умолчанию `OPTIONS` находится в выключенном положении, если при этом оно также отсутствует в списке `OPTIONS_DEFAULT`: +`OPTIONS` по умолчанию не установлены, если они не перечислены в `OPTIONS_DEFAULT`: [.programlisting] .... OPTIONS_DEFAULT= OPT1 OPT3 OPT6 .... -Определения `OPTIONS` обязаны быть до подключения [.filename]#bsd.port.options.mk#. Переменные `PORT_OPTIONS` могут быть проверены только после подключения [.filename]#bsd.port.options.mk#. Вместо этого также можно использовать подключение [.filename]#bsd.port.pre.mk#, что все еще широко используется в портах, написанных до появления [.filename]#bsd.port.options.mk#. Но имейте в виду, что некоторые переменные, обычно, это некоторые флаги `USE_*`, после подключения [.filename]#bsd.port.pre.mk# будут работать не так, как этого от них ожидают. +Определения `OPTIONS` должны быть указаны до включения файла [.filename]#bsd.port.options.mk#. Значения `PORT_OPTIONS` можно проверять только после включения [.filename]#bsd.port.options.mk#. Включение [.filename]#bsd.port.pre.mk# также может использоваться и до сих пор широко применяется в портах, написанных до введения [.filename]#bsd.port.options.mk#. Однако следует учитывать, что некоторые переменные не будут работать как ожидается после включения [.filename]#bsd.port.pre.mk#, обычно это некоторые флаги `USE_*`. [[ports-options-simple-use]] .Простое использование `OPTIONS` [example] ==== + [.programlisting] .... OPTIONS_DEFINE= FOO BAR -FOO_DESC= Enable option foo -BAR_DESC= Support feature bar - -.include <bsd.port.options.mk> +OPTIONS_DEFAULT=FOO -.if ${PORT_OPTIONS:MFOO} -CONFIGURE_ARGS+=--with-foo -.else -CONFIGURE_ARGS+=--without-foo -.endif +FOO_DESC= Option foo support +BAR_DESC= Feature bar support -.if ${PORT_OPTIONS:MBAR} -RUN_DEPENDS+= bar:${PORTSDIR}/bar/bar -.endif +# Will add --with-foo / --without-foo +FOO_CONFIGURE_WITH= foo +BAR_RUN_DEPENDS= bar:bar/bar .include <bsd.port.mk> .... @@ -1780,9 +3630,10 @@ RUN_DEPENDS+= bar:${PORTSDIR}/bar/bar ==== [[ports-options-check-unset]] -.Проверка незаданных значений `OPTIONS` +.Проверка неустановленных `OPTIONS` порта [example] ==== + [.programlisting] .... .if ! ${PORT_OPTIONS:MEXAMPLES} @@ -1790,15 +3641,25 @@ CONFIGURE_ARGS+=--without-examples .endif .... +Приведённая выше форма не рекомендуется. Предпочтительный метод — использование параметра configure для фактического включения и отключения функции в соответствии с опцией: + +[.programlisting] +.... +# Will add --with-examples / --without-examples +EXAMPLES_CONFIGURE_WITH= examples +.... + ==== [[ports-options-practical-use]] .Пример реального использования `OPTIONS` [example] ==== + [.programlisting] .... OPTIONS_DEFINE= EXAMPLES +OPTIONS_DEFAULT= PGSQL LDAP SSL OPTIONS_SINGLE= BACKEND OPTIONS_SINGLE_BACKEND= MYSQL PGSQL BDB @@ -1814,100 +3675,150 @@ LDAP_DESC= Build with LDAP authentication support PAM_DESC= Build with PAM support SSL_DESC= Build with OpenSSL support -OPTIONS_DEFAULT= PGSQL LDAP SSL - -.include <bsd.port.options.mk> - -.if ${PORT_OPTIONS:MPGSQL} -USE_PGSQL= yes -CONFIGURE_ARGS+= --with-postgres -.else -CONFIGURE_ARGS+= --without-postgres -.endif +# Will add USE_PGSQL=yes +PGSQL_USE= pgsql=yes +# Will add --enable-postgres / --disable-postgres +PGSQL_CONFIGURE_ENABLE= postgres -.if ${PORT_OPTIONS:MICU} -LIB_DEPENDS+= libicuuc.so:${PORTSDIR}/devel/icu -.endif +ICU_LIB_DEPENDS= libicuuc.so:devel/icu -.if ! ${PORT_OPTIONS:MEXAMPLES} -CONFIGURE_ARGS+= --without-examples -.endif +# Will add --with-examples / --without-examples +EXAMPLES_CONFIGURE_WITH= examples -# Проверка других параметров OPTIONS +# Check other OPTIONS .include <bsd.port.mk> .... ==== -==== Параметры по умолчанию +[[makefile-options-default]] +==== Опции по умолчанию -Следующие параметры по умолчанию всегда включены. +Эти опции всегда включены по умолчанию. -* `DOCS` - построение и установка документации. -* `NLS` - интернационализация. -* `EXAMPLES` - построение и установка примеров использования. -* `IPV6` - поддержка протокола IPv6. +* `DOCS` — сборка и установка документации. +* `NLS` — Поддержка родного языка. +* `EXAMPLES` — сборка и установка примеров. +* `IPV6` — Поддержка протокола IPv6. [NOTE] ==== -Нет необходимости добавлять эти параметры в `OPTIONS_DEFAULT`. Тем не менее, чтобы отобразить их в окне диалога выбора параметров, они должны быть добавлены в `OPTIONS_DEFINE`. +Нет необходимости добавлять их в `OPTIONS_DEFAULT`. Однако, чтобы они были активны и отображались в диалоге выбора опций, их необходимо добавить в `OPTIONS_DEFINE`. ==== -=== Функция автоматической активации +[[makefile-options-auto-activation]] +=== Автоматическая активация функций -При использовании сценария GNU configure, следите за тем, какие необязательные функции задействуются посредством автоматической активации. Отключайте явным образом те необязательные функции, которые вы не хотели бы использовать, через передачу соответствующих `--without-xxx` или `--disable-xxx` в переменной `CONFIGURE_ARGS`. +При использовании скрипта GNU configure следите за тем, какие дополнительные функции активируются автоматическим определением. Явно отключите ненужные дополнительные функции, добавив `--without-xxx` или `--disable-xxx` в `CONFIGURE_ARGS`. -.Неправильное управление опцией +[[makefile-options-auto-activation-bad]] +.Неправильная обработка опции [example] ==== + [.programlisting] .... .if ${PORT_OPTIONS:MFOO} -LIB_DEPENDS+= libfoo.so:${PORTSDIR}/devel/foo +LIB_DEPENDS+= libfoo.so:devel/foo CONFIGURE_ARGS+= --enable-foo .endif .... ==== -В приведенном выше примере представьте себе библиотеку libfoo, установленную в системе. Пользователь не желает, чтобы приложение использовало libfoo, и поэтому он выключает соответствующую опцию в диалоге `make config`. Но сценарий configure приложения определяет наличие библиотеки в системе и включает ее поддержку в итоговый исполняемый файл. Теперь, когда пользователь решит удалить libfoo из системы, система портов позволит это сделать (т.к. зависимость от libfoo не была записана), но приложение перестанет работать. +В приведённом выше примере представьте, что библиотека libfoo установлена в системе. Пользователь не хочет, чтобы это приложение использовало libfoo, поэтому он отключил соответствующую опцию в диалоге `make config`. Однако скрипт configure приложения обнаруживает библиотеку в системе и включает её поддержку в итоговом исполняемом файле. Теперь, когда пользователь решает удалить libfoo из системы, система портов не протестует (зависимость от libfoo не была записана), но приложение перестаёт работать. -.Правильное управление опцией +[[makefile-options-auto-activation-good]] +.Правильная обработка опции [example] ==== + [.programlisting] .... -.if ${PORT_OPTIONS:MFOO} -LIB_DEPENDS+= libfoo.so:${PORTSDIR}/devel/foo -CONFIGURE_ARGS+= --enable-foo -.else -CONFIGURE_ARGS+= --disable-foo -.endif +FOO_LIB_DEPENDS= libfoo.so:devel/foo +# Will add --enable-foo / --disable-foo +FOO_CONFIGURE_ENABLE= foo .... ==== -Во втором примере библиотека libfoo отключена явным образом. Сценарий configure не включает соответствующие функции в приложении, несмотря на присутствие библиотеки в системе. - [NOTE] ==== -При определенных условиях сокращенный синтаксис записи условий может вызывать проблемы со сложными конструкциями. Если вы получаете ошибки, такие как `Malformed conditional`, то может быть использован альтернативный синтаксис. +В некоторых случаях сокращенный синтаксис условных выражений может вызывать проблемы со сложными конструкциями. Ошибки обычно имеют вид `Malformed conditional`, тогда можно использовать альтернативный синтаксис. [.programlisting] .... .if !empty(VARIABLE:MVALUE) -# as an alternative to +.... + +в качестве альтернативы + +[.programlisting] +.... .if ${VARIABLE:MVALUE} .... ==== -=== Вспомогательные макросы +[[options-helpers]] +=== Помощники параметров + +Существуют макросы, которые помогают упростить условные значения, различающиеся в зависимости от установленных опций. Для удобства приведён полный список: + +`PLIST_SUB`, `SUB_LIST`:: +Для автоматической генерации `%%_OPT_%%` и `%%NO__OPT__%%` см. crossref:makefiles[options_sub, `OPTIONS_SUB`]. ++ +Для более сложных случаев использования см. crossref:makefiles[options-variables, Замена общих переменных, `OPT_VARIABLE` и `OPT_VARIABLE_OFF`]. + +`CONFIGURE_ARGS`:: +Для информации о `--enable-_x_` и `--disable-_x_` см. crossref:makefiles[options-configure_enable, `OPT_CONFIGURE_ENABLE`]. ++ +О `--with-_x_` и `--without-_x_` см. crossref:makefiles[options-configure_with, `OPT_CONFIGURE_WITH`]. ++ +Во всех остальных случаях см. crossref:makefiles[options-configure_on, `OPT_CONFIGURE_ON` и `OPT_CONFIGURE_OFF`]. + +`CMAKE_ARGS`:: +Для аргументов, которые являются булевыми значениями (`on`, `off`, `true`, `false`, `0`, `1`), см. crossref:makefiles[options-cmake_bool, `OPT_CMAKE_BOOL` и `OPT_CMAKE_BOOL_OFF`]. ++ +Для всех остальных случаев см. crossref:makefiles[options-cmake_on, `OPT_CMAKE_ON` и `OPT_CMAKE_OFF`]. + +`MESON_ARGS`:: +Для аргументов, принимающих `true` или `false`, см. crossref:makefiles[options-meson_true, `OPT_MESON_TRUE` и `OPT_MESON_FALSE`]. ++ +Для аргументов, принимающих `yes` или `no`, используйте crossref:makefiles[options-meson_yes, `OPT_MESON_YES` и `OPT_MESON_NO`]. ++ +Для аргументов, принимающих `enabled` или `disabled`, см. crossref:makefiles[options-meson_enabled, `OPT_MESON_ENABLED` и `OPT_MESON_DISABLED`]. ++ +Во всех остальных случаях используйте crossref:makefiles[options-meson_on, `OPT_MESON_ON` и `OPT_MESON_OFF`]. + +`QMAKE_ARGS`:: +См. crossref:makefiles[options-qmake_on, `OPT_QMAKE_ON` и `OPT_QMAKE_OFF`]. + +`USE_*`:: +См. crossref:makefiles[options-use, `OPT_USE` и `OPT_USE_OFF`]. -Существует несколько макросов, упрощающих запись условных значений, которые отличаются в зависимости от набора параметров. +`*_DEPENDS`:: +См. crossref:makefiles[options-dependencies, Зависимости, `OPT_DEPTYPE` и `OPT_DEPTYPE_OFF`]. -Если переменная `OPTIONS_SUB` имеет значение `yes`, то каждый из указанных в `OPTIONS_DEFINE` параметров будет добавлен в `PLIST_SUB`. Следующая запись: +`*` (Любая переменная):: +Наиболее используемые переменные имеют своих помощников, см. crossref:makefiles[options-variables, Замена Общих Переменных, `OPT_VARIABLE` и `OPT_VARIABLE_OFF`]. ++ +Для любой переменной без специального помощника см. crossref:makefiles[options-vars, `OPT_VARS` и `OPT_VARS_OFF`]. + +Зависимости параметров:: +Когда для работы опции требуется другая опция, см. crossref:makefiles[options-implies, `OPT_IMPLIES`]. + +Конфликты опций:: +Когда опция не может работать, если включена другая, см. crossref:makefiles[options-prevents, `OPT_PREVENTS` и `OPT_PREVENTS_MSG`]. + +Цели сборки:: +Когда для опции требуется дополнительная обработка, см. crossref:makefiles[options-targets, Дополнительные цели сборки, `_target_-_OPT_-on` и `_target_-_OPT_-off`]. + +[[options_sub]] +==== `OPTIONS_SUB` + +Если `OPTIONS_SUB` установлен в `yes`, то каждая из опций, добавленных в `OPTIONS_DEFINE`, будет добавлена в `PLIST_SUB` и `SUB_LIST`, например: [.programlisting] .... @@ -1915,7 +3826,7 @@ OPTIONS_DEFINE= OPT1 OPTIONS_SUB= yes .... -соответствует: +эквивалентно: [.programlisting] .... @@ -1924,21 +3835,33 @@ OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} -PLIST_SUB+= OPT1="" +PLIST_SUB+= OPT1="" NO_OPT1="@comment " +SUB_LIST+= OPT1="" NO_OPT1="@comment " .else -PLIST_SUB+= OPT1="@comment " +PLIST_SUB+= OPT1="@comment " NO_OPT1="" +SUB_LIST+= OPT1="@comment " NO_OPT1="" .endif .... -`X_CONFIGURE_ENABLE` дописывает в `CONFIGURE_ARGS` строку `--enable-${X_CONFIGURE_ENABLE}` или `--disable-${X_CONFIGURE_ENABLE}` в соответствии с состоянием `X`. Следующая запись: +[NOTE] +==== +Значение `OPTIONS_SUB` игнорируется. Установка любого значения добавит записи `PLIST_SUB` и `SUB_LIST` для _всех_ опций. +==== + +[[options-use]] +==== `OPT_USE` и `OPT_USE_OFF` + +Когда выбрана опция _OPT_, для каждой пары `_ключ=значение_` в ``OPT_USE``, _значение_ добавляется к соответствующему `USE_KEY`. Если _значение_ содержит пробелы, замените их запятыми, и они будут преобразованы обратно в пробелы во время обработки. `OPT_USE_OFF` работает аналогично, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 -OPT1_CONFIGURE_ENABLE= test +OPT1_USES= xorg +OPT1_USE= mysql=yes xorg=x11,xextproto,xext,xrandr +OPT1_USE_OFF= openssl=yes .... -соответствует: +эквивалентно: [.programlisting] .... @@ -1947,21 +3870,30 @@ OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} -CONFIGURE_ARGS+= --enable-test +USE_MYSQL= yes +USES+= xorg +USE_XORG= x11 xextproto xext xrandr .else -CONFIGURE_ARGS+= --disable-test +USE_OPENSSL= yes .endif .... -`X_CONFIGURE_WITH` дописывает в `CONFIGURE_ARGS` строку `--with-${X_CONFIGURE_WITH}` или `--without-${X_CONFIGURE_WITH}` в соответствии с состоянием `X`. Следующая запись: +[[options-configure-helpers]] +==== Помощники `CONFIGURE_ARGS` + +[[options-configure_enable]] +===== `OPT_CONFIGURE_ENABLE` + +Когда выбрана опция _OPT_, для каждого _элемента_ в `OPT_CONFIGURE_ENABLE` к `CONFIGURE_ARGS` добавляется `--enable-_элемент_`. Если опция _OPT_ _не_ выбрана, к `CONFIGURE_ARGS` добавляется `--disable-_элемент_`. Необязательный аргумент может быть указан с помощью символа `=`. Этот аргумент добавляется только к опции конфигурации `--enable-_элемент_`. Например: [.programlisting] .... -OPTIONS_DEFINE= OPT1 -OPT1_CONFIGURE_WITH= test +OPTIONS_DEFINE= OPT1 OPT2 +OPT1_CONFIGURE_ENABLE= test1 test2 +OPT2_CONFIGURE_ENABLE= test2=exhaustive .... -соответствует: +эквивалентно: [.programlisting] .... @@ -1970,21 +3902,64 @@ OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} -CONFIGURE_ARGS+= --with-test +CONFIGURE_ARGS+= --enable-test1 --enable-test2 +.else +CONFIGURE_ARGS+= --disable-test1 --disable-test2 +.endif + +.if ${PORT_OPTIONS:MOPT2} +CONFIGURE_ARGS+= --enable-test2=exhaustive +.else +CONFIGURE_ARGS+= --disable-test2 +.endif +.... + +[[options-configure_with]] +===== `OPT_CONFIGURE_WITH` + +Когда выбрана опция _OPT_, для каждого _элемента_ в `_OPT_CONFIGURE_WITH` к `CONFIGURE_ARGS` добавляется `--with-_элемент_`. Если опция _OPT_ _не_ выбрана, к `CONFIGURE_ARGS` добавляется `--without-_элемент_`. Необязательный аргумент можно указать с помощью символа `=`. Этот аргумент добавляется только к опции конфигурации `--with-_элемент_`. Например: + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 OPT2 +OPT1_CONFIGURE_WITH= test1 +OPT2_CONFIGURE_WITH= test2=exhaustive +.... + +эквивалентно: + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 OPT2 + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT1} +CONFIGURE_ARGS+= --with-test1 +.else +CONFIGURE_ARGS+= --without-test1 +.endif + +.if ${PORT_OPTIONS:MOPT2} +CONFIGURE_ARGS+= --with-test2=exhaustive .else -CONFIGURE_ARGS+= --without-test +CONFIGURE_ARGS+= --without-test2 .endif .... -Значение переменной `X_CONFIGURE_ON` будет дописано в `CONFIGURE_ARGS` в соответствии с состоянием `X`. Следующая запись: +[[options-configure_on]] +===== `OPT_CONFIGURE_ON` и `OPT_CONFIGURE_OFF` + +Когда выбрана опция _OPT_, значение `OPT_CONFIGURE_ON`, если оно определено, добавляется к `CONFIGURE_ARGS`. `OPT_CONFIGURE_OFF` работает аналогично, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_CONFIGURE_ON= --add-test +OPT1_CONFIGURE_OFF= --no-test .... -соответствует: +эквивалентно: [.programlisting] .... @@ -1994,37 +3969,65 @@ OPTIONS_DEFINE= OPT1 .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --add-test +.else +CONFIGURE_ARGS+= --no-test .endif .... -Значение переменной `X_CONFIGURE_OFF` будет дописано в `CONFIGURE_ARGS` в соответствии с состоянием `X`. Следующая запись: +[TIP] +==== +В большинстве случаев помощники crossref:makefiles[options-configure_enable, `OPT_CONFIGURE_ENABLE`] и crossref:makefiles[options-configure_with, `OPT_CONFIGURE_WITH`] предоставляют более короткий и понятный функционал. +==== + +[[options-cmake-helpers]] +==== Помощники `CMAKE_ARGS` + +[[options-cmake_on]] +===== `OPT_CMAKE_ON` и `OPT_CMAKE_OFF` + +Когда выбрана опция _OPT_, значение `OPT_CMAKE_ON`, если оно определено, добавляется к `CMAKE_ARGS`. `OPT_CMAKE_OFF` работает аналогично, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 -OPT1_CONFIGURE_OFF= --no-test +OPT1_CMAKE_ON= -DTEST:BOOL=true -DDEBUG:BOOL=true +OPT1_CMAKE_OFF= -DOPTIMIZE:BOOL=true .... -соответствует: +эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 + .include <bsd.port.options.mk> -.if ! ${PORT_OPTIONS:MOPT1} -CONFIGURE_ARGS+= --no-test + +.if ${PORT_OPTIONS:MOPT1} +CMAKE_ARGS+= -DTEST:BOOL=true -DDEBUG:BOOL=true +.else +CMAKE_ARGS+= -DOPTIMIZE:BOOL=true .endif .... -Значение переменной `X_CMAKE_ON` будет дописано в `CMAKE_ARGS` в соответствии с состоянием `X`. Следующая запись: +[TIP] +==== + +См. crossref:makefiles[options-cmake_bool, `OPT_CMAKE_BOOL` и `OPT_CMAKE_BOOL_OFF`] для более краткой записи, когда значение является булевым. +==== + +[[options-cmake_bool]] +===== `OPT_CMAKE_BOOL` и `OPT_CMAKE_BOOL_OFF` + +Когда выбрана опция _OPT_, для каждого _элемента_ в `OPT_CMAKE_BOOL` добавляется `-D_элемент_:BOOL=true` к `CMAKE_ARGS`. Если опция _OPT_ _не_ выбрана, `-D_элемент_:BOOL=false` добавляется к `CONFIGURE_ARGS`. `OPT_CMAKE_BOOL_OFF` работает наоборот: `-D_элемент_:BOOL=false` добавляется к `CMAKE_ARGS`, когда опция выбрана, и `-D_элемент_:BOOL=true`, когда опция _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 -OPT1_CMAKE_ON= -DTEST:BOOL=true +OPT1_CMAKE_BOOL= TEST DEBUG +OPT1_CMAKE_BOOL_OFF= OPTIMIZE .... -соответствует: +эквивалентно: [.programlisting] .... @@ -2033,19 +4036,30 @@ OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} -CMAKE_ARGS+= -DTEST:BOOL=true +CMAKE_ARGS+= -DTEST:BOOL=true -DDEBUG:BOOL=true \ + -DOPTIMIZE:BOOL=false +.else +CMAKE_ARGS+= -DTEST:BOOL=false -DDEBUG:BOOL=false \ + -DOPTIMIZE:BOOL=true .endif .... -Значение переменной `X_CMAKE_OFF` будет дописано в `CMAKE_ARGS` в соответствии с состоянием `X`. Следующая запись: +[[options-meson-helpers]] +==== Помощники `MESON_ARGS` + +[[options-meson_on]] +===== `OPT_MESON_ON` и `OPT_MESON_OFF` + +Когда выбрана опция _OPT_, значение `OPT_MESON_ON`, если оно определено, добавляется к `MESON_ARGS`. `OPT_MESON_OFF` работает аналогичным образом, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 -OPT1_CMAKE_OFF= -DTEST:BOOL=false +OPT1_MESON_ON= -Dopt=1 +OPT1_MESON_OFF= -Dopt=2 .... -соответствует: +эквивалентно: [.programlisting] .... @@ -2053,42 +4067,55 @@ OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> -.if ! ${PORT_OPTIONS:MOPT1} -CMAKE_ARGS+= -DTEST:BOOL=false +.if ${PORT_OPTIONS:MOPT1} +MESON_ARGS+= -Dopt=1 +.else +MESON_ARGS+= -Dopt=2 .endif .... -Для любой из следующих переменных: +[[options-meson_true]] +===== `OPT_MESON_TRUE` и `OPT_MESON_FALSE` -* `ALL_TARGET` -* `CATEGORIES` -* `CFLAGS` -* `CPPFLAGS` -* `CXXFLAGS` -* `CONFIGURE_ENV` -* `DISTFILES` -* `EXTRA_PATCHES` -* `INSTALL_TARGET` -* `LDFLAGS` -* `MAKE_ARGS` -* `MAKE_ENV` -* `PATCH_SITES` -* `PATCHFILES` -* `PLIST_FILES` -* `PLIST_DIRS` -* `PLIST_DIRSTRY` -* `USES` +Когда выбрана опция _OPT_, для каждого _элемента_ в `OPT_MESON_TRUE` добавляется `-D_элемент_=true` в `MESON_ARGS`. Если опция _OPT_ _не_ выбрана, добавляется `-D_элемент_=false` в `MESON_ARGS`. `OPT_MESON_FALSE` работает противоположным образом: `-D_элемент_=false` добавляется в `MESON_ARGS`, когда опция выбрана, и `-D_элемент_=true`, когда опция _не_ выбрана. Например: + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 +OPT1_MESON_TRUE= test debug +OPT1_MESON_FALSE= optimize +.... -Значение переменной `X_ABOVEVARIABLE` будет дописано в `ABOVEVARIABLE` в соответствии с состоянием `X`. Следующая запись: +эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 -OPT1_USES= gmake -OPT1_CFLAGS= -DTEST + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT1} +MESON_ARGS+= -Dtest=true -Ddebug=true \ + -Doptimize=false +.else +MESON_ARGS+= -Dtest=false -Ddebug=false \ + -Doptimize=true +.endif +.... + +[[options-meson_yes]] +===== `OPT_MESON_YES` и `OPT_MESON_NO` + +Когда выбрана опция _OPT_, для каждого _элемента_ в `OPT_MESON_YES` добавляется `-D_элемент_=yes` к `MESON_ARGS`. Если опция _OPT_ _не_ выбрана, добавляется `-D_элемент_=no` к `MESON_ARGS`. `OPT_MESON_NO` работает противоположным образом: `-D_элемент_=no` добавляется к `MESON_ARGS`, когда опция выбрана, и `-D_элемент_=yes`, когда опция _не_ выбрана. Например: + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 +OPT1_MESON_YES= test debug +OPT1_MESON_NO= optimize .... -соответствует: +эквивалентно: [.programlisting] .... @@ -2097,20 +4124,54 @@ OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} -USES+= gmake -CFLAGS+= -DTEST +MESON_ARGS+= -Dtest=yes -Ddebug=yes \ + -Doptimize=no +.else +MESON_ARGS+= -Dtest=no -Ddebug=no \ + -Doptimize=yes +.endif +.... + +[[options-meson_enabled]] +===== `OPT_MESON_ENABLED` и `OPT_MESON_DISABLED` + +Когда выбрана опция _OPT_, для каждого _элемента_ в `OPT_MESON_ENABLED` добавляется `-D_элемент_=enabled` к `MESON_ARGS`. Когда опция _OPT_ _не_ выбрана, добавляется `-D_элемент_=disabled` к `MESON_ARGS`. `OPT_MESON_DISABLED` работает противоположным образом: `-D_элемент_=disabled` добавляется к `MESON_ARGS`, когда опция выбрана, и `-D_элемент_=enabled`, когда опция _не_ выбрана. Например: + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 +OPT1_MESON_ENABLED= test +OPT1_MESON_DISABLED= debug +.... + +эквивалентно: + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT1} +MESON_ARGS+= -Dtest=enabled -Ddebug=disabled +.else +MESON_ARGS+= -Dtest=disabled -Ddebug=enabled .endif .... -Если установлена `X_ABOVEVARIABLE_OFF`, то флаг `ABOVEVARIABLE` будет автоматически выставлен при выключенном параметре `X`. Например: +[[options-qmake_on]] +==== `OPT_QMAKE_ON` и `OPT_QMAKE_OFF` + +Когда выбрана опция _OPT_, значение `OPT_QMAKE_ON`, если оно определено, добавляется к `QMAKE_ARGS`. `OPT_QMAKE_OFF` работает аналогичным образом, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 -OPT1_USES_OFF=gmake +OPT1_QMAKE_ON= -DTEST:BOOL=true +OPT1_QMAKE_OFF= -DPRODUCTION:BOOL=true .... -соответствует: +эквивалентно: [.programlisting] .... @@ -2118,12 +4179,193 @@ OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> -.if ! ${PORT_OPTIONS:MOPT1} -USES+= gmake +.if ${PORT_OPTIONS:MOPT1} +QMAKE_ARGS+= -DTEST:BOOL=true +.else +QMAKE_ARGS+= -DPRODUCTION:BOOL=true +.endif +.... + +[[options-implies]] +==== `OPT_IMPLIES` + +Предоставляет способ добавления зависимостей между опциями. + +При выборе _OPT_ все перечисленные в этой переменной опции также будут выбраны. В качестве примера можно использовать описанный ранее crossref:makefiles[options-configure_enable,`OPT_CONFIGURE_ENABLE`]: + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 OPT2 +OPT1_IMPLIES= OPT2 + +OPT1_CONFIGURE_ENABLE= opt1 +OPT2_CONFIGURE_ENABLE= opt2 +.... + +Эквивалентно: + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 OPT2 + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT1} +CONFIGURE_ARGS+= --enable-opt1 +.else +CONFIGURE_ARGS+= --disable-opt1 +.endif + +.if ${PORT_OPTIONS:MOPT2} || ${PORT_OPTIONS:MOPT1} +CONFIGURE_ARGS+= --enable-opt2 +.else +CONFIGURE_ARGS+= --disable-opt2 +.endif +.... + +[[options-implies-ex1]] +.Простое использование `OPT_IMPLIES` +[example] +==== + +Этот порт имеет опцию `X11` и опцию `GNOME`, для сборки которой необходимо выбрать опцию `X11`. + +[.programlisting] +.... +OPTIONS_DEFINE= X11 GNOME +OPTIONS_DEFAULT= X11 + +X11_USES= xorg +X11_USE= xorg=xi,xextproto +GNOME_USE= gnome=gtk30 +GNOME_IMPLIES= X11 +.... + +==== + +[[options-prevents]] +==== `OPT_PREVENTS` и `OPT_PREVENTS_MSG` + +Предоставляет способ добавления конфликтов между опциями. + +Когда выбрана _OPT_, все опции, перечисленные в `OPT_PREVENTS`, должны быть сняты. Если задано `OPT_PREVENTS_MSG` и возникает конфликт, его содержимое будет показано с объяснением причины конфликта. Например: + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 OPT2 +OPT1_PREVENTS= OPT2 +OPT1_PREVENTS_MSG= OPT1 and OPT2 enable conflicting options +.... + +Примерно эквивалентно: + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 OPT2 + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT2} && ${PORT_OPTIONS:MOPT1} +BROKEN= Option OPT1 conflicts with OPT2 (select only one) +.endif +.... + +Единственное отличие заключается в том, что первый вариант выведет ошибку после выполнения `make config`, предлагая изменить выбранные настройки. + +[[options-prevents-ex1]] +.Простое использование `OPT_PREVENTS` +[example] +==== + +Этот порт имеет опции `X509` и `SCTP`. Обе опции добавляют патчи, но патчи конфликтуют друг с другом, поэтому их нельзя выбрать одновременно. + +[.programlisting] +.... +OPTIONS_DEFINE= X509 SCTP + +SCTP_PATCHFILES= ${PORTNAME}-6.8p1-sctp-2573.patch.gz:-p1 +SCTP_CONFIGURE_WITH= sctp + +X509_PATCH_SITES= http://www.roumenpetrov.info/openssh/x509/:x509 +X509_PATCHFILES= ${PORTNAME}-7.0p1+x509-8.5.diff.gz:-p1:x509 +X509_PREVENTS= SCTP +X509_PREVENTS_MSG= X509 and SCTP patches conflict +.... + +==== + +[[options-vars]] +==== `OPT_VARS` и `OPT_VARS_OFF` + +Предоставляет универсальный способ установки и добавления значений переменным. + +[WARNING] +==== +Перед использованием `OPT_VARS` и `OPT_VARS_OFF` проверьте, доступен ли более специфичный вспомогательный инструмент в crossref:makefiles[options-variables, Универсальная замена переменных, `OPT_VARIABLE` и `OPT_VARIABLE_OFF`]. +==== + +Когда выбрана опция _OPT_ и определены `OPT_VARS`, пары `_key_=_value_` и `_key_+=_value_` обрабатываются из `OPT_VARS`. Оператор `=` приводит к перезаписи существующего значения `KEY`, а `+=` добавляет к значению. `OPT_VARS_OFF` работает аналогично, но когда `OPT` _не_ выбрана. + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 OPT2 OPT3 +OPT1_VARS= also_build+=bin1 +OPT2_VARS= also_build+=bin2 +OPT3_VARS= bin3_build=yes +OPT3_VARS_OFF= bin3_build=no + +MAKE_ARGS= ALSO_BUILD="${ALSO_BUILD}" BIN3_BUILD="${BIN3_BUILD}" +.... + +эквивалентно: + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 OPT2 + +MAKE_ARGS= ALSO_BUILD="${ALSO_BUILD}" BIN3_BUILD="${BIN3_BUILD}" + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT1} +ALSO_BUILD+= bin1 +.endif + +.if ${PORT_OPTIONS:MOPT2} +ALSO_BUILD+= bin2 .endif + +.if ${PORT_OPTIONS:MOPT2} +BIN3_BUILD= yes +.else +BIN3_BUILD= no +.endif +.... + +[IMPORTANT] +==== +Значения, содержащие пробелы, должны быть заключены в кавычки: + +[.programlisting] +.... +OPT_VARS= foo="bar baz" .... -Для любого из следующих типов зависимости: +Это связано с тем, как man:make[1] обрабатывает пробелы при раскрытии переменных. Когда `OPT_VARS= foo=bar baz` раскрывается, переменная в итоге содержит две строки: `foo=bar` и `baz`. Однако отправитель, вероятно, предполагал, что должна быть только одна строка — `foo=bar baz`. Заключение значения в кавычки предотвращает использование пробела в качестве разделителя. + +Также _не_ добавляйте лишние пробелы после знака `_var_=` и перед значением, это также разобьёт строку на две части. _Это не сработает_: + +[.programlisting] +.... +OPT_VARS= foo= bar +.... + +==== + +[[options-dependencies]] +==== Зависимости, `OPT_DEPTYPE` и `OPT_DEPTYPE_OFF` + +Для любого из этих типов зависимостей: * `PKG_DEPENDS` * `EXTRACT_DEPENDS` @@ -2133,15 +4375,91 @@ USES+= gmake * `LIB_DEPENDS` * `RUN_DEPENDS` -Значение переменной `X_ABOVEVARIABLE` будет дописано в `ABOVEVARIABLE` в соответствии с состоянием `X`. Следующая запись: +Когда выбрана опция _OPT_, значение `OPT_DEPTYPE`, если оно определено, добавляется к `DEPTYPE`. `OPT_DEPTYPE_OFF` работает аналогично, но когда _не_ выбрана `OPT`. Например: + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 +OPT1_LIB_DEPENDS= liba.so:devel/a +OPT1_LIB_DEPENDS_OFF= libb.so:devel/b +.... + +эквивалентно: + +[.programlisting] +.... +OPTIONS_DEFINE= OPT1 + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT1} +LIB_DEPENDS+= liba.so:devel/a +.else +LIB_DEPENDS+= libb.so:devel/b +.endif +.... + +[[options-variables]] +==== Универсальная замена переменных, `OPT_VARIABLE` и `OPT_VARIABLE_OFF` + +Для любой из этих переменных: + +* `ALL_TARGET` +* `BINARY_ALIAS` +* `BROKEN` +* `CATEGORIES` +* `CFLAGS` +* `CONFIGURE_ENV` +* `CONFLICTS` +* `CONFLICTS_BUILD` +* `CONFLICTS_INSTALL` +* `CPPFLAGS` +* `CXXFLAGS` +* `DESKTOP_ENTRIES` +* `DISTFILES` +* `EXTRACT_ONLY` +* `EXTRA_PATCHES` +* `GH_ACCOUNT` +* `GH_PROJECT` +* `GH_SUBDIR` +* `GH_TAGNAME` +* `GH_TUPLE` +* `GL_ACCOUNT` +* `GL_COMMIT` +* `GL_PROJECT` +* `GL_SITE` +* `GL_SUBDIR` +* `GL_TUPLE` +* `IGNORE` +* `INFO` +* `INSTALL_TARGET` +* `LDFLAGS` +* `LIBS` +* `MAKE_ARGS` +* `MAKE_ENV` +* `MASTER_SITES` +* `PATCHFILES` +* `PATCH_SITES` +* `PLIST_DIRS` +* `PLIST_FILES` +* `PLIST_SUB` +* `PORTDOCS` +* `PORTEXAMPLES` +* `SUB_FILES` +* `SUB_LIST` +* `TEST_TARGET` +* `USES` + +Когда выбрана опция _OPT_, значение `OPT_ABOVEVARIABLE`, если оно определено, добавляется к `_ABOVEVARIABLE_`. `OPT_ABOVEVARIABLE_OFF` работает аналогично, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 -OPT1_LIB_DEPENDS= liba.so:${PORTSDIR}/devel/a +OPT1_USES= gmake +OPT1_CFLAGS_OFF= -DTEST .... -соответствует: +эквивалентно: [.programlisting] .... @@ -2150,118 +4468,290 @@ OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} -LIB_DEPENDS+= liba.so:${PORTSDIR}/devel/a +USES+= gmake +.else +CFLAGS+= -DTEST .endif .... -Если установлена `X_ABOVEVARIABLE_OFF`, то зависимость типа `ABOVEVARIABLE` будет добавлена при выключенном параметре `X`. Например: +[NOTE] +==== +Некоторые переменные отсутствуют в этом списке, в частности `PKGNAMEPREFIX` и `PKGNAMESUFFIX`. Это сделано намеренно. Порт _не должен_ изменять своё имя при изменении набора опций. +==== + +[WARNING] +==== +Некоторые из этих переменных, по крайней мере `ALL_TARGET`, `DISTFILES` и `INSTALL_TARGET`, получают свои значения по умолчанию _после_ обработки опций. + +С такими строками в [.filename]#Makefile#: + +[.programlisting] +.... +ALL_TARGET= all + +DOCS_ALL_TARGET= doc +.... + +Если опция `DOCS` включена, `ALL_TARGET` будет иметь конечное значение `all doc`; если опция отключена, значение будет `all`. + +Только со строкой помощника опций в [.filename]#Makefile#: + +[.programlisting] +.... +DOCS_ALL_TARGET= doc +.... + +Если опция `DOCS` включена, `ALL_TARGET` будет иметь окончательное значение `doc`; если опция отключена, значение будет `all`. +==== + +[[options-targets]] +==== Дополнительные цели сборки, `_target_-_OPT_-on` и `_target_-_OPT_-off` + +Эти цели в [.filename]#Makefile# могут принимать дополнительные опциональные цели сборки: + +* `pre-fetch` +* `do-fetch` +* `post-fetch` +* `pre-extract` +* `do-extract` +* `post-extract` +* `pre-patch` +* `do-patch` +* `post-patch` +* `pre-configure` +* `do-configure` +* `post-configure` +* `pre-build` +* `do-build` +* `post-build` +* `pre-install` +* `do-install` +* `post-install` +* `post-stage` +* `pre-package` +* `do-package` +* `post-package` + +Когда выбрана опция _OPT_, цель `_TARGET_-_OPT_-on`, если она определена, выполняется после `_TARGET_`. `_TARGET_-_OPT_-off` работает аналогично, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 -OPT1_LIB_DEPENDS_OFF= liba.so:${PORTSDIR}/devel/a + +post-patch-OPT1-on: + @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${EXAMPLESDIR}/|' ${WRKSRC}/Makefile + +post-patch-OPT1-off: + @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${PREFIX}/bin/|' ${WRKSRC}/Makefile .... -соответствует: +эквивалентно: [.programlisting] .... -OPTIONS_DEFINE= OPT1 +OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> -. if ! ${PORT_OPTIONS:MOPT1} -LIB_DEPENDS+= liba.so:${PORTSDIR}/devel/a +post-patch: +.if ${PORT_OPTIONS:MOPT1} + @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${EXAMPLESDIR}/|' ${WRKSRC}/Makefile +.else + @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${PREFIX}/bin/|' ${WRKSRC}/Makefile .endif .... [[makefile-wrkdir]] -== Задание рабочего каталога +== Указание рабочего каталога -Каждый порт распаковывается в рабочий каталог, который должен быть доступным для записи. В системе портов по умолчанию `DISTFILES` распаковываются в каталог с именем `${DISTNAME}`. Другими словами, если вы задали: +Каждый порт извлекается в рабочий каталог, который должен быть доступен для записи. Система портов по умолчанию распаковывает `DISTFILES` в каталог с именем `${DISTNAME}`. Другими словами, если в [.filename]#Makefile# указано: [.programlisting] .... PORTNAME= foo -PORTVERSION= 1.0 +DISTVERSION= 1.0 .... -то дистрибутивные файлы порта содержат каталог верхнего уровня, [.filename]#foo-1.0#, и все файлы расположены в этом каталоге. +то файлы дистрибутива порта содержат каталог верхнего уровня [.filename]#foo-1.0#, и остальные файлы находятся в этом каталоге. -Если это не ваш случай, то имеется несколько переменных, которые вы можете переопределить. +Если нужно расположение файлов в других каталогах, можно переопределить ряд переменных. +[[makefile-wrksrc]] === `WRKSRC` -Эта переменная задаёт имя каталога, который создаётся при распаковке исходных файлов приложения. В нашем предыдущем примере если бы распаковка происходила в каталог с именем [.filename]#foo# (а не [.filename]#foo-1.0#), то вы должны написать: +Переменная указывает имя каталога, который создается при распаковке distfiles приложения. Чтобы в нашем предыдущем примере распаковка происходила в каталог с именем [.filename]#foo# (а не [.filename]#foo-1.0#), напишите: [.programlisting] .... WRKSRC= ${WRKDIR}/foo .... -или, как вариант +или можно [.programlisting] .... WRKSRC= ${WRKDIR}/${PORTNAME} .... +[[makefile-wrksrc_subdir]] +=== `WRKSRC_SUBDIR` + +Если исходные файлы, необходимые для порта, находятся в подкаталоге распакованного дистрибутива, присвойте `WRKSRC_SUBDIR` имя этого каталога. + +[.programlisting] +.... +WRKSRC_SUBDIR= src +.... + +[[makefile-no_wrksubdir]] === `NO_WRKSUBDIR` -Если порт вообще не распаковывается ни в какой каталог, то вы должны задать для этого переменную `NO_WRKSUBDIR`. +Если порт не распаковывается в подкаталог вообще, установите `NO_WRKSUBDIR`, чтобы указать это. [.programlisting] .... NO_WRKSUBDIR= yes .... +[NOTE] +==== +Поскольку `WRKDIR` является единственной директорией, которая должна быть доступна для записи во время сборки, и используется для хранения многих файлов, фиксирующих состояние сборки, извлечение порта будет принудительно выполнено в поддиректорию. +==== + [[conflicts]] -== Разрешение конфликтов +== Обработка конфликтов -Для регистрации конфликта между пакетами и портами используются три различные переменные: `CONFLICTS`, `CONFLICTS_INSTALL` и `CONFLICTS_BUILD`. +Существует три различные переменные для регистрации конфликтов между пакетами и портами: `CONFLICTS`, `CONFLICTS_INSTALL` и `CONFLICTS_BUILD`. [NOTE] ==== -Переменные регистрации конфликта автоматически определяют переменную `IGNORE`, которая более подробно описана в crossref:porting-dads[dads-noinstall, "Пометка неустанавливаемого порта как `BROKEN`, `FORBIDDEN` или `IGNORE` "]. +Эти переменные автоматически устанавливают переменную `IGNORE`, более подробно описанную в crossref:porting-dads[dads-noinstall,Пометка порта как неустанавливаемого с помощью `BROKEN`, `FORBIDDEN` или `IGNORE`]. +==== + +При удалении одного из нескольких конфликтующих портов рекомендуется оставлять `CONFLICTS` в тех других портах на несколько месяцев, чтобы учесть пользователей, которые обновляются лишь время от времени. + +[[conclicts-conflicts_install]] +`CONFLICTS_INSTALL`:: +Если пакет не может сосуществовать с другими пакетами (из-за конфликтов файлов, несовместимости во время выполнения и т.д.). Проверка `CONFLICTS_INSTALL` выполняется после этапа сборки и перед этапом установки. + +[[conclicts-conflicts_build]] +`CONFLICTS_BUILD`:: +Если порт не может быть собран, когда уже установлены другие определённые порты. Конфликты сборки не фиксируются в результирующем пакете. + +[[conclicts-conflicts]] +`CONFLICTS`:: +Если порт не может быть собран, когда определённый порт уже установлен и итоговый пакет не может сосуществовать с другим пакетом. Проверка `CONFLICTS` выполняется до этапа сборки и до этапа установки. + +Каждый элемент, разделённый пробелами, в значениях переменных `CONFLICTS*` сопоставляется с пакетами(кроме того, который собирается) с использованием правил раскрытия шаблонов имен файлов в оболочке shell. Это позволяет перечислить все варианты порта в списке конфликтов вместо необходимости исключать собираемый вариант из этого списка. Например, если установлен git-lite, `CONFLICTS_INSTALL=git git-lite` позволит выполнить: +[source, shell] +.... +% make -C devel/git FLAVOR=lite all deinstall install +.... + +Но следующая команда сообщит о конфликте, так как установленное имя базового пакета — `git-lite`, а `git` будет собран, но не может быть установлен вместе с `git-lite`: +[source, shell] +.... +% make -C devel/git FLAVOR=default all deinstall install +.... + +Без этой функции Makefile потребовал бы по одному `_flavor__CONFLICTS_INSTALL` для каждого варианта, перечисляя все остальные варианты. + +Наиболее распространённым содержимым одной из этих переменных является база пакета другого порта. База пакета — это имя пакета без указания версии, её можно получить, выполнив команду `make -V PKGBASE`. + +[[conflicts-ex1]] +.Простой пример использования `CONFLICTS*` +[example] +==== + +Пакет package:dns/bind99[] не может быть установлен, если присутствует пакет package:dns/bind910[], так как они устанавливают одинаковые файлы. Сначала соберите базовый пакет для использования: + +[source, shell] +.... +% make -C dns/bind99 -V PKGBASE +bind99 +% make -C dns/bind910 -V PKGBASE +bind910 +.... + +Затем добавьте в [.filename]#Makefile# пакета package:dns/bind99[]: + +[.programlisting] +.... +CONFLICTS_INSTALL= bind910 +.... + +И добавьте в [.filename]#Makefile# пакета package:dns/bind910[]: + +[.programlisting] +.... +CONFLICTS_INSTALL= bind99 +.... + +==== + +Иногда только определенные версии другого порта несовместимы. В этом случае используйте полное имя пакета, включая версию. При необходимости используйте подстановочные символы шаблонов имён файлов оболочки, такие как `*` и `?`, чтобы охватить все необходимые версии. + +[[conflicts-ex2]] +.Использование `CONFLICTS*` с шаблонами имён файлов. +[example] ==== -При удалении одного из конфликтующих портов целесообразно сохранить записи `CONFLICTS` в тех других портах в течении нескольких месяцев, чтобы позаботиться о тех пользователей, которые обновляются от случая к случаю. +В версиях с 2.0 по 2.4.1_2 пакет package:deskutils/gnotime[] устанавливал встроенную версию пакета package:databases/qof[]. -=== `CONFLICTS_INSTALL` +Чтобы отразить это прошлое, [.filename]#Makefile# пакета package:databases/qof[] содержит: -Если ваш пакет не может существовать вместе с другими (из-за конфликта файлов, несовместимости времени выполнения и так далее), перечислите имена остальных пакетов в переменной `CONFLICTS_INSTALL`. Здесь вы можете использовать шаблоны командного интерпретатора, такие как `*` и `?`. Имена пакетов должны выглядеть так же, как в [.filename]#/var/db/pkg#. Пожалуйста, убедитесь, что `CONFLICTS_INSTALL` не содержит пакет самого этого порта. В противном случае не будет работать установка с использованием переменной `FORCE_PKG_REGISTER`. Проверка CONFLICTS_INSTALL выполняется после процесса сборки и до процесса установки. +[.programlisting] +.... +CONFLICTS_INSTALL= gnotime-2.[0-3]* \ + gnotime-2.4.0* gnotime-2.4.1 \ + gnotime-2.4.1_[12] +.... -=== `CONFLICTS_BUILD` +Первый элемент соответствует версиям `2.0`–`2.3`, второй — всем редакциям `2.4.0`, третий — точно версии `2.4.1`, а последний — первой и второй редакциям версии `2.4.1`. -Если ваш порт не может быть собран, когда уже установлен другой, перечислите имена остальных портов в переменной `CONFLICTS_BUILD`. Здесь вы можете использовать шаблоны командного интерпретатора, такие как `*` и `?`. Имена пакетов должны выглядеть так же, как в [.filename]#/var/db/pkg#. Проверка CONFLICTS_BUILD выполняется до процесса сборки. Конфликты сборки в получаемом пакете не записываются. +package:deskutils/gnotime[] не имеет строки конфликтов, потому что его текущая версия не конфликтует ни с чем другим. +==== -=== `CONFLICTS` +Переменная `DISABLE_CONFLICTS` может быть временно установлена при выполнении целей, на которые не влияют конфликты. Эту переменную не следует устанавливать в Makefiles портов. -Если ваш порт не может быть собран, когда уже установлен другой, а получаемый пакет не может существовать вместе с другими, перечислите имена остальных пакетов в переменной `CONFLICTS`. Здесь вы можете использовать шаблоны командного интерпретатора, такие как `*` и `?`. Имена пакетов должны выглядеть так же, как в [.filename]#/var/db/pkg#. Пожалуйста, убедитесь, что `CONFLICTS` не содержит пакет самого этого порта. В противном случае не будет работать установка с использованием переменной `FORCE_PKG_REGISTER`. Проверка CONFLICTS выполняется до процессов сборки и установки. +[source, shell] +.... +% make -DDISABLE_CONFLICTS patch +.... [[install]] == Установка файлов +[IMPORTANT] +==== +Фаза `install` очень важна для конечного пользователя, так как она добавляет файлы в его систему. Все дополнительные команды, выполняемые в целях `*-install` [.filename]#Makefile# порта, должны выводиться на экран. _Не_ заглушайте эти команды с помощью `@` или `.SILENT`. +==== + [[install-macros]] === Макросы `INSTALL_*` -Используйте макросы, которые есть в файле [.filename]#bsd.port.mk# для обеспечения правильных прав доступа файлов в целях `*-install` порта. Устанавливайте права владения напрямую в [.filename]#pkg-plist# через соответствующие записи `@owner owner` и `@group group`. Эти операторы работают до момента их переопределения или до конца [.filename]#pkg-plist#, поэтому не забывайте их сбрасывать, когда они больше не нужны. По умолчанию владение устанавливается для `root:wheel`. +Используйте макросы, предоставленные в [.filename]#bsd.port.mk#, чтобы обеспечить корректные режимы файлов в целях `*-install` порта. Устанавливайте владельца напрямую в [.filename]#pkg-plist# в соответствующих записях, таких как `@(_владелец_,_группа_,)`, `@owner _владелец_` и `@group _группа_`. Эти операторы действуют до переопределения или до конца [.filename]#pkg-plist#, поэтому не забудьте сбросить их, когда они больше не нужны. Владелец по умолчанию — `root:wheel`. Дополнительную информацию см. в crossref:plist[plist-keywords-base,Базовые Ключевые Слова]. -* `INSTALL_PROGRAM` - это команда для установки бинарных выполнимых файлов. -* `INSTALL_SCRIPT` - это команда для установки выполнимых скриптов. -* `INSTALL_LIB` - это команда для установки динамических библиотек. -* `INSTALL_KLD` - это команда для установки загружаемых модулей ядра. Некоторые архитектуры предпочитают, чтобы для модулей сохранялись отладочные сведения, по этой причине используйте эту команду вместо `INSTALL_PROGRAM`. -* `INSTALL_DATA` - это команда для установки совместно используемых файлов данных. -* `INSTALL_MAN` - это команда для установки страниц Справочника и другой документации (никаких файлов она не сжимает). +* `INSTALL_PROGRAM` — команда для установки бинарных исполняемых файлов. +* `INSTALL_SCRIPT` — команда для установки исполняемых скриптов. +* `INSTALL_LIB` — это команда для установки общих библиотек (но не статических библиотек). +* `INSTALL_KLD` — это команда для установки загружаемых модулей ядра. Некоторые архитектуры не поддерживают удаление символов из модулей, поэтому используйте эту команду вместо `INSTALL_PROGRAM`. +* `INSTALL_DATA` — это команда для установки общих данных, включая статические библиотеки. +* `INSTALL_MAN` — это команда для установки man-страниц и другой документации (она ничего не сжимает). -В основе работы этих макросов лежит команда `install` со всеми соответствующими флагами. Смотрите пример их использования ниже. +Эти переменные передаются команде man:install[1] с соответствующими флагами для каждой ситуации. + +[IMPORTANT] +==== +Не используйте `INSTALL_LIB` для установки статических библиотек, так как их удаление делает их бесполезными. Вместо этого используйте `INSTALL_DATA`. +==== [[install-strip]] -=== Удаление отладочной информации в бинарных файлах и динамических библиотеках +=== Удаление символов из бинарных файлов и разделяемых библиотек -Не удаляйте отладочную информацию из бинарных файлов вручную, если вы это делали. Во всех двоичных файлах отладочная информация должна быть удалена, и макрос `INSTALL_PROGRAM` выполнит установку и удаление отладочной информации одновременно (обратитесь к следующему разделу). Макрос `INSTALL_LIB` делает то же самое для динамических библиотек. +Установленные бинарные файлы должны быть очищены от отладочной информации. Не очищайте бинарные файлы вручную, если это не является абсолютно необходимым. Макрос `INSTALL_PROGRAM` устанавливает и очищает бинарный файл одновременно. Макрос `INSTALL_LIB` делает то же самое с разделяемыми библиотеками. -Если вам нужно удалить отладочную информацию из файла без использования макросов `INSTALL_PROGRAM` и `INSTALL_LIB`, то это можно сделать при помощи `${STRIP_CMD}`. Обычно это делается внутри цели `post-install`. К примеру: +Когда файл необходимо очистить, но ни макросы `INSTALL_PROGRAM`, ни `INSTALL_LIB` не подходят, `${STRIP_CMD}` очищает программу или разделяемую библиотеку. Обычно это делается в цели `post-install`. Например: [.programlisting] .... @@ -2269,24 +4759,33 @@ post-install: ${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/xdl .... -Удаление отладочной информации из нескольких файлов: +Когда необходимо удалить отладочную информацию из нескольких файлов: [.programlisting] .... post-install: - .for l in geometry media body track world +.for l in geometry media body track world ${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/lib${PORTNAME}-${l}.so.0 - .endfor +.endfor .... -Для проверки того, удалена ли отладочная информация из файла, используйте man:file[1]. Для двоичных файлов man:file[1] печатает `stripped` или `not stripped`. Кроме того, man:strip[1] определяет, была ли уже удалена из программы отладочная информация, и в этом случае просто завершает свою работу. +Используйте man:file[1] для файла, чтобы определить, был ли он подвергнут удалению символов. man:file[1] сообщает, что бинарные файлы либо `stripped` (удалены символы), либо `not stripped` (символы не удалены). Кроме того, man:strip[1] обнаружит программы, которые уже были подвергнуты удалению символов, и завершит работу без ошибок. + +[IMPORTANT] +==== +Когда определён `WITH_DEBUG`, elf-файлы _не должны_ быть очищены. + +Переменные (`STRIP_CMD`, `INSTALL_PROGRAM`, `INSTALL_LIB`, ...) и crossref:uses[uses,`USES`], предоставляемые фреймворком, обрабатывают это автоматически. + +Некоторое программное обеспечение добавляет `-s` к своим `LDFLAGS`. В этом случае либо удалите `-s`, если установлен `WITH_DEBUG`, либо удалите его безусловно и используйте `STRIP_CMD` в `post-install`. +==== [[install-copytree]] === Установка целого дерева файлов -Иногда должно быть установлено большое количество файлов с сохранением их иерархической организации. Например, копирование дерева каталогов целиком из `WRKSRC` в целевой каталог внутри `PREFIX`. Обратите внимание, что `PREFIX`, `EXAMPLESDIR`, `DATADIR` и другие переменные пути всегда должны предваряться `STAGEDIR`, чтобы не ломать staging (смотрите <<staging>>). +Иногда необходимо установить большое количество файлов с сохранением их иерархической структуры. Например, копирование всего дерева каталогов из `WRKSRC` в целевой каталог под `PREFIX`. Обратите внимание, что `PREFIX`, `EXAMPLESDIR`, `DATADIR` и другие переменные путей всегда должны предваряться `STAGEDIR` для соблюдения процедуры промежуточной установки (см. crossref:special[staging,Промежуточная установка]). -Для этой ситуации существует два макроса. Преимущество от использования этих макросов вместо команды `cp` в том, что они гарантируют установку правильного владельца и прав на конечные файлы. Первый макрос, `COPYTREE_BIN`, делает все устанавливаемые файлы исполняемыми, что подходит для установки в [.filename]#PREFIX/bin#. Второй макрос, `COPYTREE_SHARE`, не устанавливает на файлы права исполнения, и, таким образом, подходит для установки файлов внутри каталога [.filename]#PREFIX/share#. +Для этой ситуации существуют два макроса. Преимущество использования этих макросов вместо `cp` заключается в том, что они гарантируют целевым файлам правильные значения владельца и разрешений. Первый макрос, `COPYTREE_BIN`, устанавливает все установленные файлы как исполняемые, что делает его подходящим для установки в [.filename]#PREFIX/bin#. Второй макрос, `COPYTREE_SHARE#, не устанавливает исполняемые разрешения для файлов и, следовательно, подходит для установки файлов в [.filename]#PREFIX/share#. [.programlisting] .... @@ -2295,7 +4794,7 @@ post-install: (cd ${WRKSRC}/examples && ${COPYTREE_SHARE} . ${STAGEDIR}${EXAMPLESDIR}) .... -В этом примере устанавливается содержимое каталога [.filename]#examples# из установочных файлов производителя в надлежащее место для примеров вашего порта. +Этот пример установит содержимое каталога [.filename]#examples# из дистрибутива вендора в соответствующее расположение примеров порта. [.programlisting] .... @@ -2304,9 +4803,9 @@ post-install: (cd ${WRKSRC}/temperatures && ${COPYTREE_SHARE} "June July August" ${STAGEDIR}${DATADIR}/summer) .... -А в этом примере будут установлены данные летних месяцев в подкаталог [.filename]#summer# каталога [.filename]#DATADIR#. +И этот пример установит данные летних месяцев в подкаталог [.filename]#summer# каталога [.filename]#DATADIR#. -В качестве третьего параметра в макросе `COPYTREE_*` можно передать дополнительные параметры `find`. Например, чтобы в первом примере установить все файлы кроме файлов Makefile, можно использовать следующую команду. +Дополнительные аргументы `find` могут быть переданы через третий аргумент макросов `COPYTREE_*`. Например, чтобы установить все файлы из первого примера, кроме Makefiles, можно использовать следующие команды. [.programlisting] .... @@ -2316,50 +4815,51 @@ post-install: ${COPYTREE_SHARE} . ${STAGEDIR}${EXAMPLESDIR} "! -name Makefile") .... -Эти макросы не производят добавление устанавливаемых файлов в [.filename]#pkg-plist#. Они должны быть добавлены туда вручную. Необязательные файлы документации (`PORTDOCS`, смотрите <<install-documentation>>) и примеров (`PORTEXAMPLES`) всегда должны предваряться в [.filename]#pkg-plist# префиксами `%%PORTDOCS%%` или `%%PORTEXAMPLES%%`. +Эти макросы не добавляют установленные файлы в [.filename]#pkg-plist#. Их необходимо добавлять вручную. Для дополнительной документации (`PORTDOCS`, см. crossref:makefiles[install-documentation, Установка дополнительной документации]) и примеров (`PORTEXAMPLES`), префиксы `%%PORTDOCS%%` или `%%PORTEXAMPLES%%` должны быть добавлены в [.filename]#pkg-plist#. [[install-documentation]] === Установка дополнительной документации -Если с вашим программным обеспечением поставляется некоторая документация, отличающаяся от стандартных страниц Справочника и файлов info, которая, как вы думаете, будет полезна пользователям, установите ее в каталог [.filename]#PREFIX/shared/doc#. Это может быть сделано, как и в предыдущем разделе, в цели `post-install`. +Если у программного обеспечения есть документация, помимо стандартных страниц man и info, которая может быть полезна пользователю, установите её в `DOCSDIR`. Это можно сделать, как и в предыдущем пункте, в цели `post-install`. -Создайте для вашего порта новый каталог. Имя каталога должно соответствовать тому, что представляет из себя порт. Обычно это означает `PORTNAME`. Однако, если вы думаете, что пользователь захочет иметь разные версии порта, установленные одновременно, то вы можете использовать полное имя `PKGNAME`. +Создайте новый каталог для порта. Имя каталога — `DOCSDIR`. Обычно оно равно `PORTNAME`. Однако, если пользователю может потребоваться установка разных версий порта одновременно, можно использовать полное имя `PKGNAME`. -Поскольку устанавливаются только файлы, перечисленные в [.filename]#pkg-plist#, безопасным способом будет устанавливать документацию в `STAGEDIR` всегда (смотрите crossref:special[staging, Staging]). Следовательно, блоки `.if` нужны только для файлов достаточно большого размера, установка которых влечёт значительные накладные расходы на операции ввода/вывода. +Поскольку устанавливаются только файлы, перечисленные в [.filename]#pkg-plist#, можно безопасно всегда устанавливать документацию в `STAGEDIR` (см. crossref:special[staging,Staging]). Поэтому блоки `.if` требуются только в тех случаях, когда устанавливаемые файлы достаточно велики, чтобы вызвать значительные накладные расходы на ввод-вывод. [.programlisting] .... post-install: ${MKDIR} ${STAGEDIR}${DOCSDIR} - ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${STAGEDIR}${DOCSDIR} + ${INSTALL_DATA} ${WRKSRC}/docs/xvdocs.ps ${STAGEDIR}${DOCSDIR} .... -Вот несколько полезных переменных и то, как они преобразуются по умолчанию при использовании в [.filename]#Makefile#: +С другой стороны, если в порте есть опция DOCS, установите документацию в цели `post-install-DOCS-on`. Эти цели описаны в crossref:makefiles[options-targets, Дополнительные цели сборки, `_target_-_OPT_-on` и `_target_-_OPT_-off`]. -* `DATADIR` преобразуется в [.filename]#PREFIX/shared/PORTNAME#. -* `DATADIR_REL` преобразуется в [.filename]#share/PORTNAME#. -* `DOCSDIR` преобразуется в [.filename]#PREFIX/shared/doc/PORTNAME#. -* `DOCSDIR_REL` преобразуется в [.filename]#share/doc/PORTNAME#. -* `EXAMPLESDIR` преобразуется в [.filename]#PREFIX/shared/examples/PORTNAME#. -* `EXAMPLESDIR_REL` преобразуется в [.filename]#share/examples/PORTNAME#. +Вот несколько полезных переменных и их стандартное раскрытие при использовании в [.filename]#Makefile#: + +* `DATADIR` раскрывается в [.filename]#PREFIX/share/PORTNAME#. +* `DATADIR_REL` раскрывается в [.filename]#share/PORTNAME#. +* `DOCSDIR` раскрывается в [.filename]#PREFIX/share/doc/PORTNAME#. +* `DOCSDIR_REL` раскрывается в [.filename]#share/doc/PORTNAME#. +* `EXAMPLESDIR` раскрывается в [.filename]#PREFIX/share/examples/PORTNAME#. +* `EXAMPLESDIR_REL` раскрывается в [.filename]#share/examples/PORTNAME#. [NOTE] ==== -Параметр `DOCS` управляет установкой дополнительной документации в `DOCSDIR`. Это не относится к стандартным страницам справочника и страницам info. Все, что устанавливается в `DATADIR` и `EXAMPLESDIR`, соответственно управляется через параметры `DATA` и `EXAMPLES`. +Опция `DOCS` управляет только дополнительной документацией, устанавливаемой в `DOCSDIR`. Она не применяется к стандартным man-страницам и info-страницам. Содержимое, устанавливаемое в `EXAMPLESDIR`, контролируется опцией `EXAMPLES`. ==== -Эти переменные экспортируются в `PLIST_SUB`. Их значения появятся там в виде имён путей относительно [.filename]#PREFIX#, если это возможно. То есть [.filename]#share/doc/PORTNAME# в списке сборки по умолчанию будет заменен на `%%DOCSDIR%%`, и так далее. (Дополнительную информацию о подстановке в [.filename]#pkg-plist# можно найти <<plist-sub,здесь>>.) +Эти переменные экспортируются в `PLIST_SUB`. Их значения будут представлены там в виде путей относительно [.filename]#PREFIX#, если это возможно. То есть, [.filename]#share/doc/PORTNAME# будет заменено на `%%DOCSDIR%%` в списке упаковки по умолчанию и так далее. (Подробнее о подстановках в [.filename]#pkg-plist# см. crossref:plist[plist-sub,здесь].) -Все условно устанавливаемые файлы и каталоги с документацией должны быть перечислены в файле [.filename]#pkg-plist# с префиксом `%%PORTDOCS%%`, например: +Все условно устанавливаемые файлы и каталоги документации включаются в [.filename]#pkg-plist# с префиксом `%%PORTDOCS%%`, например: [.programlisting] .... %%PORTDOCS%%%%DOCSDIR%%/AUTHORS %%PORTDOCS%%%%DOCSDIR%%/CONTACT -%%PORTDOCS%%@dirrm %%DOCSDIR%% .... -В качестве альтернативы перечислению файлов документации в файле [.filename]#pkg-plist#, порт может указать в переменной `PORTDOCS` список имён файлов и глобальных шаблонов командного процессора для добавления в окончательный список сборки. Имена будут задаваться относительно `DOCSDIR`. Таким образом, порт, использующий `PORTDOCS` и нестандартное местоположение документации, должен задавать соответствующим образом и `DOCSDIR`. Если каталог указан в `PORTDOCS` или соответствует шаблону для этой переменной, то полное поддерево с входящими в него файлами и каталогами будет регистрироваться в окончательном списке сборки. Если параметр `DOCS` не задан, то файлы и каталоги, перечисленные в `PORTDOCS`, не будут установлены и добавлены в список сборки порта. Установка документации в `PORTDOCS`, как это показано выше, остаётся за самим портом. Типичный пример использования `PORTDOCS` выглядит следующим образом: +В качестве альтернативы перечислению файлов документации в [.filename]#pkg-plist#, порт может установить переменную `PORTDOCS` в список имён файлов и шаблонов имен файлов shell для добавления в итоговый список упаковки. Имена будут относительны к `DOCSDIR`. Поэтому порт, использующий `PORTDOCS` и нестандартное расположение документации, должен соответствующим образом установить `DOCSDIR`. Если в `PORTDOCS` указан каталог или он соответствует шаблону из этой переменной, всё поддерево содержащихся файлов и каталогов будет зарегистрировано в итоговом списке упаковки. Если опция `DOCS` отключена, файлы и каталоги, перечисленные в `PORTDOCS`, не будут установлены или добавлены в список упаковки порта. Установка документации в `PORTDOCS`, как показано выше, остаётся на усмотрение самого порта. Типичный пример использования `PORTDOCS`: [.programlisting] .... @@ -2368,12 +4868,57 @@ PORTDOCS= README.* ChangeLog docs/* [NOTE] ==== -Эквивалентами `PORTDOCS` для файлов, устанавливаемых в `DATADIR` и `EXAMPLESDIR` являются `PORTDATA` и `PORTEXAMPLES` соответственно. +Эквивалентами `PORTDOCS` для файлов, установленных в `DATADIR` и `EXAMPLESDIR`, являются `PORTDATA` и `PORTEXAMPLES` соответственно. -Во время установки выводится содержимое [.filename]#pkg-message#. За подробной информацией обратитесь к <<porting-message,разделу об использовании [.filename]#pkg-message#>>. Файл [.filename]#pkg-message# не нужно добавлять в [.filename]#pkg-plist#. +Содержимое файла [.filename]#pkg-message# отображается при установке. Подробности см. в разделе crossref:pkg-files[porting-message,использование файла [.filename]#pkg-message#]. Файл [.filename]#pkg-message# не нужно добавлять в [.filename]#pkg-plist#. ==== [[install-subdirs]] -=== Подкаталоги внутри PREFIX +=== Подкаталоги в `PREFIX` + +Попробуйте сделать так, чтобы порт размещал файлы в правильных подкаталогах `PREFIX`. Некоторые порты собирают всё в кучу и помещают в подкаталог с именем порта, что неверно. Также многие порты размещают все файлы, кроме бинарников, заголовочных файлов и страниц руководства, в подкаталоге [.filename]#lib#, что плохо согласуется с парадигмой BSD. Многие из этих файлов должны быть перемещены в один из следующих каталогов: [.filename]#etc# (файлы настройки/конфигурации), [.filename]#libexec# (исполняемые файлы для внутреннего использования), [.filename]#sbin# (исполняемые файлы для суперпользователей/администраторов), [.filename]#info# (документация для браузера info) или [.filename]#share# (архитектурно-независимые файлы). Подробности см. в man:hier[7]; правила, действующие для [.filename]#/usr#, в основном применимы и к [.filename]#/usr/local#. Исключение составляют порты, связанные с USENET "news". Они могут использовать [.filename]#PREFIX/news# в качестве места назначения для своих файлов. + +[[binary-alias]] +== Используйте `BINARY_ALIAS` для переименования команд вместо исправления сборки + +Когда определена переменная `BINARY_ALIAS`, будут созданы символьные ссылки на указанные команды в каталоге, который будет добавлен в начало переменной `PATH`. + +Используйте это для замены жёстко заданных команд, от которых зависит этап сборки, без необходимости исправлять какие-либо файлы сборки. + +[[binary-alias-ex1]] +.Использование `BINARY_ALIAS` для предоставления `gsed` в качестве `sed` +[example] +==== +Некоторые порты ожидают, что `sed` будет вести себя как GNU sed и используют возможности, которые man:sed[1] не предоставляет. GNU sed доступен в пакете package:textproc/gsed[] на FreeBSD. + +Используйте `BINARY_ALIAS` для замены `sed` на `gsed` на время сборки: + +[.programlisting] +.... +BUILD_DEPENDS= gsed:textproc/gsed +... +BINARY_ALIAS= sed=gsed +.... + +==== + +[[binary-alias-ex2]] +.Использование `BINARY_ALIAS` для создания псевдонимов жестко заданных команд `python3` +[example] +==== +Порт, в котором есть жёсткая ссылка на `python3` в скриптах сборки, требует его наличия в `PATH` во время сборки. Используйте `BINARY_ALIAS` для создания псевдонима, указывающего на нужный бинарный файл Python 3: + +[.programlisting] +.... +USES= python:3.4+,build +... +BINARY_ALIAS= python3=${PYTHON_CMD} +.... -Попробуйте поместить все файлы порта в правильных подкаталогах каталога `PREFIX`. Некоторые порты игнорируют все установки и помещают все в подкаталог с именем порта, что неправильно. Также многие порты помещают все, кроме бинарных файлов, файлов заголовков и страниц Справочника, в подкаталог каталога [.filename]#lib#, что не очень хорошо работает с подходом BSD. Многие файлы должны быть перемещены в одно из следующих местоположений: [.filename]#etc# (настроечные/конфигурационные файлы), [.filename]#libexec# (выполнимые файлы, запускаемые из других программ), [.filename]#sbin# (исполнимые файлы для администраторов/менеджеров системы), [.filename]#info# (документация в формате info для просмотрщика info) или [.filename]#share# (независимые от архитектуры файлы). Обратитесь к man:hier[7] для прояснения деталей; правила, покрывающие [.filename]#/usr#, достаточно хорошо подходят также и к [.filename]#/usr/local#. Исключением являются порты, имеющие дело с "новостями" USENET. Они могут использовать каталог [.filename]#PREFIX/news# для установки своих файлов. +См. crossref:special[using-python,Использование Python] для получения дополнительной информации о `USES=python`. +==== + +[NOTE] +==== +Бинарные псевдонимы создаются после обработки зависимостей, указанных через `BUILD_DEPENDS` и `LIB_DEPENDS`, но до цели `configure`. Это приводит к различным ограничениям. Например, программы, установленные через `TEST_DEPENDS`, нельзя использовать для создания бинарного псевдонима, так как тестовые зависимости, указанные таким образом, обрабатываются после создания бинарных псевдонимов. +==== |