Глава 5. Настройка Makefile | FreeBSD Documentation Portal
Description: Настройка Makefile для портов FreeBSD
Keywords: makefiles,configuring,naming,versions

# Глава 5. Настройка Makefile

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

Настройка Makefile довольно проста, и мы снова рекомендуем изучить существующие примеры перед началом. Также в этом руководстве есть пример Makefile, поэтому ознакомьтесь с ним и, пожалуйста, соблюдайте порядок переменных и разделов в этом шаблоне, чтобы порт был удобнее для чтения другими.

Рассмотрите эти проблемы последовательно при разработке нового Makefile:

## 5.1. Оригинальный исходный код

Находится ли он в `DISTDIR` в виде стандартного архива `gzip` с именем вроде foozolix-1.2.tar.gz? Если да, переходите к следующему шагу. Если нет, возможно, для формата имени файла дистрибутива потребуется переопределить одну или несколько переменных: `DISTVERSION`, `DISTNAME`, `EXTRACT_CMD`, `EXTRACT_BEFORE_ARGS`, `EXTRACT_AFTER_ARGS`, `EXTRACT_SUFX` или `DISTFILES`.

В худшем случае создайте пользовательскую цель `do-extract`, чтобы переопределить стандартную. Это редко, если вообще когда-либо, необходимо.

## 5.2. Именование

Первая часть Makefile порта указывает его название, описывает номер версии и помещает его в соответствующую категорию.

### 5.2.1. `PORTNAME`

Установите `PORTNAME` как базовое имя программы. Оно используется в качестве основы для пакета FreeBSD и для `DISTNAME`.

| Название пакета должно быть уникальным во всём дереве портов. Убедитесь, что `PORTNAME` ещё не используется существующим портом и что никакой другой порт уже не имеет такой же `PKGBASE`. Если имя уже занято, добавьте либо `PKGNAMEPREFIX`.

### 5.2.2. Версии, `DISTVERSION` или `PORTVERSION`

Установите `DISTVERSION` в номер версии программы.

`PORTVERSION` — это версия, используемая для пакета FreeBSD. Она будет автоматически вычислена из `DISTVERSION` в соответствии со схемой версионирования пакетов FreeBSD. Если версия содержит буквы, может потребоваться задать `PORTVERSION` вместо `DISTVERSION`.

| Только одна из переменных `PORTVERSION` и `DISTVERSION` может быть установлена одновременно.

Время от времени некоторые программы используют схему версионирования, которая несовместима с тем, как `DISTVERSION` преобразуется в `PORTVERSION`.

| При обновлении порта можно использовать аргумент `-t` утилиты pkg-version(8), чтобы проверить, является ли новая версия больше или меньше предыдущей. Смотрите ниже, как использовать pkg-version(8) для сравнения версий.

Пример 1. Использование pkg-version(8) для сравнения версий

`pkg version -t` принимает две версии в качестве аргументов и возвращает `<`, `=` или `>`, если первая версия меньше, равна или больше второй версии соответственно.

    % pkg version -t 1.2 1.3
     < (1)
    % pkg version -t 1.2 1.2
     = (2)
    % pkg version -t 1.2 1.2.0
     = (3)
    % pkg version -t 1.2 1.2.p1
     > (4)
    % pkg version -t 1.2.a1 1.2.b1
     < (5)
    % pkg version -t 1.2 1.2p1
     < (6)

1 | `1.2` идёт перед `1.3`.
2 | `1.2` и `1.2` равны, так как имеют одинаковую версию.
3 | `1.2` и `1.2.0` равны, так как ноль ничего не значит.
4 | `1.2` идёт после `1.2.p1`, так как `.p1` означает «pre-release 1» (предрелизная версия 1).
5 | `1.2.a1` предшествует `1.2.b1`, представьте "alpha" и "beta", где `a` идёт перед `b`.
6 | `1.2` находится перед `1.2p1`, так же как `2p1` (читается как "2, уровень исправления 1") — это версия, следующая после любой `2.X`, но перед `3`.

Здесь `a`, `b` и `p` используются так, как если бы они означали "альфа", "бета" или "пре-релиз" и "уровень патча", но на самом деле это просто буквы, которые сортируются в алфавитном порядке, поэтому можно использовать любую букву, и они будут отсортированы соответствующим образом.

Таблица 1. Примеры `DISTVERSION` и производной `PORTVERSION`
DISTVERSION | .PORTVERSION
--- | ---
0.7.1d | 0.7.1.d
10Alpha3 | 10.a3
3Beta7-pre2 | 3.b7.p2
8:f_17 | 8f.17

Пример 2. Использование `DISTVERSION`

Если версия содержит только числа, разделённые точками, тире или подчёркиваниями, используйте `DISTVERSION`.

    PORTNAME=   nekoto
    DISTVERSION=	1.2-4

Это сгенерирует `PORTVERSION` равный `1.2.4`.

Пример 3. Использование `DISTVERSION` когда версия начинается с буквы или префикса

Когда версия начинается или заканчивается буквой, или префиксом, или суффиксом, которые не являются частью версии, используйте `DISTVERSIONPREFIX`, `DISTVERSION` и `DISTVERSIONSUFFIX`.

Если версия `v1.2-4`:

    PORTNAME=   nekoto
    DISTVERSIONPREFIX=  v
    DISTVERSION=	1_2_4

Некоторые проекты, использующие GitHub, могут включать своё название в версии. Например, версия может выглядеть как `nekoto-1.2-4`:

    PORTNAME=   nekoto
    DISTVERSIONPREFIX=  nekoto-
    DISTVERSION=	1.2_4

Эти проекты также иногда используют строку в конце версии, например, `1.2-4_RELEASE`:

    PORTNAME=   nekoto
    DISTVERSION=	1.2-4
    DISTVERSIONSUFFIX=  _RELEASE

Или они делают и то, и другое, например, `nekoto-1.2-4_RELEASE`:

    PORTNAME=   nekoto
    DISTVERSIONPREFIX=  nekoto-
    DISTVERSION=	1.2-4
    DISTVERSIONSUFFIX=  _RELEASE

`DISTVERSIONPREFIX` и `DISTVERSIONSUFFIX` не будут использоваться при формировании `PORTVERSION`, а только в `DISTNAME`.

Все сгенерируют `PORTVERSION` равный `1.2.4`.

Пример 4. Использование `DISTVERSION`, когда версия содержит буквы, означающие "alpha", "beta" или "pre-release"

Если версия содержит числа, разделённые точками, тире или подчёркиваниями, а буквы используются для обозначения "альфа", "бета" или "предварительной версии" (то есть до версии без букв), используйте `DISTVERSION`.

    PORTNAME=   nekoto
    DISTVERSION=	1.2-pre4

    PORTNAME=   nekoto
    DISTVERSION=	1.2p4

Оба варианта создадут `PORTVERSION` равную `1.2.p4`, что предшествует версии 1.2. Для проверки этого факта можно использовать pkg-version(8):

    % pkg version -t 1.2.p4 1.2
    <

Пример 5. Не использовать `DISTVERSION`, если версия содержит буквы, означающие "уровень патча"

Если версия содержит буквы, которые не означают "alpha", "beta" или "pre", а скорее указывают на "уровень исправления" и следуют после версии без букв, используйте `PORTVERSION`.

    PORTNAME=   nekoto
    PORTVERSION=	1.2p4

В данном случае использование `DISTVERSION` невозможно, так как это приведёт к генерации версии `1.2.p4`, которая будет считаться более ранней, чем `1.2`, а не более поздней. pkg-version(8) подтвердит это:

    % pkg version -t 1.2 1.2.p4
    > (1)
    % pkg version -t 1.2 1.2p4
    < (2)

1 | `1.2` идёт после `1.2.p4`, что в данном случае неверно.
2 | `1.2` находится перед `1.2p4`, что и требовалось.

Для более сложных примеров настройки `PORTVERSION`, когда версия программного обеспечения действительно несовместима с FreeBSD, или `DISTNAME`, когда файл дистрибутива не содержит саму версию, см. `DISTNAME`.

### 5.2.3. `PORTREVISION` и `PORTEPOCH`

#### 5.2.3.1. `PORTREVISION`

`PORTREVISION` — это монотонно возрастающее значение, которое сбрасывается в 0 при каждом увеличении `DISTVERSION`, обычно при каждом новом официальном выпуске от поставщика. Если `PORTREVISION` не равен нулю, его значение добавляется к имени пакета. Изменения `PORTREVISION` используются автоматизированными инструментами, такими как pkg-version(8), для определения доступности нового пакета.

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

Примеры случаев, когда необходимо увеличить `PORTREVISION`:

- Добавление исправлений для устранения уязвимостей безопасности, ошибок или для добавления новой функциональности в порт.

- Изменения в Makefile порта для включения или отключения параметров сборки в пакете.

- Изменения в списке файлов пакета или в поведении во время установки. Например, изменение скрипта, который генерирует начальные данные для пакета, такие как ключи хоста ssh(1).

- Увеличение версии зависимости порта от общей библиотеки (в данном случае, попытка установить старый пакет после установки более новой версии зависимости завершится неудачей, так как будет искаться старая версия libfoo.x вместо libfoo.(x+1)).

- Тихие изменения в дистрибутивном файле порта, которые имеют значительные функциональные отличия. Например, изменения в дистрибутивном файле, требующие корректировки файла distinfo без соответствующего изменения `DISTVERSION`, когда сравнение `diff -ru` старой и новой версий показывает нетривиальные изменения в коде.

- Изменения в `MAINTAINER`.

Примеры изменений, которые не требуют увеличения `PORTREVISION`:

- Стилевые изменения в каркасе портов без функциональных изменений в итоговом пакете.

- Изменения в `MASTER_SITES` или другие функциональные изменения порта, которые не влияют на итоговый пакет.

- Тривиальные исправления в дистрибутивном файле, такие как исправление опечаток, которые не настолько важны, чтобы пользователи пакета были вынуждены тратить время на обновление.

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

Эмпирическое правило заключается в том, чтобы решить, является ли изменение, внесённое в порт, чем-то, что принесёт пользу некоторым пользователям. Будь то улучшение, исправление или просто факт, что новый пакет вообще будет работать. Затем необходимо сопоставить это с тем, что всем, кто регулярно обновляет своё дерево портов, придётся выполнить обновление. Если ответ положительный, необходимо увеличить `PORTREVISION`.

| Пользователи бинарных пакетов никогда не увидят обновления, если `PORTREVISION` не увеличен. Без увеличения `PORTREVISION` сборщики пакетов не могут обнаружить изменение и, следовательно, не пересоберут пакет.

#### 5.2.3.2. `PORTEPOCH`

Время от времени разработчики программного обеспечения или сопровождающие портов FreeBSD совершают ошибку и выпускают версию своего ПО, которая фактически имеет меньший номер по сравнению с предыдущей. Примером может служить переход с foo-20000801 на foo-1.0 (первая версия будет ошибочно считаться более новой, поскольку число 20000801 больше, чем 1.0).

| Результаты сравнения номеров версий не всегда очевидны. Команда `pkg version` (см. pkg-version(8)) может быть использована для проверки сравнения двух строк с номерами версий. Например:
    % pkg version -t 0.031 0.29
    >
Символ `>` в выводе указывает, что версия 0.031 считается больше, чем версия 0.29, что могло быть неочевидно для сопровождающего.

В таких ситуациях необходимо увеличить `PORTEPOCH`. Если `PORTEPOCH` не равен нулю, он добавляется к имени пакета, как описано в разделе 0 выше. `PORTEPOCH` никогда не должен уменьшаться или сбрасываться до нуля, потому что это приведёт к ошибке при сравнении с пакетом из более ранней эпохи. Например, пакет не будет обнаружен как устаревший. Новый номер версии, `1.0,1` в приведённом выше примере, всё ещё численно меньше предыдущей версии, 20000801, но суффикс `,1` обрабатывается автоматизированными инструментами особым образом и считается большим, чем подразумеваемый суффикс `,0` у предыдущего пакета.

Неправильное удаление или сброс `PORTEPOCH` приводит к бесконечным проблемам. Если приведённое выше объяснение недостаточно ясно, обратитесь к Список рассылки, посвящённый Портам FreeBSD.

Ожидается, что `PORTEPOCH` не будет использоваться для большинства портов, и что разумное использование `DISTVERSION` или аккуратное применение `PORTVERSION` часто может предотвратить необходимость его использования, если будущий выпуск программного обеспечения изменит структуру версий. Однако разработчикам портов FreeBSD следует быть осторожными, когда вендор выпускает релиз без официального номера версии — например, релиз в виде "снимка" кода. Возникает соблазн обозначить такой релиз датой выпуска, что вызовет проблемы, как в примере выше, когда будет сделан новый "официальный" релиз.

Например, если снимок выпущен на дату `20000917`, а предыдущая версия программного обеспечения была `1.2`, не следует использовать `20000917` для `DISTVERSION`. Правильным будет указать `DISTVERSION` как `1.2.20000917` или подобное, чтобы следующая версия, например `1.3`, оставалась численно большей.

#### 5.2.3.3. Пример использования `PORTREVISION` и `PORTEPOCH`

Порт `gtkmumble` версии `0.10` добавлен в коллекцию портов:

    PORTNAME=	gtkmumble
    DISTVERSION=	0.10

`PKGNAME` становится `gtkmumble-0.10`.

Обнаружена уязвимость в безопасности, требующая локального исправления FreeBSD. `PORTREVISION` соответствующим образом увеличивается.

    PORTNAME=	gtkmumble
    DISTVERSION=	0.10
    PORTREVISION=	1

`PKGNAME` принимает значение `gtkmumble-0.10_1`

Выпущена новая версия от поставщика под номером `0.2` (оказывается, автор изначально подразумевал, что `0.10` на самом деле означает `0.1.0`, а не "то, что идёт после 0.9" — увы, теперь уже поздно). Поскольку новая минорная версия `2` численно меньше предыдущей версии `10`, необходимо увеличить `PORTEPOCH`, чтобы вручную заставить систему распознавать новый пакет как "более новый". Так как это новый релиз кода от поставщика, `PORTREVISION` сбрасывается до 0 (или удаляется из Makefile).

    PORTNAME=	gtkmumble
    DISTVERSION=	0.2
    PORTEPOCH=	1

`PKGNAME` становится `gtkmumble-0.2,1`

Следующий выпуск — 0.3. Поскольку `PORTEPOCH` никогда не уменьшается, переменные версий теперь выглядят так:

    PORTNAME=	gtkmumble
    DISTVERSION=	0.3
    PORTEPOCH=	1

`PKGNAME` принимает значение `gtkmumble-0.3,1`

| Если бы `PORTEPOCH` был сброшен в `0` при этом обновлении, пользователь, установивший пакет `gtkmumble-0.10_1`, не увидел бы пакет `gtkmumble-0.3` как более новый, поскольку `3` всё ещё численно меньше, чем `10`. Помните, в этом и заключается вся суть `PORTEPOCH` изначально.

### 5.2.4. `PKGNAMEPREFIX` и `PKGNAMESUFFIX`

Две необязательные переменные, `PKGNAMEPREFIX` и `PKGNAMESUFFIX`, объединяются с `PORTNAME` и `PORTVERSION` для формирования `PKGNAME` в виде `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Убедитесь, что это соответствует нашим рекомендациям по именованию пакетов. В частности, использование дефиса (`-`) в `PORTVERSION` не допускается. Кроме того, если имя пакета содержит часть language- или -compiled.specifics (см. ниже), используйте `PKGNAMEPREFIX` и `PKGNAMESUFFIX` соответственно. Не включайте их в `PORTNAME`.

### 5.2.5. Соглашения о наименовании пакетов

Вот соглашения, которым следует придерживаться при наименовании пакетов. Это сделано для того, чтобы каталог пакетов было легко просматривать, поскольку там уже тысячи пакетов, и пользователи могут отказаться от их использования, если это будет напрягать их глаза!

Имена пакетов имеют формат language_region-name-compiled.specifics-version.numbers.

Имя пакета определяется как `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Убедитесь, что переменные заданы в соответствии с этим форматом.

language_region-

  FreeBSD стремится поддерживать родной язык своих пользователей. Часть language- представляет собой двухбуквенное сокращение естественного языка, определённое стандартом ISO-639, когда порт относится к определённому языку. Примерами являются `ja` для японского, `ru` для русского, `vi` для вьетнамского, `zh` для китайского, `ko` для корейского и `de` для немецкого.

  Если порт относится к определённому региону в языковой зоне, добавьте также двухбуквенный код страны. Например, `en_US` для американского английского и `fr_CH` для швейцарского французского.

  Часть language- задается в `PKGNAMEPREFIX`.

name

  Убедитесь, что название порта и его версия четко разделены и указаны в `PORTNAME` и `DISTVERSION`. Единственная причина, по которой `PORTNAME` может содержать часть версии, — это если вышестоящее распространяемое ПО действительно так названо, как в портах textproc/libxml2 или japanese/kinput2-freewnn. В противном случае `PORTNAME` не может содержать информацию о версии. Довольно нормально, когда несколько портов имеют одинаковый `PORTNAME`, как это делают порты www/apache*; в таком случае разные версии (и разные записи в индексе) различаются значениями `PKGNAMEPREFIX` и `PKGNAMESUFFIX`.

  Существует традиция называть модули `Perl 5`, добавляя префикс `p5-` и заменяя разделитель в виде двойного двоеточия на дефис. Например, модуль `Data::Dumper` становится `p5-Data-Dumper`.

-compiled.specifics

  Если порт может быть собран с различными жёстко заданными значениями по умолчанию (обычно это часть имени каталога в семействе портов), часть -compiled.specifics указывает скомпилированные значения по умолчанию. Дефис является необязательным. Примерами могут служить размер бумаги и единицы измерения шрифтов.

  Часть -compiled.specifics задаётся в `PKGNAMESUFFIX`.

-version.numbers

  Строка версии следует после тире (`-`) и представляет собой разделённый точками список целых чисел и строчных букв латинского алфавита. В частности, не допускается использование дополнительных тире внутри строки версии. Единственное исключение — строка `pl` (означающая "уровень исправления"), которую можно использовать только в случае отсутствия у программного обеспечения номеров основной и дополнительной версий. Если в версии программного обеспечения встречаются строки типа "alpha", "beta", "rc" или "pre", следует взять первую букву и поместить её сразу после точки. Если после таких названий строка версии продолжается, числа следуют за буквой без дополнительной точки между ними (например, `1.0b2`).

  Идея заключается в упрощении сортировки портов за счёт анализа строки версии. В частности, необходимо убедиться, что компоненты номера версии всегда разделены точкой, а если дата является частью строки, использовать формат `dyyyy.mm.dd`, а не `dd.mm.yyyy` или не соответствующий стандарту Y2K формат `yy.mm.dd`. Важно добавлять перед версией букву, в данном случае `d` (от слова "дата"), на случай, если будет выпущена версия с фактическим номером, который численно окажется меньше `yyyy`.

| Название пакета должно быть уникальным среди всех портов в дереве. Убедитесь, что порт с таким же `PORTNAME` ещё не существует, и если он есть, добавьте один из `PKGNAMEPREFIX` или `PKGNAMESUFFIX`.

Вот несколько (реальных) примеров преобразования названия, указанного авторами программного обеспечения, в подходящее имя пакета. В каждой строке указана только одна из переменных `DISTVERSION` или `PORTVERSION`, в зависимости от того, какая используется в Makefile порта:

Таблица 2. Примеры наименования пакетов
Имя дистрибутива | PKGNAMEPREFIX | PORTNAME | PKGNAMESUFFIX | 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.3alpha |  | Версия будет `1.3.a`
es-0.9-beta1 | (пусто) | es | (пусто) | 0.9-beta1 |  | Версия будет `0.9.b1`
mailman-2.0rc3 | (пусто) | mailman | (пусто) | 2.0rc3 |  | Версия будет `2.0.r3`
v3.3beta021.src | (пусто) | tiff | (пусто) |  | 3.3 | Что это вообще было?
tvtwm | (пусто) | tvtwm | (пусто) |  | p11 | Нет версии в имени файла, используйте то, что указано в исходном коде
piewm | (пусто) | piewm | (пусто) | 1.0 |  | Нет версии в имени файла, используйте то, что указано в исходном коде
xvgr-2.10pl1 | (пусто) | xvgr | (пусто) |  | 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

Если в исходном источнике полностью отсутствует информация о версии и маловероятно, что автор когда-либо выпустит новую версию, просто укажите строку версии как `1.0` (как в примере с `piewm` выше). В противном случае, спросите автора или используйте дату выпуска исходного файла в формате `dyyyy.mm.dd` или `dyyyymmdd` в качестве версии.

| Используйте любую букву. Здесь `d` означает дату, если источник — это репозиторий Git, часто используется `g` с последующей датой коммита, также распространено использование `s` для снимка.

## 5.3. Категоризация

### 5.3.1. `CATEGORIES`

При создании пакета он помещается в /usr/ports/packages/All, и ссылки на него создаются в одном или нескольких подкаталогах /usr/ports/packages. Имена этих подкаталогов задаются переменной `CATEGORIES`. Это предназначено для облегчения поиска пакетов пользователем при просмотре большого количества пакетов на FTP-сайте или CDROM. Пожалуйста, ознакомьтесь с текущим списком категорий и выберите подходящие для данного порта.

Этот список также определяет, где в дереве портов будет размещён порт. Если здесь указано несколько категорий, файлы порта должны быть помещены в подкаталог с названием первой категории. Дополнительные сведения о выборе подходящих категорий см. в ниже.

### 5.3.2. Текущий список категорий

Вот текущий список категорий портов. Категории, помеченные звёздочкой (`*`), являются виртуальными — они не имеют соответствующего подкаталога в дереве портов. Они используются только как вторичные категории и исключительно для целей поиска.

| Для невиртуальных категорий в `COMMENT` в Makefile соответствующего подкаталога содержится однострочное описание.

Категория | Описание | Заметки
--- | --- | ---
accessibility | Порты для помощи пользователям с ограниченными возможностями. |
afterstep`*` | Порты для поддержки оконного менеджера AfterStep. |
arabic | Поддержка арабского языка. |
archivers | Инструменты для архивирования. |
astro | Астрономические порты. |
audio | Поддержка звука. |
benchmarks | Утилиты для тестирования производительности. |
biology | Программное обеспечение, связанное с биологией. |
budgie`*` | Программное обеспечение, связанное со средой рабочего стола Budgie. |
cad | Компьютерные средства автоматизированного проектирования. |
chinese | Поддержка китайского языка. |
comms | Программное обеспечение для связи. | В основном программное обеспечение для работы с последовательным портом.
converters | Преобразователи символьных кодировок. |
databases | Базы данных. |
deskutils | Вещи, которые раньше находились на рабочем столе до изобретения компьютеров. |
devel | Средства разработки. | Не размещайте библиотеки здесь только потому, что они являются библиотеками. Они не должны быть в этой категории, если только они действительно не подходят никуда больше.
dns | Программное обеспечение, связанное с DNS. |
docs`*` | Мета-порты для документации FreeBSD. |
editors | Общие редакторы. | Специализированные редакторы помещаются в раздел соответствующих инструментов. Например, редактор математических формул будет помещён в math, а editors будет для него второй категорией.
education`*` | Программное обеспечение для образования. | Это включает приложения, утилиты или игры, разработанные в первую очередь или в значительной степени для помощи пользователю в изучении конкретной темы или обучении в целом. Также сюда входят приложения для создания курсов, приложения для предоставления курсов и приложения для управления классом или школой
elisp`*` | Порты Emacs-lisp. |
emulators | Эмуляторы других операционных систем. | Терминальные эмуляторы не относятся сюда. Основанные на X идут в x11, а текстовые — либо в comms, либо в misc, в зависимости от конкретной функциональности.
enlightenment`*` | Порты, связанные с оконным менеджером Enlightenment. |
filesystems | Файловые системы и связанные утилиты. |
finance | Монетарные, финансовые и связанные с ними приложения. |
french | Поддержка французского языка. |
ftp | Клиентские и серверные утилиты FTP. | Если порт поддерживает как FTP, так и HTTP, поместите его в ftp с дополнительной категорией www.
games | Игры. |
география`*` | Программное обеспечение, связанное с географией. |
german | Поддержка немецкого языка. |
gnome`*` | Порты из проекта GNOME. |
gnustep`*` | Программное обеспечение, связанное со средой рабочего стола GNUstep. |
graphics | Графические утилиты. |
hamradio`*` | Программное обеспечение для радиолюбителей. |
haskell`*` | Программное обеспечение, связанное с языком Haskell. |
hebrew | Поддержка иврита. |
hungarian | Венгерская языковая поддержка. |
irc | Утилиты Internet Relay Chat. |
japanese | Поддержка японского языка. |
java | Программное обеспечение, связанное с языком Java™. | Категория java не должна быть единственной для порта. За исключением портов, непосредственно связанных с языком Java, разработчикам также рекомендуется не использовать java в качестве основной категории для порта.
kde`*` | Порты проекта KDE (общие). |
kde-приложения`*` | Приложения от проекта KDE. |
kde-frameworks`*` | Дополнительные библиотеки от проекта KDE для программирования с использованием Qt. |
kde-plasma`*` | Рабочий стол от проекта KDE. |
kld`*` | Загружаемые модули ядра. |
korean | Поддержка корейского языка. |
lang | Языки программирования. |
linux`*` | Приложения и вспомогательные утилиты Linux. |
lisp`*` | Программное обеспечение, связанное с языком Lisp. |
mail | Почтовое программное обеспечение. |
mate`*` | Порты, связанные с окружением рабочего стола MATE, форком GNOME 2. |
math | Численные расчеты и другие математические утилиты. |
mbone`*` | Приложения MBone. |
misc | Различные утилиты | Вещи, которые не подходят никуда больше. По возможности, попытайтесь найти для порта категорию лучше, чем `misc`, так как порты здесь часто остаются без внимания.
multimedia | Мультимедийное программное обеспечение. |
net | Различное сетевое программное обеспечение. |
net-im | Программное обеспечение для обмена мгновенными сообщениями. |
net-mgmt | Программное обеспечение для управления сетями. |
net-p2p | Одноранговые сетевые приложения. |
сеть-vpn`*` | Виртуальные частные сети. |
news | Программное обеспечение для USENET-новостей. |
parallel`*` | Приложения, работающие с параллелизмом в вычислениях. |
pear`*` | Порты, связанные с PHP-фреймворком Pear. |
perl5`*` | Порты, требующие Perl версии 5 для работы. |
plan9`*` | Различные программы с Plan9. |
polish | Поддержка польского языка. |
ports-mgmt | Порты для управления, установки и разработки портов и пакетов FreeBSD. |
portuguese | Поддержка португальского языка. |
print | Программное обеспечение для печати. | Инструменты для настольных издательских систем (превьюеры и т. д.) также относятся сюда.
python`*` | Программное обеспечение, связанное с языком Python. |
ruby`*` | Программное обеспечение, связанное с языком Ruby. |
rubygems`*` | Порты пакетов RubyGems. |
russian | Поддержка русского языка. |
scheme`*` | Программное обеспечение, связанное с языком Scheme. |
science | Научные порты, которые не входят в другие категории, такие как astro, biology и math. |
security | Средства обеспечения безопасности. |
shells | Командные оболочки. |
spanish`*` | Поддержка испанского языка. |
sysutils | Системные утилиты. |
tcl`*` | Порты, использующие Tcl для запуска. |
textproc | Средства обработки текста. | Он не включает инструменты для настольных издательских систем, которые помещаются в print.
tk`*` | Порты, использующие Tk для работы. |
ukrainian | Поддержка украинского языка. |
vietnamese | Поддержка вьетнамского языка. |
wayland`*` | Порты для поддержки сервера дисплея Wayland. |
windowmaker`*` | Порты для поддержки оконного менеджера Window Maker. |
www | Программное обеспечение, связанное с Всемирной паутиной. | Поддержка языка HTML также относится сюда.
x11 | Система X Window и связанные компоненты. | Эта категория предназначена только для программного обеспечения, которое напрямую поддерживает оконную систему. Не помещайте сюда обычные X-приложения. Большинство из них относятся к другим категориям x11-* (см. ниже).
x11-clocks | Часы X11. |
x11-drivers | Драйверы X11. |
x11-fm | Менеджеры файлов X11. |
x11-fonts | Шрифты и утилиты для работы со шрифтами в X11. |
x11-servers | Серверы X11. |
x11-themes | Темы X11. |
x11-toolkits | Инструментарии X11. |
x11-wm | Оконные менеджеры X11. |
xfce`*` | Порты, связанные с окружением рабочего стола Xfce. |
zope`*` | Zope поддержка. |

### 5.3.3. Выбор подходящей категории

Поскольку многие категории пересекаются, выбор основной категории для порта может быть утомительным. Существует несколько правил, регулирующих этот вопрос. Вот список приоритетов в порядке убывания важности:

- Первая категория должна быть физической (см. выше). Это необходимо для работы упаковки. Виртуальные категории и физические категории могут чередоваться после этого.

- Языковые категории всегда указываются первыми. Например, если порт устанавливает японские шрифты для X11, то строка `CATEGORIES` будет выглядеть так: japanese x11-fonts.

- Конкретные категории перечислены перед менее специфичными. Например, HTML-редактор указывается как www editors, а не наоборот. Также не следует указывать net, если порт принадлежит к любой из категорий irc, mail, news, security или www, так как net подразумевается автоматически.

- x11 используется как вторичная категория только в случае, когда основной категорией указан естественный язык. В частности, не указывайте x11 в строке категории для X-приложений.

- Режимы Emacs размещаются в той же категории портов, что и приложение, поддерживаемое данным режимом, а не в editors. Например, режим Emacs для редактирования исходных файлов какого-либо языка программирования попадает в lang.

- Порты, устанавливающие загружаемые модули ядра, также имеют виртуальную категорию kld в строке `CATEGORIES`. Это одна из вещей, автоматически обрабатываемых при добавлении `USES=kmod`.

- misc не встречается вместе с другими невиртуальными категориями. Если `misc` указан вместе с чем-то ещё в `CATEGORIES`, это означает, что `misc` можно безопасно удалить, а порт разместить только в другом подкаталоге.

- Если порт действительно не подходит никуда больше, поместите его в misc.

Если категория не определена четко, пожалуйста, укажите это в комментарии при отправке порта в баг-трекере, чтобы мы могли обсудить её перед импортом. Как коммиттер, отправьте сообщение в рассылку Список рассылки, посвящённый Портам FreeBSD, чтобы мы сначала обсудили это. Слишком часто новые порты импортируются в неправильную категорию, после чего их сразу же приходится перемещать.

### 5.3.4. Предложение новой категории

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

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

Обоснование этого заключается в том, что такое изменение создает значительный объём работы как для коммиттеров, так и для всех пользователей, которые отслеживают изменения в Коллекции портов. Кроме того, предлагаемые изменения категорий, как правило, вызывают споры. (Возможно, это связано с отсутствием четкого консенсуса относительно того, когда категория становится «слишком большой», а также относительно того, должны ли категории способствовать удобству просмотра (и, следовательно, какое количество категорий было бы идеальным), и так далее.)

Вот процедура:

1. Предложите новую категорию на Список рассылки, посвящённый Портам FreeBSD. Включите подробное обоснование для новой категории, объясните, почему существующие категории недостаточны, и укажите список существующих портов, предлагаемых к перемещению. (Если в Bugzilla есть ожидающие рассмотрения новые порты, которые подходят под эту категорию, также перечислите их.) Если вы являетесь сопровождающим или подающим предложение, укажите это, так как это может помочь в рассмотрении.

2. Участвуйте в обсуждении.

3. Если кажется, что идея находит поддержку, оформите PR, включающий как обоснование, так и список существующих портов, которые необходимо переместить. В идеале, этот PR также должен содержать следующие исправления:

   - Makefile для новых портов после копирования их репозитория

   - Makefile для новой категории

   - Makefile для старых категорий портов

   - Makefile для портов, зависящих от старых портов

   - (для дополнительной оценки включите другие файлы, которые необходимо изменить, в соответствии с процедурой, описанной в Руководстве коммиттера.)

4. Поскольку это затрагивает инфраструктуру портов и включает перемещение и исправление многих портов, а также, возможно, проведение регрессионных тестов на сборочном кластере, назначьте PR для Группа Менеджеров Дерева Портов FreeBSD <portmgr@FreeBSD.org>.

5. Если этот PR будет одобрен, коммиттер должен будет выполнить оставшуюся часть процедуры, описанной в Руководстве коммиттера.

Предложение новой виртуальной категории аналогично описанному выше, но гораздо менее трудоёмко, так как фактически не потребуется перемещать порты. В этом случае единственные патчи, которые нужно включить в PR, — это добавление новой категории в `CATEGORIES` затронутых портов.

### 5.3.5. Предложение о реорганизации всех категорий

Изредка кто-то предлагает реорганизовать категории, используя либо двухуровневую структуру, либо какую-либо другую структуру ключевых слов. На сегодняшний день ни одно из этих предложений не было реализовано, потому что, хотя их очень легко выдвинуть, усилия, необходимые для переработки всей существующей коллекции портов в рамках любой реорганизации, пугают, мягко говоря. Пожалуйста, ознакомьтесь с историей этих предложений в архивах списка рассылки, прежде чем публиковать эту идею. Более того, будьте готовы к тому, что вас попросят предоставить рабочий прототип.

## 5.4. Файлы дистрибутива

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

### 5.4.1. `DISTNAME`

`DISTNAME` — это имя порта, используемое авторами программного обеспечения. По умолчанию `DISTNAME` имеет значение `${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}`, а если не задано, `DISTVERSION` по умолчанию принимает значение `${PORTVERSION}`, поэтому переопределяйте `DISTNAME` только при необходимости. `DISTNAME` используется только в двух случаях. Во-первых, список файлов дистрибутива (`DISTFILES`) по умолчанию имеет значение `${DISTNAME}${EXTRACT_SUFX}`. Во-вторых, ожидается, что файл дистрибутива распакуется в подкаталог с именем `WRKSRC`, который по умолчанию равен work/${DISTNAME}.

Некоторые названия дистрибутивов от поставщиков, которые не соответствуют схеме `${PORTNAME}-${PORTVERSION}`, могут обрабатываться автоматически путем установки `DISTVERSIONPREFIX`, `DISTVERSION` и `DISTVERSIONSUFFIX`. `PORTVERSION` будет автоматически вычисляться из `DISTVERSION`.

| Только одна из переменных `PORTVERSION` и `DISTVERSION` может быть установлена одновременно. Если `DISTVERSION` не определяет корректную `PORTVERSION`, не используйте `DISTVERSION`.

Если схема версий исходного проекта может быть преобразована в схему, совместимую с портами, установите некоторую переменную в версию исходного проекта, не используйте имя переменной `DISTVERSION`. Установите `PORTVERSION` в вычисленную версию на основе созданной переменной и задайте `DISTNAME` соответствующим образом.

Если схема версионирования вышестоящего проекта не может быть легко преобразована в значение, совместимое с портами, установите `PORTVERSION` в разумное значение и задайте `DISTNAME` как `PORTNAME` с дословной версией вышестоящего проекта.

Пример 6. Получение `PORTVERSION` вручную

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`.

Порядок, в котором система портов и pkg будут сортировать версии, проверяется с помощью аргумента `-t` из pkg-version(8):

    % pkg version -t 9.9.9 9.9.9.p1
    > (1)
    % pkg version -t 9.9.9 9.9.9p1
    < (2)

1 | Знак `>` означает, что первый аргумент, переданный в `-t`, больше второго аргумента. `9.9.9` находится после `9.9.9.p1`.
2 | Знак `<` означает, что первый аргумент, переданный в `-t`, меньше второго аргумента. `9.9.9` находится перед `9.9.9p1`.

В файле Makefile порта, например dns/bind99, это достигается с помощью:

    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` напрямую для именования дистрибутивного файла.

Пример 7. Получить `DISTNAME` из `PORTVERSION`

Время от времени имя файла дистрибутива имеет мало отношения или вообще никакого отношения к версии программного обеспечения.

В пакете comms/kermit, в файле дистрибутива присутствует только последний элемент версии:

    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` make(1) возвращает суффикс переменной, в данном случае `304`. Файл дистрибутива корректно создаётся как `cku304-dev20.tar.gz`.

Пример 8. Экзотический случай 1

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

Из пакета audio/libworkman:

    PORTNAME=       libworkman
    PORTVERSION=    1.4
    CATEGORIES=     audio
    MASTER_SITES=   LOCAL/jim
    DISTNAME=       ${PORTNAME}-1999-06-20

Пример 9. Экзотический случай 2

В пакете comms/librs232 файл дистрибутива не имеет версии, поэтому необходимо использовать `DIST_SUBDIR`:

    PORTNAME=       librs232
    PORTVERSION=    20160710
    CATEGORIES=     comms
    MASTER_SITES=   http://www.teuniz.net/RS-232/
    DISTNAME=       RS-232
    DIST_SUBDIR=	${PORTNAME}-${PORTVERSION}

| `PKGNAMEPREFIX` и `PKGNAMESUFFIX` не влияют на `DISTNAME`. Также обратите внимание, что если `WRKSRC` равно ${WRKDIR}/${DISTNAME}, а исходный архив с исходным кодом называется иначе, чем `${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}`, оставьте `DISTNAME` без изменений — определение только `DISTFILES` проще, чем определение и `DISTNAME`, и `WRKSRC` (а возможно, и `EXTRACT_SUFX`).

### 5.4.2. `MASTER_SITES`

Запишите именем каталога из FTP/HTTP-URL, указывающего на исходный tarball, в `MASTER_SITES`. Не забудьте завершающий слэш (/)!

Макросы `make` будут пытаться использовать эту спецификацию для загрузки файла дистрибутива с помощью `FETCH`, если не смогут найти его уже в системе.

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

| `MASTER_SITES` не должен быть пустым. Он должен указывать на реальный сайт, где размещены файлы дистрибутива. Он не может указывать на веб-архивы или кэшированные сайты с файлами дистрибутива FreeBSD. Единственное исключение из этого правила — порты, у которых нет файлов дистрибутива. Например, мета-порты не имеют файлов дистрибутива, поэтому `MASTER_SITES` не нужно задавать.

#### 5.4.2.1. Использование переменных `MASTER_SITE_*`

Для популярных архивов, таких как SourceForge (`SOURCEFORGE`), GNU (`GNU`) или Perl CPAN (`PERL_CPAN`), доступны сокращённые обозначения. `MASTER_SITES` может использовать их напрямую:

    MASTER_SITES=	GNU/make

Старый расширенный формат по-прежнему работает, но все порты были преобразованы в компактный формат. Расширенный формат выглядит следующим образом:

    MASTER_SITES=		${MASTER_SITE_GNU}
    MASTER_SITE_SUBDIR=	make

Эти значения и переменные определены в Mk/bsd.sites.mk. Новые записи добавляются часто, поэтому обязательно проверяйте последнюю версию этого файла перед отправкой порта.

| Для любой переменной `MASTER_SITE_FOO` можно использовать сокращение `FOO`. Например, используйте:
    MASTER_SITES=	FOO
Если требуется `MASTER_SITE_SUBDIR`, используйте следующее:
    MASTER_SITES=	FOO/bar

| Некоторые имена `MASTER_SITE_*` довольно длинные, и для удобства использования были определены сокращения:
Таблица 3. Сокращения для макросов `MASTER_SITE_*`
Макрос | Сокращение
--- | ---
`PERL_CPAN` | `CPAN`
`GITHUB` | `GH`
`GITHUB_CLOUD` | `GHC`
`LIBREOFFICE_DEV` | `LODEV`
`NETLIB` | `NL`
`RUBYGEMS` | `RG`
`SOURCEFORGE` | `SF`

#### 5.4.2.2. Волшебные макросы MASTER_SITES

Существует несколько "волшебных" макросов для популярных сайтов с предсказуемой структурой каталогов. Для них достаточно использовать сокращение, и система автоматически выберет подкаталог. Например, для порта с именем `Stardict`, версии `1.2.3`, размещенного на SourceForge, добавьте следующую строку:

    MASTER_SITES=	SF

подразумевает подкаталог с именем `/project/stardict/stardict/1.2.3`. Если подразумеваемый каталог указан неверно, его можно переопределить:

    MASTER_SITES=	SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION}

Это также можно записать как

    MASTER_SITES=	SF
    MASTER_SITE_SUBDIR=	stardict/WyabdcRealPeopleTTS/${PORTVERSION}

Таблица 4. Волшебные макросы `MASTER_SITES`
Макрос | Предполагаемый подкаталог
--- | ---
`APACHE_COMMONS_BINARIES` | `${PORTNAME:S,commons-,,}`
`APACHE_COMMONS_SOURCE` | `${PORTNAME:S,commons-,,}`
`APACHE_JAKARTA` | `${PORTNAME:S,-,/,}/source`
`BERLIOS` | `${PORTNAME:tl}.berlios`
`PYPI` | `source/${DISTNAME:C/(.).*/\1/}/${DISTNAME:C/(.*)-[0-9].*/\1/}`
`CPAN` | `${PORTNAME:C/-.*//}`
`DEBIAN` | `pool/main/${PORTNAME:C/^((lib)?.).*$/\1/}/${PORTNAME}`
`FARSIGHT` | `${PORTNAME}`
`FESTIVAL` | `${PORTREVISION}`
`GCC` | `releases/${DISTNAME}`
`GENTOO` | `distfiles`
`GIMP` | `${PORTNAME}/${PORTVERSION:R}/`
`GH` | `${GH_ACCOUNT}/${GH_PROJECT}/tar.gz/${GH_TAGNAME}?dummy=/`
`GHC` | `${GH_ACCOUNT}/${GH_PROJECT}/`
`GNOME` | `sources/${PORTNAME}/${PORTVERSION:C/^(\.[0-9]).*/\1/}`
`GNU` | `${PORTNAME}`
`GNUPG` | `${PORTNAME}`
`GNU_ALPHA` | `${PORTNAME}`
`HORDE` | `${PORTNAME}`
`LODEV` | `${PORTNAME}`
`MATE` | `${PORTVERSION:C/^(\.[0-9]).*/\1/}`
`MOZDEV` | `${PORTNAME:tl}`
`NL` | `${PORTNAME}`
`QT` | `archive/qt/${PORTVERSION:R}`
`SAMBA` | `${PORTNAME}`
`SAVANNAH` | `${PORTNAME:tl}`
`SF` | `${PORTNAME:tl}/${PORTNAME:tl}/${PORTVERSION}`

### 5.4.3. `USE_GITHUB`

Если файл дистрибутива получен из определённого коммита или тега на GitHub, для которого нет официально выпущенного файла, существует простой способ автоматически установить правильные значения `DISTNAME` и `MASTER_SITES`.

| По состоянию на 2023-02-21 GitHub объявили, что загрузки исходного кода будут стабильными в течение года. Пожалуйста, переключитесь на ресурсы выпусков (release assets), а если они недоступны, запросите их создание у вышестоящих разработчиков.

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

Таблица 5. `USE_GITHUB` Описание
Переменная | Описание | По умолчанию
--- | --- | ---
`GH_ACCOUNT` | Имя учётной записи пользователя GitHub, который размещает проект | `${PORTNAME}`
`GH_PROJECT` | Название проекта на GitHub | `${PORTNAME}`
`GH_TAGNAME` | Имя тега для загрузки (2.0.1, хэш, …​) Использование имени ветки здесь некорректно. Также можно использовать хэш идентификатора коммита для создания снимка состояния. | `${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}`
`GH_SUBDIR` | Когда программному обеспечению требуется дополнительный файл дистрибутива для извлечения в `${WRKSRC}`, можно использовать эту переменную. Примеры можно найти в Загрузка нескольких файлов из GitHub для получения дополнительной информации. | (отсутствует)
`GH_TUPLE` | `GH_TUPLE` позволяет объединить `GH_ACCOUNT`, `GH_PROJECT`, `GH_TAGNAME` и `GH_SUBDIR` в одну переменную. Формат следующий: account`:`project`:`tagname`:`group`/`subdir. Часть `/`subdir является необязательной. Это полезно, когда требуется получить несколько проектов с GitHub. |

| Не используйте `GH_TUPLE` для файла дистрибутива по умолчанию, так как у него нет значения по умолчанию.

Пример 10. Простое использование `USE_GITHUB`

При попытке создать порт для версии `1.2.7` pkg от пользователя FreeBSD на github, по адресу https://github.com/freebsd/pkg/, файл Makefile в итоге будет выглядеть следующим образом (незначительно сокращено для примера):

    PORTNAME=	pkg
    DISTVERSION=	1.2.7

    USE_GITHUB=	yes
    GH_ACCOUNT=	freebsd

Он автоматически получит `MASTER_SITES` установленным в `GH` и `WRKSRC` в `${WRKDIR}/pkg-1.2.7`.

Пример 11. Более полное использование `USE_GITHUB`

При попытке создать порт для самой последней версии pkg от пользователя FreeBSD на github, по адресу https://github.com/freebsd/pkg/, файл Makefile в итоге выглядит следующим образом (незначительно сокращено для примера):

    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`.

`20140411` — это дата коммита, указанного в `GH_TAGNAME`, а не дата редактирования файла Makefile или дата создания коммита.

Пример 12. Использование `USE_GITHUB` с `DISTVERSIONPREFIX`

Время от времени `GH_TAGNAME` немного отличается от `DISTVERSION`. Например, если версия `1.0.2`, то тег будет `v1.0.2`. В таких случаях можно использовать `DISTVERSIONPREFIX` или `DISTVERSIONSUFFIX`:

    PORTNAME=	foo
    DISTVERSIONPREFIX=	v
    DISTVERSION=	1.0.2

    USE_GITHUB=	yes

Он автоматически установит `GH_TAGNAME` в `v1.0.2`, в то время как `WRKSRC` останется `${WRKDIR}/foo-1.0.2`.

Пример 13. Использование `USE_GITHUB` при отсутствии версий у исходного проекта

Если никогда не было версии вышестоящего репозитория, не изобретайте её, например `0.1` или `1.0`. Создайте порт с `DISTVERSION` в формате `gYYYYMMDD`, где `g` означает Git, а `YYYYMMDD` представляет дату коммита, указанного в `GH_TAGNAME`.

    PORTNAME=	bar
    DISTVERSION=	g20140411

    USE_GITHUB=	yes
    GH_TAGNAME=	c472d66b

Это создаёт схему версионирования, которая увеличивается со временем и всё ещё находится до версии `0`. Подробности об использовании pkg-version(8) для сравнения версий смотрите в этой секции:

    % pkg version -t g20140411 0
    <

Что означает, что использование `PORTEPOCH` не потребуется, если вышестоящий проект решит сократить версии в будущем.

Пример 14. Использование `USE_GITHUB` для доступа к коммиту между двумя версиями

Если текущая версия программного обеспечения использует тег Git, и порт необходимо обновить до более новой промежуточной версии без тега, используйте git-describe(1), чтобы определить версию для использования:

    % 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` — это хеш коммита, на который указывает данная ссылка.

    PORTNAME=	bar
    DISTVERSIONPREFIX=  v
    DISTVERSION=	0.7.3-14
    DISTVERSIONSUFFIX=  -gf0038b1

    USE_GITHUB=	yes

Это создаёт схему версионирования, которая увеличивается со временем (точнее, с коммитами) и не конфликтует с созданием версии `0.7.4`. Подробности об использовании pkg-version(8) для сравнения версий смотрите в этой секции :

    % pkg version -t 0.7.3 0.7.3.14
    <
    % pkg version -t 0.7.3.14 0.7.4
    <

Если запрошенный коммит совпадает с тегом, по умолчанию отображается более короткое описание. Полная версия эквивалентна:

    % git describe --tags c66c71d
    v0.7.3

    % git describe --tags --long c66c71d
    v0.7.3-0-gc66c71d

#### 5.4.3.1. Извлечение нескольких файлов из GitHub

Фреймворк `USE_GITHUB` также поддерживает загрузку нескольких файлов дистрибутива из разных мест в GitHub. Он работает очень похоже на Файлы дистрибуции или патчей из нескольких мест.

В `GH_ACCOUNT`, `GH_PROJECT` и `GH_TAGNAME` добавляются несколько значений. Каждому различному значению присваивается группа. Основное значение может не иметь группы или принадлежать группе `:DEFAULT`. Значение может быть опущено, если оно совпадает со значением по умолчанию, указанным в описании `USE_GITHUB`.

`GH_TUPLE` также можно использовать, когда имеется множество файлов дистрибутива. Это помогает сохранять учётные данные, проект, имя тега и информацию о группе в одном месте.

Для каждой группы создаётся вспомогательная переменная `${WRKSRC_group}`, содержащая каталог, в который был извлечён файл. Переменные `${WRKSRC_group}` могут использоваться для перемещения каталогов во время `post-extract`, добавления в `CONFIGURE_ARGS` или любых других действий, необходимых для корректной сборки программного обеспечения.

| Часть `:group` должна использоваться только для одного файла дистрибутива. Она служит уникальным ключом, и её повторное использование приведёт к перезаписи предыдущих значений.

| Поскольку это всего лишь синтаксический сахар над `DISTFILES` и `MASTER_SITES`, имена групп должны соответствовать ограничениям на имена групп, описанным в Файлы дистрибутивов или патчей из нескольких источников

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

    USE_GITHUB=	nodefault

| При использовании `USE_GITHUB=nodefault` в Makefile необходимо указать `DISTFILES` в его верхнем блоке. Определение должно быть следующим:
    DISTFILES=    ${DISTNAME}${EXTRACT_SUFX}

Пример 15. Использование `USE_GITHUB` с несколькими файлами дистрибутива

Время от времени возникает необходимость загрузить более одного файла дистрибутива. Например, когда вышестоящий репозиторий git использует подмодули. Это можно легко сделать с помощью групп в переменных `GH_*`:

    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. Стандартный берется из foo/foo и имеет версию `1.0.2`. Второй, с группой `icons`, берется из bar/foo-icons и имеет версию `1.0`. Третий берется из bar/foo-contrib и использует Git-коммит `fa579bc`. Файлы дистрибутива называются foo-foo-1.0.2_GH0.tar.gz, bar-foo-icons-1.0_GH0.tar.gz и bar-foo-contrib-fa579bc_GH0.tar.gz.

Все файлы дистрибутива извлекаются в `${WRKDIR}` в соответствующих подкаталогах. Основной файл по-прежнему извлекается в `${WRKSRC}`, в данном случае, ${WRKDIR}/foo-1.0.2. Каждый дополнительный файл дистрибутива извлекается в `${WRKSRC_group}`. Здесь, для группы `icons`, он называется `${WRKSRC_icons}` и содержит ${WRKDIR}/foo-icons-1.0. Файл с группой `contrib` называется `${WRKSRC_contrib}` и содержит `${WRKDIR}/foo-contrib-fa579bc`.

Система сборки программы ожидает найти иконки в подкаталоге ext/icons в её исходниках, поэтому используется `GH_SUBDIR`. `GH_SUBDIR` гарантирует, что ext существует, но ext/icons ещё не существует. Затем он выполняет следующее:

    post-extract:
          @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons

Пример 16. Использование `USE_GITHUB` с несколькими файлами дистрибутива с помощью `GH_TUPLE`

Это функционально эквивалентно Использованию `USE_GITHUB` с несколькими файлами дистрибутива, но с использованием `GH_TUPLE`:

    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` присутствует избыточная информация, так как группировка невозможна.

Пример 17. Как использовать `USE_GITHUB` с подмодулями Git?

Порты, использующие GitHub в качестве вышестоящего репозитория, иногда применяют подмодули. Подробнее см. git-submodule(1).

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

В качестве примера используем пакет finance/moneymanagerex, его репозиторий на GitHub находится по адресу https://github.com/moneymanagerex/moneymanagerex/. В корне репозитория есть файл .gitmodules. Этот файл описывает все подмодули, используемые в данном репозитории, и перечисляет дополнительные необходимые репозитории. Этот файл покажет, какие дополнительные репозитории требуются:

    [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
    [...]

Единственная информация, отсутствующая в этом файле, — это хэш коммита или тег, который следует использовать в качестве версии. Эта информация находится после клонирования репозитория:

    % 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`.

Хотя получение информации из GitHub кажется более простым, данные, полученные с помощью `git submodule status`, будут более информативными. Например, здесь хеш коммита `lib/wxsqlite3` `fb66eb2` соответствует `v3.4.0`. Оба варианта можно использовать взаимозаменяемо, но если доступен тег, предпочтительнее использовать его.

Теперь, когда вся необходимая информация собрана, можно написать Makefile (показаны только строки, связанные с GitHub):

    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 \
    		[...]

### 5.4.4. `USE_GITLAB`

Подобно GitHub, если файл дистрибутива поставляется с gitlab.com или использует программное обеспечение GitLab, эти переменные доступны для использования и могут потребовать установки.

Таблица 6. Описание `USE_GITLAB`
Переменная | Описание | По умолчанию
--- | --- | ---
`GL_SITE` | Название сайта, на котором размещен проект GitLab | https://gitlab.com/
`GL_ACCOUNT` | Имя учётной записи пользователя GitLab, размещающего проект | `${PORTNAME}`
`GL_PROJECT` | Название проекта на GitLab | `${PORTNAME}`
`GL_COMMIT` | Хэш коммита для загрузки. Должен быть полным 160-битным, 40-символьным шестнадцатеричным хэшем sha1. Это обязательная переменная для GitLab. | `(нет)`
`GL_SUBDIR` | Когда программному обеспечению требуется дополнительный файл дистрибутива для извлечения в `${WRKSRC}`, можно использовать эту переменную. Примеры можно найти в Загрузка нескольких файлов из GitLab для получения дополнительной информации. | (отсутствует)
`GL_TUPLE` | `GL_TUPLE` позволяет объединить `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT`, `GL_COMMIT` и `GL_SUBDIR` в одну переменную. Формат записи: сайт`:`учётная запись`:`проект`:`коммит`:`группа`/`подкаталог. Части сайт`:` и `/`подкаталог являются необязательными. Это полезно, когда требуется загрузить данные из нескольких проектов GitLab. |

Пример 18. Простое использование `USE_GITLAB`

Пытаясь создать порт для версии `1.14` библиотеки libsignon-glib от пользователя accounts-sso на gitlab.com, по адресу https://gitlab.com/accounts-sso/libsignon-glib/, файл Makefile будет выглядеть следующим образом для загрузки дистрибутивных файлов:

    PORTNAME=	libsignon-glib
    DISTVERSION=	1.14

    USE_GITLAB=	yes
    GL_ACCOUNT=	accounts-sso
    GL_COMMIT=	e90302e342bfd27bc8c9132ab9d0ea3d8723fd03

Он автоматически получит `MASTER_SITES`, установленный на gitlab.com, и `WRKSRC` на `${WRKDIR}/libsignon-glib-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03`.

Пример 19. Более полное использование `USE_GITLAB`

Более полный пример использования вышеописанного, если порт не имеет версионирования и foobar принадлежит пользователю foo в проекте bar на самостоятельно размещенном сайте GitLab `https://gitlab.example.com/`, тогда Makefile будет выглядеть следующим образом для загрузки дистрибутивных файлов:

    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`.

| `20170906` — это дата коммита, указанного в `GL_COMMIT`, а не дата редактирования файла Makefile или дата коммита в дерево портов FreeBSD.

| Протокол, порт и корневой каталог веб-сервера `GL_SITE` могут быть изменены в той же переменной.

#### 5.4.4.1. Извлечение нескольких файлов из GitLab

Фреймворк `USE_GITLAB` также поддерживает загрузку нескольких файлов дистрибутивов из различных мест GitLab и сайтов, размещённых на GitLab. Он работает очень похоже на Несколько файлов дистрибутивов или патчей из разных местоположений и Загрузка нескольких файлов из GitLab.

В `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT` и `GL_COMMIT` добавляются множественные значения. Каждое уникальное значение назначается группе. Описание `USE_GITLAB`.

`GL_TUPLE` также может использоваться, когда имеется множество файлов дистрибутива. Это помогает хранить информацию о сайте, учётной записи, проекте, коммите и группе в одном месте.

Для каждой группы создаётся вспомогательная переменная `${WRKSRC_group}`, содержащая каталог, в который был извлечён файл. Переменные `${WRKSRC_group}` могут использоваться для перемещения каталогов во время `post-extract`, добавления в `CONFIGURE_ARGS` или любых других действий, необходимых для корректной сборки программного обеспечения.

| Часть `:group` должна использоваться только для одного файла дистрибутива. Она служит уникальным ключом, и её повторное использование приведёт к перезаписи предыдущих значений.

| Поскольку это всего лишь синтаксический сахар над `DISTFILES` и `MASTER_SITES`, имена групп должны соответствовать ограничениям на имена групп, описанным в Файлы дистрибутивов или патчей из нескольких источников

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

    USE_GITLAB=	nodefault

| При использовании `USE_GITLAB=nodefault`, Makefile должен устанавливать `DISTFILES` в своём верхнем блоке. Определение должно быть следующим:
    DISTFILES=    ${DISTNAME}${EXTRACT_SUFX}

Пример 20. Использование `USE_GITLAB` с несколькими файлами дистрибутива

Время от времени возникает необходимость загрузить более одного файла дистрибутива. Например, когда вышестоящий git-репозиторий использует подмодули. Это можно легко сделать с помощью групп в переменных `GL_*`:

    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. По умолчанию файл берется из https://gitlab.com/foo/foo, а коммит — `c189207a55da45305c884fe2b50e086fcad4724b`. Второй файл, из группы `icons`, берется из https://gitlab.example.com:9434/gitlab/bar/foo-icons, а коммит — `ae7368cab1ca7ca754b38d49da064df87968ffe4`. Третий файл берется из https://gitlab.com/bar/foo-contrib, а коммит — `9e4dd76ad9b38f33fdb417a4c01935958d5acd2a`. Файлы дистрибутива называются foo-foo-c189207a55da45305c884fe2b50e086fcad4724b_GL0.tar.gz, bar-foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4_GL0.tar.gz и bar-foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a_GL0.tar.gz.

Все файлы дистрибутива извлекаются в `${WRKDIR}` в соответствующих подкаталогах. Основной файл по-прежнему извлекается в `${WRKSRC}`, в данном случае это ${WRKDIR}/foo-c189207a55da45305c884fe2b50e086fcad4724b-c189207a55da45305c884fe2b50e086fcad4724b. Каждый дополнительный файл дистрибутива извлекается в `${WRKSRC_group}`. Здесь для группы `icons` он называется `${WRKSRC_icons}` и содержит ${WRKDIR}/foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4-ae7368cab1ca7ca754b38d49da064df87968ffe4. Файл группы `contrib` называется `${WRKSRC_contrib}` и содержит `${WRKDIR}/foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a`.

Система сборки программного обеспечения ожидает найти иконки в подкаталоге ext/icons в своих исходниках, поэтому используется `GL_SUBDIR`. `GL_SUBDIR` гарантирует, что ext существует, но ext/icons ещё не существует. Затем она выполняет следующее:

    post-extract:
            @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons

Пример 21. Использование `USE_GITLAB` с несколькими файлами дистрибуции с помощью `GL_TUPLE`

Это функционально эквивалентно Использование `USE_GITLAB` с несколькими файлами дистрибуции, но с использованием `GL_TUPLE`:

    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`, так как группировка невозможна.

### 5.4.5. `EXTRACT_SUFX`

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

Например, если файл дистрибутива был назван foo.tar.gzip вместо более привычного foo.tar.gz, напишите:

    DISTNAME=	foo
    EXTRACT_SUFX=	.tar.gzip

`USES=tar[:xxx]`, `USES=lha` или `USES=zip` автоматически устанавливают `EXTRACT_SUFX` в наиболее распространённые расширения архивов при необходимости, подробнее см. Использование макросов `USES`. Если ни один из них не задан, `EXTRACT_SUFX` по умолчанию принимает значение `.tar.gz`.

| Как `EXTRACT_SUFX` используется только в `DISTFILES`, следует задавать только один из них.

### 5.4.6. `DISTFILES`

Иногда названия файлов для загрузки не имеют ничего общего с именем порта. Например, файл может называться source.tar.gz или подобным образом. В других случаях исходный код приложения может быть разбит на несколько различных архивов, все из которых необходимо загрузить.

Если это так, установите `DISTFILES` как список разделённых пробелами файлов, которые необходимо загрузить.

    DISTFILES=	source1.tar.gz source2.tar.gz

Если явно не задано, `DISTFILES` по умолчанию равно `${DISTNAME}${EXTRACT_SUFX}`.

### 5.4.7. `EXTRACT_ONLY`

Если необходимо извлечь только некоторые из `DISTFILES` — например, один из них является исходным кодом, а другой — несжатым документом — укажите имена файлов, которые нужно извлечь, в `EXTRACT_ONLY`.

    DISTFILES=	source.tar.gz manual.html
    EXTRACT_ONLY=	source.tar.gz

Если ни один из `DISTFILES` не требует распаковки, установите `EXTRACT_ONLY` в пустую строку.

    EXTRACT_ONLY=

### 5.4.8. `PATCHFILES`

Если порт требует дополнительных исправлений, доступных через FTP или HTTP, установите `PATCHFILES` в имена файлов, а `PATCH_SITES` — в URL каталога, содержащего их (формат такой же, как у `MASTER_SITES`).

Если патч не относится к корню исходного дерева (то есть к `WRKSRC`), потому что содержит дополнительные пути, установите `PATCH_DIST_STRIP` соответствующим образом. Например, если все пути в патче имеют дополнительный префикс `foozolix-1.0/` перед именами файлов, задайте `PATCH_DIST_STRIP=-p1`.

Не беспокойтесь, если патчи сжаты; они будут автоматически распакованы, если их имена заканчиваются на .Z, .gz, .bz2 или .xz.

Если патч распространяется вместе с другими файлами, такими как документация, в сжатом tarball, использование `PATCHFILES` невозможно. В таком случае добавьте имя и расположение tarball с патчами в `DISTFILES` и `MASTER_SITES`. Затем используйте `EXTRA_PATCHES`, чтобы указать на эти файлы, и bsd.port.mk автоматически применит их. В частности, не копируйте файлы патчей в ${PATCHDIR}. Этот каталог может быть недоступен для записи.

| Если есть несколько патчей и для них требуются разные значения параметра strip, его можно добавить рядом с именем патча в `PATCHFILES`, например:
    PATCHFILES=	patch1 patch2:-p1
Это не конфликтует с функцией группировки мастер-сайтов, добавление группы также работает:
    PATCHFILES=	patch2:-p1:source2

| Tarball уже будет распакован вместе с обычными исходными кодами, поэтому нет необходимости явно его распаковывать, если это обычный сжатый tarball. Будьте особенно осторожны, чтобы не перезаписать существующие файлы в этом каталоге при ручной распаковке. Также не забудьте добавить команду для удаления скопированного патча в цель `pre-clean`.

### 5.4.9. Несколько файлов дистрибутивов или исправлений из нескольких местоположений

(Считайте, что это несколько «продвинутая тема»; тем, кто впервые читает этот документ, возможно, стоит сначала пропустить этот раздел).

Этот раздел содержит информацию о механизме загрузки, известном как `MASTER_SITES:n` и `MASTER_SITES_NN`. Мы будем называть этот механизм `MASTER_SITES:n`.

Небольшая предыстория. В OpenBSD есть удобная функция внутри `DISTFILES` и `PATCHFILES`, которая позволяет добавлять постфикс `:n` к файлам и патчам. Здесь `n` может быть любым словом, содержащим `[0-9a-zA-Z_]`, и обозначать группу. Например:

    DISTFILES=	alpha:0 beta:1

В OpenBSD файл дистрибутива alpha будет связан с переменной `MASTER_SITES0`, а не с нашей общей `MASTER_SITES`, а beta — с `MASTER_SITES1`.

Это очень интересная функция, которая может сократить бесконечные поиски нужного сайта для загрузки.

Представьте 2 файла в `DISTFILES` и 20 сайтов в `MASTER_SITES`, причём сайты медленные как черепаха, где beta есть на всех сайтах из `MASTER_SITES`, а alpha можно найти только на 20-м сайте. Было бы так обидно проверять их все, если бы сопровождающий знал это заранее, не так ли? Не самое лучшее начало для чудесных выходных!

Теперь, когда идея понятна, представьте больше `DISTFILES` и больше `MASTER_SITES`. Безусловно, наш "мастер по исследованию distfiles" оценил бы снижение нагрузки на сеть, которое это принесло бы.

В следующих разделах будет приведена информация о реализации этой идеи в FreeBSD. Мы немного улучшили концепцию OpenBSD.

| Имена групп не могут содержать дефисы (`-`), более того, они не могут содержать любые символы вне диапазона `[a-zA-Z0-9_]`. Это связано с тем, что, хотя make(1) допускает использование имён переменных с дефисами, sh(1) — нет.

#### 5.4.9.1. Упрощенная информация

В этом разделе объясняется, как быстро настроить детализированное получение нескольких файлов дистрибутивов и патчей с разных сайтов и подкаталогов. Здесь описывается случай упрощённого использования `MASTER_SITES:n`. Этого будет достаточно для большинства сценариев. Более подробная информация доступна в Подробная Информация.

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

Для поддержки этого, каждая запись в `DISTFILES` может сопровождаться двоеточием и "именем группы". Затем каждый сайт, указанный в `MASTER_SITES`, сопровождается двоеточием и группой, которая указывает, какие файлы дистрибутива загружаются с данного сайта.

Например, рассмотрим приложение, исходный код которого разделён на две части: source1.tar.gz и source2.tar.gz, которые необходимо загрузить с двух разных сайтов. В Makefile порта будут присутствовать строки, подобные Упрощённое использование `MASTER_SITES:n` с одним файлом на сайт.

Пример 22. Упрощённое использование `MASTER_SITES:n` с одним файлом на сайт

    MASTER_SITES=	ftp://ftp1.example.com/:source1 \
    		http://www.example.com/:source2
    DISTFILES=	source1.tar.gz:source1 \
    		source2.tar.gz:source2

Несколько файлов дистрибутивов могут принадлежать одной группе. Продолжая предыдущий пример, предположим, что существует третий файл дистрибутива source3.tar.gz, который загружается с `ftp.example2.com`. Тогда Makefile будет записан, как показано в Упрощённое использование `MASTER_SITES:n` с несколькими файлами на один сайт.

Пример 23. Упрощённое использование `MASTER_SITES:n` с несколькими файлами на одном сайте

    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

#### 5.4.9.2. Подробная информация

Хорошо, значит, предыдущий пример не отражал потребности нового порта? В этом разделе мы подробно объясним, как работает механизм детализированного получения `MASTER_SITES:n` и как его можно использовать.

1. Элементы могут иметь постфикс `:n`, где n — это ``, то есть _n_ концептуально может быть любой буквенно-цифровой строкой, но пока мы ограничим её `[a-zA-Z_][0-9a-zA-Z_]`.

   Более того, сравнение строк чувствительно к регистру; то есть, `n` отличается от `N`.

   Однако эти слова не могут использоваться для постфиксных целей, так как имеют специальное значение: `default`, `all` и `ALL` (они используются внутри системы, см. ii). Кроме того, `DEFAULT` является словом специального назначения (проверьте пункт 3).

2. Элементы с постфиксом `:n` принадлежат группе `n`, `:m` — группе `m` и так далее.

3. Элементы без постфикса не принадлежат к группам, все они относятся к специальной группе `DEFAULT`. Элементы с постфиксом `DEFAULT` избыточны, за исключением случаев, когда элемент одновременно принадлежит и к `DEFAULT`, и к другим группам (см. пункт 5).

   Эти примеры эквивалентны, но первый предпочтительнее:

       MASTER_SITES=	alpha

       MASTER_SITES=	alpha:DEFAULT

4. Группы не являются исключительными, элемент может принадлежать нескольким разным группам одновременно, а группа может содержать несколько разных элементов или не содержать их вовсе.

5. Когда элемент принадлежит нескольким группам одновременно, используйте оператор запятую (`,`).

   Вместо повторения несколько раз, каждый раз с разным постфиксом, мы можем перечислить несколько групп сразу в одном постфиксе. Например, `:m,n,o` обозначает элемент, принадлежащий группам `m`, `n` и `o`.

   Все эти примеры эквивалентны, но последний является предпочтительным:

       MASTER_SITES=	alpha alpha:SOME_SITE

       MASTER_SITES=	alpha:DEFAULT alpha:SOME_SITE

       MASTER_SITES=	alpha:SOME_SITE,DEFAULT

       MASTER_SITES=	alpha:DEFAULT,SOME_SITE

6. Все сайты в заданной группе сортируются согласно `MASTER_SORT_AWK`. Все группы в `MASTER_SITES` и `PATCH_SITES` также сортируются.

7. Семантика групп может использоваться в любых переменных `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR`, `PATCH_SITE_SUBDIR`, `DISTFILES` и `PATCHFILES` согласно следующему синтаксису:

   1. Все элементы `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`. См. оба раздела Подробное использование `MASTER_SITES:n` в `MASTER_SITE_SUBDIR` и Подробное использование `MASTER_SITES:n` с оператором запятая.

      Пример 24. Подробное использование `MASTER_SITES:n` в `MASTER_SITE_SUBDIR`

          MASTER_SITE_SUBDIR=	old:n new/:NEW

      - Каталоги в группе `DEFAULT` → old:n

      - Каталоги в группе `NEW` → new

      Пример 25. Подробное использование `MASTER_SITES:n` с оператором запятая, несколькими файлами, сайтами и подкаталогами

          MASTER_SITES=	http://site1/%SUBDIR%/ http://site2/:DEFAULT \
          		http://site3/:group3 http://site4/:group4 \
          		http://site5/:group5 http://site6/:group6 \
          		http://site7/:DEFAULT,group6 \
          		http://site8/%SUBDIR%/:group6,group7 \
          		http://site9/:group8
          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

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

      - file1 будет загружен из

        - `MASTER_SITE_OVERRIDE`

        - http://site1/directory-trial:1/

        - http://site1/directory-one/

        - http://site1/directory/

        - http://site2/

        - http://site7/

        - `MASTER_SITE_BACKUP`

      - file2 будет загружен точно так же, как file1, поскольку они оба принадлежат к одной и той же группе

        - `MASTER_SITE_OVERRIDE`

        - http://site1/directory-trial:1/

        - http://site1/directory-one/

        - http://site1/directory/

        - http://site2/

        - http://site7/

        - `MASTER_SITE_BACKUP`

      - file3 будет загружен из

        - `MASTER_SITE_OVERRIDE`

        - http://site3/

        - `MASTER_SITE_BACKUP`

      - file4 будет загружен из

        - `MASTER_SITE_OVERRIDE`

        - http://site4/

        - http://site5/

        - http://site6/

        - http://site7/

        - http://site8/directory-one/

        - `MASTER_SITE_BACKUP`

      - file5 будет загружен из

        - `MASTER_SITE_OVERRIDE`

        - `MASTER_SITE_BACKUP`

      - file6 будет получен из

        - `MASTER_SITE_OVERRIDE`

        - http://site8/

        - `MASTER_SITE_BACKUP`

8. Как сгруппировать один из специальных макросов из bsd.sites.mk, например, SourceForge (`SF`)?

   Это максимально упрощено. См. Подробное использование `MASTER_SITES:n` с SourceForge (`SF`).

   Пример 26. Подробное использование `MASTER_SITES:n` с SourceForge (`SF`)

       MASTER_SITES=	http://site1/ SF/something/1.0:sourceforge,TEST
       DISTFILES=	something.tar.gz:sourceforge

   something.tar.gz будет загружен со всех сайтов в пределах SourceForge.

9. Как использовать это с `PATCH*`?

   Все примеры были выполнены с `MASTER*`, но они работают точно так же для `PATCH*`, как можно увидеть в Упрощённое использование `MASTER_SITES:n` с `PATCH_SITES`.

   Пример 27. Упрощённое использование `MASTER_SITES:n` с `PATCH_SITES`

       PATCH_SITES=	http://site1/ http://site2/:test
       PATCHFILES=	patch1:test

#### 5.4.9.3. Что меняется для портов? Что остаётся неизменным?

1. Все текущие порты остаются без изменений. Функция `MASTER_SITES:n` активируется только при наличии элементов с постфиксом `:n`, соответствующих указанным выше синтаксическим правилам, в частности, как показано в пункте 7.

2. Порты сохраняют те же цели: `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`. Проверьте Подробное использование `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`. Кроме того, прямая проверка не гарантирует работу в будущих версиях. Для получения дополнительной информации об этих новых целях портов см. пункт B.

3. Новые цели портов

   1. Существуют цели `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`, и так далее.

   2. Существуют новые цели `master-sites-all` и `patch-sites-all`, которые выполняют работу старых `master-sites` и `patch-sites`. Они возвращают элементы всех групп, как если бы они все принадлежали одной группе, с оговоркой, что перечисляется столько же `MASTER_SITE_BACKUP` и `MASTER_SITE_OVERRIDE`, сколько определено групп в `DISTFILES` или `PATCHFILES`; соответственно для `master-sites-all` и `patch-sites-all`.

### 5.4.10. `DIST_SUBDIR`

Не допускайте захламления портом каталога /usr/ports/distfiles. Если порт требует загрузки большого количества файлов или содержит файл с именем, которое может конфликтовать с другими портами (например, Makefile), установите `DIST_SUBDIR` в имя порта (подойдут `${PORTNAME}` или `${PKGNAMEPREFIX}${PORTNAME}`). Это изменит `DISTDIR` со значения по умолчанию /usr/ports/distfiles на /usr/ports/distfiles/${DIST_SUBDIR}, фактически помещая все необходимые для порта файлы в этот подкаталог.

Также будет проверяться подкаталог с тем же именем на основном резервном сайте по адресу http://distcache.FreeBSD.org (Явное указание `DISTDIR` в Makefile не решит эту задачу, поэтому используйте `DIST_SUBDIR`.)

| Это не влияет на сайты в `MASTER_SITES`, определённые в Makefile.

## 5.5. `MAINTAINER`

Установите здесь свой адрес электронной почты. Пожалуйста. :-)

Только один адрес без комментария допускается в качестве значения `MAINTAINER`. Используемый формат: `user@hostname.domain`. Пожалуйста, не включайте в эту запись описательный текст, например, настоящее имя. Это только вносит путаницу в инфраструктуру Ports и большинство инструментов, которые её используют.

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

| Сопровождающий добровольно поддерживает порт в рабочем состоянии. Сопровождающие несут основную ответственность за свои порты, но не имеют исключительных прав на них. Порты существуют для пользы сообщества и, по сути, принадлежат сообществу. Это означает, что люди, не являющиеся сопровождающими, также могут вносить изменения в порт. Крупные изменения в коллекции портов могут потребовать правок во многих портах. Команда управления портами FreeBSD или члены других команд могут изменять порты для исправления проблем с зависимостями или других проблем, таких как обновление версии динамической библиотеки. Некоторые типы исправлений имеют "автоматическое согласование" от Группа Менеджеров Дерева Портов FreeBSD <portmgr@FreeBSD.org>, что позволяет любому коммиттеру исправлять эти категории проблем в любом порте. Такие исправления не требуют одобрения от сопровождающего. Автоматическое согласование для большинства портов применяется к исправлениям, таким как изменения инфраструктуры, или тривиальным и проверенным исправлениям сборки и выполнения. Текущий список доступен в разделе Портов Руководства коммиттера.

Другие изменения в порте будут отправлены сопровождающему на проверку и утверждение перед внесением. Если сопровождающий не отвечает на запрос об обновлении в течение двух недель (за исключением основных государственных праздников), это считается превышением времени ожидания сопровождающего, и обновление может быть внесено без его явного одобрения. Если сопровождающий не отвечает в течение трёх месяцев или если произошло три последовательных превышения времени ожидания, то сопровождающий считается отсутствующим без уведомления, и все его порты могут быть возвращены в общий пул. Исключениями являются порты, сопровождаемые Группа Менеджеров Дерева Портов FreeBSD <portmgr@FreeBSD.org> или Команда Офицера Безопасности <security-officer@FreeBSD.org>. Никакие несанкционированные изменения не могут быть внесены в порты, сопровождаемые этими группами.

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

Группа Менеджеров Дерева Портов FreeBSD <portmgr@FreeBSD.org> оставляет за собой право отозвать или изменить права сопровождающего по любой причине, а Команда Офицера Безопасности <security-officer@FreeBSD.org> оставляет за собой право отозвать или изменить права сопровождающего по соображениям безопасности.

## 5.6. `COMMENT`

Комментарий — это однострочное описание порта, отображаемое командой `pkg info`. При составлении придерживайтесь следующих правил:

1. Строка COMMENT должна быть не длиннее 70 символов.

2. Не включайте название пакета или номер версии программного обеспечения.

3. Комментарий должен начинаться с заглавной буквы и заканчиваться без точки.

4. Не начинайте с неопределённого артикля (то есть A или An).

5. Пишите названия с заглавной буквы, например: Apache, JavaScript или Perl.

6. Используйте запятую для списков слов: "green, red, and blue."

7. Проверяйте на наличие орфографических ошибок.

Вот пример:

    COMMENT=	Cat chasing a mouse all over the screen

Переменная COMMENT следует сразу за переменной MAINTAINER в файле Makefile.

## 5.7. Веб-сайт проекта

Каждый порт должен указывать на веб-сайт, предоставляющий дополнительную информацию о программном обеспечении.

Везде, где это возможно, следует использовать официальный сайт проекта, поддерживаемый разработчиками программного обеспечения.

    WWW=		https://ffmpeg.org/

Но это также может быть каталог или ресурс в репозитории исходного кода:

    WWW=		https://sourceforge.net/projects/mpd/

Переменная WWW следует сразу за переменной COMMENT в файле Makefile.

Если один и тот же контент доступен по HTTP и HTTPS, следует использовать URL, начинающийся с `https://`. Если URI является корнем веб-сайта или каталогом, он должен заканчиваться косой чертой.

Эта информация ранее размещалась в последней строке файла pkg-descr. Она была перенесена в Makefile для удобства обслуживания и обработки. Наличие строки `WWW:` в конце файла pkg-descr считается устаревшим.

## 5.8. Лицензии

Каждый порт должен содержать документацию о лицензии, под которой он распространяется. Если лицензия не одобрена OSI, необходимо также указать любые ограничения на распространение.

### 5.8.1. `LICENSE`

Краткое название лицензии или лицензий, если применяется более одной лицензии.

Если это одна из лицензий, перечисленных в Предопределённый список лицензий, можно задать только переменные `LICENSE_FILE` и `LICENSE_DISTFILES`.

Если это лицензия, которая не определена в рамках портов (см. Список предопределённых лицензий), необходимо задать `LICENSE_PERMS` и `LICENSE_NAME`, а также `LICENSE_FILE` или `LICENSE_TEXT`. Также можно задать `LICENSE_DISTFILES` и `LICENSE_GROUPS`, но это не обязательно.

Предопределённые лицензии показаны в Список предопределённых лицензий. Текущий список всегда доступен в Mk/bsd.licenses.db.mk.

Пример 28. Простейшее использование, предопределённые лицензии

Когда в файле README какого-либо программного обеспечения указано: «Данное программное обеспечение распространяется на условиях GNU Lesser General Public License, опубликованной Free Software Foundation; либо версии 2.1 Лицензии, либо (по вашему выбору) любой более поздней версии», но сам файл лицензии не предоставлен, используйте следующее:

    LICENSE=	LGPL21+

Когда программное обеспечение предоставляет файл лицензии, используйте это:

    LICENSE=	LGPL21+
    LICENSE_FILE=	${WRKSRC}/COPYING

Для предопределённых лицензий права по умолчанию: `dist-mirror dist-sell pkg-mirror pkg-sell auto-accept`.

Таблица 7. Предопределённый список лицензий
Короткое имя | Имя | Группа | Разрешения
--- | --- | --- | ---
`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` | (по умолчанию)

### 5.8.2. `LICENSE_PERMS` и `LICENSE_PERMS_NAME_`

Разрешения. Используйте `none`, если пусто.

Список разрешений лицензии

`dist-mirror`

  Разрешается распространение дистрибутивных файлов. Дистрибутивные файлы будут добавлены в CDN `MASTER_SITE_BACKUP` FreeBSD.

`no-dist-mirror`

  Распространение дистрибутивных файлов запрещено. Это эквивалентно установке `RESTRICTED`. Дистрибутивные файлы не будут добавлены в CDN `MASTER_SITE_BACKUP` FreeBSD.

`dist-sell`

  Продажа файлов дистрибутива разрешена. Файлы дистрибутива будут присутствовать на образах установщика.

`no-dist-sell`

  Продажа файлов дистрибутива запрещена. Это эквивалентно установке `NO_CDROM`.

`pkg-mirror`

  Свободное распространение пакета разрешено. Пакет будет распространяться через CDN пакетов FreeBSD https://pkg.freebsd.org/.

`no-pkg-mirror`

  Свободное распространение пакета запрещено. Эквивалентно установке `NO_PACKAGE`. Пакет не будет распространяться через FreeBSD CDN для пакетов https://pkg.freebsd.org/.

`pkg-sell`

  Продажа пакета разрешена. Пакет будет присутствовать на образах установщика.

`no-pkg-sell`

  Продажа пакета запрещена. Это эквивалентно установке `NO_CDROM`. Пакет не будет присутствовать на образах установщика.

`auto-accept`

  Лицензия принимается по умолчанию. Запросы на принятие лицензии не отображаются, если пользователь не определил `LICENSES_ASK`. Используйте это, если в лицензии не указано, что пользователь должен принять условия лицензии.

`no-auto-accept`

  Лицензия не принимается по умолчанию. Пользователь всегда будет запрошен на подтверждение принятия данной лицензии. Это должно использоваться, если лицензия требует, чтобы пользователь принял её условия.

Когда присутствуют и `permission`, и `no-permission`, то `no-permission` отменяет `permission`.

Когда `permission` отсутствует, это считается как `no-permission`.

| Некоторые отсутствующие разрешения могут сделать порт (и все зависящие от него порты) непригодными для использования пользователями пакетов: Порт без разрешения `auto-accept` никогда не будет собран, и все зависящие от него порты будут проигнорированы. Порт без разрешения `pkg-mirror`, а также любые порты, зависящие от него, будут удалены после сборки, что гарантирует их отсутствие в дистрибуции.

Пример 29. Нестандартная лицензия

Прочитайте условия лицензии и переведите их, используя доступные разрешения.

    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

Пример 30. Стандартные и нестандартные лицензии

Прочитайте условия лицензии и укажите их, используя доступные разрешения. В случае сомнений обратитесь за разъяснениями на Список рассылки, посвящённый Портам FreeBSD.

    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. Файлы дистрибутива и пакеты не будут доступны в образах установщика.

### 5.8.3. `LICENSE_GROUPS` и `LICENSE_GROUPS_NAME`

Группы, к которым принадлежит лицензия.

Список предопределённых групп лицензий

`FSF`

  Одобрено Free Software Foundation, см. Команда по лицензированию и соответствию FSF.

`GPL`

  Совместимые с GPL

`OSI`

  Одобрено OSI, см. страницу Открытых лицензий.

`COPYFREE`

  Соответствует определению стандарта Copyfree, см. страницу лицензий Copyfree.

`FONTS`

  Лицензии на шрифты

### 5.8.4. `LICENSE_NAME` и `LICENSE_NAME_NAME`

Полное название лицензии.

Пример 31. `LICENSE_NAME`

    LICENSE=        UNRAR
    LICENSE_NAME=   UnRAR License
    LICENSE_FILE=   ${WRKSRC}/license.txt
    LICENSE_PERMS=  dist-mirror dist-sell pkg-mirror pkg-sell auto-accept

### 5.8.5. `LICENSE_FILE` и `LICENSE_FILE_NAME`

Полный путь к файлу, содержащему текст лицензии, обычно ${WRKSRC}/some/file. Если файл отсутствует в дистрибутиве, а его содержимое слишком длинное для размещения в `LICENSE_TEXT`, поместите его в новый файл в ${FILESDIR}.

Пример 32. `LICENSE_FILE`

    LICENSE=	GPLv3+
    LICENSE_FILE=	${WRKSRC}/COPYING

### 5.8.6. `LICENSE_TEXT` и `LICENSE_TEXT_NAME`

Текст для использования в качестве лицензии. Полезно, когда лицензия отсутствует в файлах дистрибутива и её текст краток.

Пример 33. `LICENSE_TEXT`

    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

### 5.8.7. `LICENSE_DISTFILES` и `LICENSE_DISTFILES_NAME`

Файлы дистрибутива, к которым применяются лицензии. По умолчанию — все файлы дистрибутива.

Пример 34. `LICENSE_DISTFILES`

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

    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

### 5.8.8. `LICENSE_COMB`

Установите значение `multi`, если применяются все лицензии. Установите значение `dual`, если применяется любая из лицензий. По умолчанию используется значение `single`.

Пример 35. Двойные лицензии

Когда порт содержит указание «Это программное обеспечение может распространяться под GNU General Public License или Artistic License», это означает, что можно использовать любую из этих лицензий. Используйте следующее:

    LICENSE=	ART10 GPLv1
    LICENSE_COMB=   dual

Если предоставлены файлы лицензий, используйте это:

    LICENSE=	ART10 GPLv1
    LICENSE_COMB=   dual
    LICENSE_FILE_ART10=     ${WRKSRC}/Artistic
    LICENSE_FILE_GPLv1=     ${WRKSRC}/Copying

Пример 36. Множественные лицензии

Если часть порта имеет одну лицензию, а другая часть — другую, используйте `multi`:

    LICENSE=	GPLv2 LGPL21+
    LICENSE_COMB=	multi

## 5.9. `PORTSCOUT`

Portscout — это автоматизированная утилита проверки distfile для Коллекции портов FreeBSD, подробно описанная в Portscout: сканирование distfile портов FreeBSD.

`PORTSCOUT` определяет специальные условия, в рамках которых работа сканера дистрибутивных файлов Portscout ограничена.

Ситуации, когда установлена переменная `PORTSCOUT`, включают:

- Когда необходимо игнорировать distfiles для определённых версий. Например, чтобы исключить версию 8.2 и версию 8.3 из проверок версий distfiles, так как известно, что они неработоспособны, добавьте:

      PORTSCOUT=	skipv:8.2,8.3

- Когда проверки версий distfile необходимо полностью отключить. Например, если порт больше не будет обновляться, добавьте:

      PORTSCOUT=	ignore:1

- Когда необходимо проверять конкретные версии или определённые мажорные и минорные редакции distfile. Например, если нужно отслеживать только версию 0.6.4, потому что более новые версии имеют проблемы совместимости с FreeBSD, добавьте:

      PORTSCOUT=	limit:^0\.6\.4

- Когда URL-адреса, перечисляющие доступные версии, отличаются от URL-адресов загрузки. Например, чтобы ограничить проверку версий distfile страницей загрузки для пакета: databases/pgtune добавьте:

      PORTSCOUT=	site:http://www.renpy.org/dl/release/

## 5.10. Зависимости

Многие порты зависят от других портов. Это очень удобная особенность большинства Unix-подобных операционных систем, включая FreeBSD. Несколько портов могут использовать общую зависимость вместо того, чтобы включать эту зависимость в каждый порт или пакет, который в ней нуждается. Существует семь переменных, которые можно использовать для обеспечения наличия всех необходимых компонентов на машине пользователя. Также есть предопределённые переменные зависимостей для распространённых случаев и несколько дополнительных для управления поведением зависимостей.

| Когда у программного обеспечения есть дополнительные зависимости, предоставляющие дополнительные возможности, основные зависимости, перечисленные в `*_DEPENDS`, должны включать те дополнительные зависимости, которые будут полезны большинству пользователей. Основные зависимости никогда не должны быть "минимальным" набором зависимостей. Цель состоит не в том, чтобы включить все возможные зависимости. Включайте только те, которые будут полезны большинству людей.

### 5.10.1. `LIB_DEPENDS`

Эта переменная определяет разделяемые библиотеки, от которых зависит данный порт. Это список кортежей вида `lib:dir`, где `lib` — имя разделяемой библиотеки, а `dir` — каталог, в котором её следует искать, если она недоступна. Например,

    LIB_DEPENDS=   libjpeg.so:graphics/jpeg

проверит наличие общей библиотеки jpeg с любой версией и перейдет в подкаталог graphics/jpeg дерева портов, чтобы собрать и установить её, если она не найдена.

Зависимость проверяется дважды: один раз внутри цели `build` и затем внутри цели `install`. Также имя зависимости добавляется в пакет, чтобы `pkg install` (см. pkg-install(8)) автоматически установил её, если её нет в системе пользователя.

### 5.10.2. `RUN_DEPENDS`

Эта переменная определяет исполняемые файлы или файлы, от которых зависит порт во время выполнения. Это список кортежей `path:dir`[:`target`], где `path` — это имя исполняемого файла или файла, dir — каталог, в котором его следует искать, если он недоступен, а target — цель, которую нужно вызвать в этом каталоге. Если path начинается с косой черты (`/`), он считается файлом, и его существование проверяется с помощью `test -e`; в противном случае предполагается, что это исполняемый файл, и `which -s` используется для проверки наличия программы в пути поиска.

Например,

    RUN_DEPENDS=	${LOCALBASE}/news/bin/innd:news/inn \
    		xmlcatmgr:textproc/xmlcatmgr

проверит, существует ли файл или каталог /usr/local/news/bin/innd, и соберет и установит его из подкаталога news/inn дерева портов, если он не найден. Также будет проверено, находится ли исполняемый файл `xmlcatmgr` в пути поиска, и если он не найден, будет выполнен переход в textproc/xmlcatmgr для сборки и установки.

| В этом случае `innd` является исполняемым файлом; если исполняемый файл находится в месте, которое не ожидается в пути поиска, используйте полный путь.

| Официальный путь поиска `PATH`, используемый в кластере сборки портов
    /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

Зависимость проверяется внутри цели `install`. Также имя зависимости добавляется в пакет, чтобы команда `pkg install` (см. pkg-install(8)) автоматически установила её, если она отсутствует в системе пользователя. Часть target может быть опущена, если она совпадает с `DEPENDS_TARGET`.

Довольно распространённая ситуация, когда `RUN_DEPENDS` буквально совпадает с `BUILD_DEPENDS`, особенно если портируемое программное обеспечение написано на скриптовом языке или требует одинаковой среды для сборки и выполнения. В этом случае возникает соблазн и интуитивное желание напрямую присвоить одно другому:

    RUN_DEPENDS=	${BUILD_DEPENDS}

Однако такое присваивание может загрязнить зависимости во время выполнения записями, не определёнными в оригинальном `BUILD_DEPENDS` порта. Это происходит из-за ленивого вычисления присваивания переменных в make(1). Рассмотрим Makefile с `USE_*`, которые обрабатываются ports/Mk/bsd.*.mk для добавления начальных зависимостей сборки. Например, `USES= gmake` добавляет devel/gmake в `BUILD_DEPENDS`. Чтобы предотвратить попадание таких дополнительных зависимостей в `RUN_DEPENDS`, создайте другую переменную с текущим содержимым `BUILD_DEPENDS` и присвойте её как `BUILD_DEPENDS`, так и `RUN_DEPENDS`:

    MY_DEPENDS=	some:devel/some \
    		other:lang/other
    BUILD_DEPENDS=	${MY_DEPENDS}
    RUN_DEPENDS=	${MY_DEPENDS}

| Не используйте `:=` для присваивания `BUILD_DEPENDS` в `RUN_DEPENDS` или наоборот. Все переменные раскрываются немедленно, что является совершенно неправильным и почти всегда приводит к ошибке.

### 5.10.3. `BUILD_DEPENDS`

Эта переменная указывает исполняемые файлы или файлы, необходимые для сборки данного порта. Как и `RUN_DEPENDS`, это список кортежей `path:dir`[:`target`]. Например,

    BUILD_DEPENDS=	unzip:archivers/unzip

проверит наличие исполняемого файла с именем `unzip` и перейдет в подкаталог archivers/unzip дерева портов, чтобы собрать и установить его, если он не будет найден.

| "build" здесь означает все процессы от извлечения до компиляции. Зависимость проверяется внутри цели `extract`. Часть target может быть опущена, если она совпадает с `DEPENDS_TARGET`

### 5.10.4. `FETCH_DEPENDS`

Эта переменная определяет исполняемые файлы или файлы, необходимые для загрузки этого порта. Как и предыдущие две, это список кортежей `path:dir`[:`target`]. Например,

    FETCH_DEPENDS=	ncftp2:net/ncftp2

проверит наличие исполняемого файла с именем `ncftp2` и перейдет в подкаталог net/ncftp2 дерева портов для сборки и установки, если файл не будет найден.

Зависимость проверяется внутри цели `fetch`. Часть target может быть опущена, если она совпадает с `DEPENDS_TARGET`.

### 5.10.5. `EXTRACT_DEPENDS`

Эта переменная указывает исполняемые файлы или файлы, которые требуются для извлечения данного порта. Как и предыдущая, это список кортежей `path:dir`[:`target`]. Например,

    EXTRACT_DEPENDS=	unzip:archivers/unzip

проверит наличие исполняемого файла с именем `unzip` и перейдет в подкаталог archivers/unzip дерева портов, чтобы собрать и установить его, если он не будет найден.

Зависимость проверяется внутри цели `extract`. Часть target может быть опущена, если она совпадает с `DEPENDS_TARGET`.

| Используйте эту переменную только если извлечение уже не работает (по умолчанию предполагается `tar`) и не может быть исправлено с помощью `USES=tar`, `USES=lha` или `USES=zip`, как описано в Использование макросов `USES`.

### 5.10.6. `PATCH_DEPENDS`

Эта переменная указывает исполняемые файлы или файлы, которые требуются этому порту для применения патчей. Как и предыдущая, это список кортежей `path:dir`[:`target`]. Например,

    PATCH_DEPENDS=	${NONEXISTENT}:java/jfc:extract

будет спускаться в подкаталог java/jfc дерева портов для его извлечения.

Зависимость проверяется в рамках цели `patch`. Часть target может быть опущена, если она совпадает с `DEPENDS_TARGET`.

### 5.10.7. `USES`

Параметры могут быть добавлены для определения различных функций и зависимостей, используемых портом. Они указываются путем добавления этой строки в Makefile:

    USES= feature[:arguments]

Для полного списка значений обратитесь к разделу Использование макросов `USES`.

| `USES` нельзя назначать после включения bsd.port.pre.mk.

### 5.10.8. `USE_*`

Существует несколько переменных для определения общих зависимостей, используемых многими портами. Их использование необязательно, но помогает сократить многословность Makefile портов. Каждая из них оформлена как `USE_*`. Эти переменные могут использоваться только в Makefile портов и ports/Mk/bsd.*.mk. Они не предназначены для настраиваемых пользователем опций — для этой цели используйте `PORT_OPTIONS`.

| Всегда неправильно устанавливать любые `USE_*` в /etc/make.conf. Например, установка
    USE_GCC=X.Y
(где X.Y — номер версии) добавит зависимость от gccXY для каждого порта, включая сам `lang/gccXY`!

Таблица 8. `USE_*`
Переменная | Значение
--- | ---
`USE_GCC` | Порт требует GCC (`gcc` или `g++`) для сборки. Некоторые порты нуждаются в определённой, старой версии GCC, другие требуют современных, актуальных версий. Обычно устанавливается в `yes` (означает всегда использовать стабильную, современную версию GCC из портов, согласно `GCC_DEFAULT` в Mk/bsd.default-versions.mk). Это также значение по умолчанию. Точная версия также может быть указана, например, значением `10`. GCC из базовой системы используется, если он удовлетворяет запрашиваемой версии, в противном случае подходящий компилятор собирается из портов, а `CC` и `CXX` корректируются соответствующим образом. Аргумент `:build`, следующий за указанием версии, добавляет только зависимость во время сборки порта. Например:
    USE_GCC=yes		# порт требует текущей версии GCC
    USE_GCC=11:build	# порт требует GCC 11 только во время сборки
| `USE_GCC=any` устарел и не должен использоваться в новых портах

Переменные, связанные с gmake и configure, описаны в Механизмы сборки, тогда как autoconf, automake и libtool описаны в Использование GNU Autotools. Переменные, связанные с Perl, описаны в Использование Perl. Переменные X11 перечислены в Использование X11. Использование GNOME посвящено GNOME, а Использование KDE — переменным, связанным с KDE. Использование Java документирует переменные Java, тогда как Веб-приложения содержит информацию о модулях Apache, PHP и PEAR. Python обсуждается в Использование Python, а Ruby — в Использование Ruby. Использование SDL предоставляет переменные, используемые для приложений SDL, и, наконец, Использование Xfce содержит информацию о Xfce.

### 5.10.9. Минимальная версия зависимого пакета

Минимальная версия зависимого пакета может быть указана в любом `*_DEPENDS`, кроме `LIB_DEPENDS`, используя следующий синтаксис:

    p5-Spiffy>=0.26:devel/p5-Spiffy

Первое поле содержит имя зависимого пакета, которое должно соответствовать записи в базе данных пакетов, знак сравнения и версию пакета. Зависимость считается удовлетворённой, если на машине установлен p5-Spiffy-0.26 или новее.

### 5.10.10. Заметки о зависимостях

Как упомянуто выше, цель по умолчанию, вызываемая при необходимости зависимости, — это `DEPENDS_TARGET`. По умолчанию она установлена в `install`. Это пользовательская переменная; она никогда не определяется в Makefile порта. Если порту требуется особый способ обработки зависимости, используйте часть `:target` в `*_DEPENDS` вместо переопределения `DEPENDS_TARGET`.

При выполнении `make clean` зависимости портов также автоматически очищаются. Если это нежелательно, определите переменную `NOCLEANDEPENDS` в окружении. Это может быть особенно полезно, если среди зависимостей порта есть что-то, что требует много времени для пересборки, например KDE, GNOME или Mozilla.

Для безусловной зависимости от другого порта используйте переменную `${NONEXISTENT}` в качестве первого поля `BUILD_DEPENDS` или `RUN_DEPENDS`. Используйте это только в случае, когда необходим исходный код другого порта. Время компиляции можно сократить, указав также цель. Например

    BUILD_DEPENDS=	${NONEXISTENT}:graphics/jpeg:extract

всегда будет переходить к порту `jpeg` и извлекать его.

### 5.10.11. Циклические зависимости фатальны

| Не создавайте циклических зависимостей в дереве портов!

Технология сборки портов не допускает циклических зависимостей. Если такая зависимость будет добавлена, у кого-то в мире почти сразу окажется сломанной установка FreeBSD, а за этим последуют многие другие. Подобные проблемы бывает очень сложно обнаружить. Если есть сомнения, перед внесением изменений обязательно выполните: `cd /usr/ports; make index`. Этот процесс может быть довольно медленным на старых машинах, но он способен избавить множество людей, включая вас, от серьёзных проблем.

### 5.10.12. Проблемы, вызванные автоматическими зависимостями

Зависимости должны быть объявлены явно или с использованием OPTIONS framework. Использование других методов, таких как автоматическое обнаружение, усложняет индексацию, что вызывает проблемы для управления портами и пакетами.

Пример 37. Неправильное объявление необязательной зависимости

    .include <bsd.port.pre.mk>

    .if exists(${LOCALBASE}/bin/foo)
    LIB_DEPENDS=	libbar.so:foo/bar
    .endif

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

Пример 38. Правильное объявление необязательной зависимости

    OPTIONS_DEFINE=	BAR
    BAR_DESC=	Calling cellphones via bar

    BAR_LIB_DEPENDS=	libbar.so:foo/bar

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

## 5.11. Подчиненные порты и `MASTERDIR`

Если порту необходимо собирать немного разные версии пакетов, используя переменную (например, разрешение или размер бумаги) с разными значениями, создайте по одному подкаталогу для каждого пакета, чтобы пользователям было проще понять, что делать, но старайтесь максимально использовать общие файлы между портами. Обычно, при грамотном использовании переменных, во всех каталогах, кроме одного, требуется лишь очень короткий Makefile. В единственном Makefile укажите каталог с остальными файлами с помощью `MASTERDIR`. Также используйте переменную как часть `PKGNAMESUFFIX`, чтобы пакеты имели разные имена.

Это лучше всего продемонстрировать на примере. Это часть файла print/pkfonts300/Makefile;

    PORTNAME=	pkfonts${RESOLUTION}
    PORTVERSION=	1.0
    DISTFILES=	pk${RESOLUTION}.tar.gz

    PLIST=		${PKGDIR}/pkg-plist.${RESOLUTION}

    .if !defined(RESOLUTION)
    RESOLUTION=	300
    .else
    .if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \
    	${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, 360, 400 and 600."
    	@${FALSE}
    .endif
    .endif

Пакет `print/pkfonts300` также содержит все обычные исправления, файлы пакетов и т.д. При запуске `make` в этом месте будет взято значение разрешения по умолчанию (300), и порт будет собран в обычном режиме.

Что касается других разрешений, это полный print/pkfonts360/Makefile:

    RESOLUTION=	360
    MASTERDIR=	${.CURDIR}/../pkfonts300

    .include	"${MASTERDIR}/Makefile"

(print/pkfonts118/Makefile, print/pkfonts600/Makefile и все остальные аналогичны). Определение `MASTERDIR` указывает bsd.port.mk, что стандартный набор подкаталогов, таких как `FILESDIR` и `SCRIPTDIR`, следует искать в pkfonts300. Строка `RESOLUTION=360` переопределит строку `RESOLUTION=300` в pkfonts300/Makefile, и порт будет собран с разрешением, установленным на 360.

## 5.12. Страницы Справочника

Если порт размещает дерево man в другом месте, отличном от `PREFIX`, используйте `MANDIRS` для указания этих каталогов. Обратите внимание, что файлы, соответствующие страницам руководства, должны быть добавлены в pkg-plist вместе с остальными файлами. Назначение `MANDIRS` — обеспечить автоматическое сжатие страниц руководства, поэтому имена файлов имеют суффикс .gz.

## 5.13. Файлы информации

Если пакету требуется установить файлы GNU info, перечислите их в `INFO` (без завершающего `.info`), по одному документу на строку. Предполагается, что эти файлы будут установлены в PREFIX/INFO_PATH. Измените `INFO_PATH`, если пакет использует другое расположение. Однако это не рекомендуется. Эти записи содержат только путь относительно PREFIX/INFO_PATH. Например, пакет lang/gcc34 устанавливает файлы info в PREFIX/INFO_PATH/gcc34, и `INFO` будет выглядеть примерно так:

    INFO=	gcc34/cpp gcc34/cppinternals gcc34/g77 ...

Соответствующий код установки/удаления будет автоматически добавлен во временный файл pkg-plist перед регистрацией пакета.

## 5.14. Параметры Makefile

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

### 5.14.1. `OPTIONS`

#### 5.14.1.1. Пояснения

`OPTIONS_*` предоставляют пользователю, устанавливающему порт, диалоговое окно с доступными опциями, после чего сохраняют выбранные опции в ${PORT_DBDIR}/${OPTIONS_NAME}/options. При следующей сборке порта эти опции будут использованы повторно. `PORT_DBDIR` по умолчанию имеет значение /var/db/ports. `OPTIONS_NAME` соответствует имени порта (origin) с заменой разделителя на подчёркивания, например, для dns/bind99 это будет `dns_bind99`.

Когда пользователь запускает `make config` (или впервые запускает `make build`), система проверяет наличие файла ${PORT_DBDIR}/${OPTIONS_NAME}/options. Если этот файл не существует, используются значения `OPTIONS_*`, и отображается диалоговое окно, где можно включить или отключить опции. Затем файл options сохраняется, а настроенные переменные используются при сборке порта.

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

`make showconfig` показывает сохранённую конфигурацию. Используйте `make rmconfig` для удаления сохранённой конфигурации.

#### 5.14.1.2. Синтаксис

`OPTIONS_DEFINE` содержит список `OPTIONS`, которые будут использоваться. Они независимы друг от друга и не сгруппированы:

    OPTIONS_DEFINE=	OPT1 OPT2

После определения `OPTIONS` описываются (необязательно, но настоятельно рекомендуется):

    OPT1_DESC=	Describe OPT1
    OPT2_DESC=	Describe OPT2
    OPT3_DESC=	Describe OPT3
    OPT4_DESC=	Describe OPT4
    OPT5_DESC=	Describe OPT5
    OPT6_DESC=	Describe OPT6

ports/Mk/bsd.options.desc.mk содержит описания для многих распространённых `OPTIONS`. Хотя они часто полезны, переопределите их, если описание недостаточно для порта.

| При описании параметров рассматривайте их с точки зрения пользователя: «Какую функциональность это изменяет?» и «Зачем мне включать этот параметр?» Не просто повторяйте название. Например, описание параметра `NLS` как «включить поддержку NLS» не помогает пользователю, который уже видит название параметра, но может не знать, что оно означает. Описание вроде «Поддержка родного языка с помощью утилиты gettext» гораздо полезнее.

| Названия параметров всегда пишутся в верхнем регистре. Они не могут использовать смешанный регистр или нижний регистр.

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

    OPTIONS_SINGLE=		SG1
    OPTIONS_SINGLE_SG1=	OPT3 OPT4

| В каждый момент времени должна быть выбрана одна опция из каждой группы `OPTIONS_SINGLE`, чтобы параметры были действительными. Один вариант из каждой группы должен быть добавлен в `OPTIONS_DEFAULT`.

`OPTIONS` могут быть сгруппированы как переключаемые варианты, где ни один или только один вариант из каждой группы разрешён:

    OPTIONS_RADIO=		RG1
    OPTIONS_RADIO_RG1=	OPT7 OPT8

`OPTIONS` также могут быть сгруппированы в виде списков "множественного выбора", где хотя бы одна опция должна быть включена:

    OPTIONS_MULTI=		MG1
    OPTIONS_MULTI_MG1=	OPT5 OPT6

`OPTIONS` также могут быть сгруппированы в виде списков "множественного выбора", где ни одна или любые опции могут быть включены:

    OPTIONS_GROUP=		GG1
    OPTIONS_GROUP_GG1=	OPT9 OPT10

`OPTIONS` по умолчанию не установлены, если они не перечислены в `OPTIONS_DEFAULT`:

    OPTIONS_DEFAULT=	OPT1 OPT3 OPT6

Определения `OPTIONS` должны быть указаны до включения файла bsd.port.options.mk. Значения `PORT_OPTIONS` можно проверять только после включения bsd.port.options.mk. Включение bsd.port.pre.mk также может использоваться и до сих пор широко применяется в портах, написанных до введения bsd.port.options.mk. Однако следует учитывать, что некоторые переменные не будут работать как ожидается после включения bsd.port.pre.mk, обычно это некоторые флаги `USE_*`.

Пример 39. Простое использование `OPTIONS`

    OPTIONS_DEFINE=	FOO BAR
    OPTIONS_DEFAULT=FOO

    FOO_DESC=	Option foo support
    BAR_DESC=	Feature bar support

    # Will add --with-foo / --without-foo
    FOO_CONFIGURE_WITH=	foo
    BAR_RUN_DEPENDS=	bar:bar/bar

    .include <bsd.port.mk>

Пример 40. Проверка неустановленных `OPTIONS` порта

    .if ! ${PORT_OPTIONS:MEXAMPLES}
    CONFIGURE_ARGS+=--without-examples
    .endif

Приведённая выше форма не рекомендуется. Предпочтительный метод — использование параметра configure для фактического включения и отключения функции в соответствии с опцией:

    # Will add --with-examples / --without-examples
    EXAMPLES_CONFIGURE_WITH=	examples

Пример 41. Пример реального использования `OPTIONS`

    OPTIONS_DEFINE=		EXAMPLES
    OPTIONS_DEFAULT=	PGSQL LDAP SSL

    OPTIONS_SINGLE=		BACKEND
    OPTIONS_SINGLE_BACKEND=	MYSQL PGSQL BDB

    OPTIONS_MULTI=		AUTH
    OPTIONS_MULTI_AUTH=	LDAP PAM SSL

    EXAMPLES_DESC=		Install extra examples
    MYSQL_DESC=		Use MySQL as backend
    PGSQL_DESC=		Use PostgreSQL as backend
    BDB_DESC=		Use Berkeley DB as backend
    LDAP_DESC=		Build with LDAP authentication support
    PAM_DESC=		Build with PAM support
    SSL_DESC=		Build with OpenSSL support

    # Will add USE_PGSQL=yes
    PGSQL_USE=	pgsql=yes
    # Will add --enable-postgres / --disable-postgres
    PGSQL_CONFIGURE_ENABLE=	postgres

    ICU_LIB_DEPENDS=	libicuuc.so:devel/icu

    # Will add --with-examples / --without-examples
    EXAMPLES_CONFIGURE_WITH=	examples

    # Check other OPTIONS

    .include <bsd.port.mk>

#### 5.14.1.3. Опции по умолчанию

Эти опции всегда включены по умолчанию.

- `DOCS` — сборка и установка документации.

- `NLS` — Поддержка родного языка.

- `EXAMPLES` — сборка и установка примеров.

- `IPV6` — Поддержка протокола IPv6.

| Нет необходимости добавлять их в `OPTIONS_DEFAULT`. Однако, чтобы они были активны и отображались в диалоге выбора опций, их необходимо добавить в `OPTIONS_DEFINE`.

### 5.14.2. Автоматическая активация функций

При использовании скрипта GNU configure следите за тем, какие дополнительные функции активируются автоматическим определением. Явно отключите ненужные дополнительные функции, добавив `--without-xxx` или `--disable-xxx` в `CONFIGURE_ARGS`.

Пример 42. Неправильная обработка опции

    .if ${PORT_OPTIONS:MFOO}
    LIB_DEPENDS+=		libfoo.so:devel/foo
    CONFIGURE_ARGS+=	--enable-foo
    .endif

В приведённом выше примере представьте, что библиотека libfoo установлена в системе. Пользователь не хочет, чтобы это приложение использовало libfoo, поэтому он отключил соответствующую опцию в диалоге `make config`. Однако скрипт configure приложения обнаруживает библиотеку в системе и включает её поддержку в итоговом исполняемом файле. Теперь, когда пользователь решает удалить libfoo из системы, система портов не протестует (зависимость от libfoo не была записана), но приложение перестаёт работать.

Пример 43. Правильная обработка опции

    FOO_LIB_DEPENDS=		libfoo.so:devel/foo
    # Will add --enable-foo / --disable-foo
    FOO_CONFIGURE_ENABLE=	foo

| В некоторых случаях сокращенный синтаксис условных выражений может вызывать проблемы со сложными конструкциями. Ошибки обычно имеют вид `Malformed conditional`, тогда можно использовать альтернативный синтаксис.
    .if !empty(VARIABLE:MVALUE)
в качестве альтернативы
    .if ${VARIABLE:MVALUE}

### 5.14.3. Помощники параметров

Существуют макросы, которые помогают упростить условные значения, различающиеся в зависимости от установленных опций. Для удобства приведён полный список:

`PLIST_SUB`, `SUB_LIST`

  Для автоматической генерации `%%OPT%%` и `%%NOOPT%%` см. `OPTIONS_SUB`.

  Для более сложных случаев использования см. Замена общих переменных.

`CONFIGURE_ARGS`

  Для информации о `--enable-x` и `--disable-x` см. `OPT_CONFIGURE_ENABLE`.

  О `--with-x` и `--without-x` см. `OPT_CONFIGURE_WITH`.

  Во всех остальных случаях см. `OPT_CONFIGURE_ON` и `OPT_CONFIGURE_OFF`.

`CMAKE_ARGS`

  Для аргументов, которые являются булевыми значениями (`on`, `off`, `true`, `false`, `0`, `1`), см. `OPT_CMAKE_BOOL` и `OPT_CMAKE_BOOL_OFF`.

  Для всех остальных случаев см. `OPT_CMAKE_ON` и `OPT_CMAKE_OFF`.

`MESON_ARGS`

  Для аргументов, принимающих `true` или `false`, см. `OPT_MESON_TRUE` и `OPT_MESON_FALSE`.

  Для аргументов, принимающих `yes` или `no`, используйте `OPT_MESON_YES` и `OPT_MESON_NO`.

  Для аргументов, принимающих `enabled` или `disabled`, см. `OPT_MESON_ENABLED` и `OPT_MESON_DISABLED`.

  Во всех остальных случаях используйте `OPT_MESON_ON` и `OPT_MESON_OFF`.

`QMAKE_ARGS`

  См. `OPT_QMAKE_ON` и `OPT_QMAKE_OFF`.

`USE_*`

  См. `OPT_USE` и `OPT_USE_OFF`.

`*_DEPENDS`

  См. Зависимости.

`*` (Любая переменная)

  Наиболее используемые переменные имеют своих помощников, см. Замена Общих Переменных.

  Для любой переменной без специального помощника см. `OPT_VARS` и `OPT_VARS_OFF`.

Зависимости параметров

  Когда для работы опции требуется другая опция, см. `OPT_IMPLIES`.

Конфликты опций

  Когда опция не может работать, если включена другая, см. `OPT_PREVENTS` и `OPT_PREVENTS_MSG`.

Цели сборки

  Когда для опции требуется дополнительная обработка, см. Дополнительные цели сборки.

#### 5.14.3.1. `OPTIONS_SUB`

Если `OPTIONS_SUB` установлен в `yes`, то каждая из опций, добавленных в `OPTIONS_DEFINE`, будет добавлена в `PLIST_SUB` и `SUB_LIST`, например:

    OPTIONS_DEFINE=	OPT1
    OPTIONS_SUB=	yes

эквивалентно:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    .if ${PORT_OPTIONS:MOPT1}
    PLIST_SUB+=	OPT1="" NO_OPT1="@comment "
    SUB_LIST+=	OPT1="" NO_OPT1="@comment "
    .else
    PLIST_SUB+=	OPT1="@comment " NO_OPT1=""
    SUB_LIST+=	OPT1="@comment " NO_OPT1=""
    .endif

| Значение `OPTIONS_SUB` игнорируется. Установка любого значения добавит записи `PLIST_SUB` и `SUB_LIST` для всех опций.

#### 5.14.3.2. `OPT_USE` и `OPT_USE_OFF`

Когда выбрана опция OPT, для каждой пары `ключ=значение` в `OPT_USE`, значение добавляется к соответствующему `USE_KEY`. Если значение содержит пробелы, замените их запятыми, и они будут преобразованы обратно в пробелы во время обработки. `OPT_USE_OFF` работает аналогично, но когда `OPT` не выбрана. Например:

    OPTIONS_DEFINE=	OPT1
    OPT1_USES=	xorg
    OPT1_USE=	mysql=yes xorg=x11,xextproto,xext,xrandr
    OPT1_USE_OFF=	openssl=yes

эквивалентно:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    .if ${PORT_OPTIONS:MOPT1}
    USE_MYSQL=	yes
    USES+=		xorg
    USE_XORG=	x11 xextproto xext xrandr
    .else
    USE_OPENSSL=	yes
    .endif

#### 5.14.3.3. Помощники `CONFIGURE_ARGS`

##### 5.14.3.3.1. `OPT_CONFIGURE_ENABLE`

Когда выбрана опция OPT, для каждого элемента в `OPT_CONFIGURE_ENABLE` к `CONFIGURE_ARGS` добавляется `--enable-элемент`. Если опция OPT не выбрана, к `CONFIGURE_ARGS` добавляется `--disable-элемент`. Необязательный аргумент может быть указан с помощью символа `=`. Этот аргумент добавляется только к опции конфигурации `--enable-элемент`. Например:

    OPTIONS_DEFINE=	OPT1 OPT2
    OPT1_CONFIGURE_ENABLE=	test1 test2
    OPT2_CONFIGURE_ENABLE=	test2=exhaustive

эквивалентно:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    .if ${PORT_OPTIONS:MOPT1}
    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

##### 5.14.3.3.2. `OPT_CONFIGURE_WITH`

Когда выбрана опция OPT, для каждого элемента в `OPT_CONFIGURE_WITH` к `CONFIGURE_ARGS` добавляется `--with-_элемент`. Если опция OPT не выбрана, к `CONFIGURE_ARGS` добавляется `--without-элемент`. Необязательный аргумент можно указать с помощью символа `=`. Этот аргумент добавляется только к опции конфигурации `--with-элемент`. Например:

    OPTIONS_DEFINE=	OPT1 OPT2
    OPT1_CONFIGURE_WITH=	test1
    OPT2_CONFIGURE_WITH=	test2=exhaustive

эквивалентно:

    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-test2
    .endif

##### 5.14.3.3.3. `OPT_CONFIGURE_ON` и `OPT_CONFIGURE_OFF`

Когда выбрана опция OPT, значение `OPT_CONFIGURE_ON`, если оно определено, добавляется к `CONFIGURE_ARGS`. `OPT_CONFIGURE_OFF` работает аналогично, но когда `OPT` не выбрана. Например:

    OPTIONS_DEFINE=	OPT1
    OPT1_CONFIGURE_ON=	--add-test
    OPT1_CONFIGURE_OFF=	--no-test

эквивалентно:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    .if ${PORT_OPTIONS:MOPT1}
    CONFIGURE_ARGS+=	--add-test
    .else
    CONFIGURE_ARGS+=	--no-test
    .endif

| В большинстве случаев помощники `OPT_CONFIGURE_ENABLE` и `OPT_CONFIGURE_WITH` предоставляют более короткий и понятный функционал.

#### 5.14.3.4. Помощники `CMAKE_ARGS`

##### 5.14.3.4.1. `OPT_CMAKE_ON` и `OPT_CMAKE_OFF`

Когда выбрана опция OPT, значение `OPT_CMAKE_ON`, если оно определено, добавляется к `CMAKE_ARGS`. `OPT_CMAKE_OFF` работает аналогично, но когда `OPT` не выбрана. Например:

    OPTIONS_DEFINE=	OPT1
    OPT1_CMAKE_ON=	-DTEST:BOOL=true -DDEBUG:BOOL=true
    OPT1_CMAKE_OFF=	-DOPTIMIZE:BOOL=true

эквивалентно:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    .if ${PORT_OPTIONS:MOPT1}
    CMAKE_ARGS+=	-DTEST:BOOL=true -DDEBUG:BOOL=true
    .else
    CMAKE_ARGS+=	-DOPTIMIZE:BOOL=true
    .endif

| См. `OPT_CMAKE_BOOL` и `OPT_CMAKE_BOOL_OFF` для более краткой записи, когда значение является булевым.

##### 5.14.3.4.2. `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`, когда опция не выбрана. Например:

    OPTIONS_DEFINE=	OPT1
    OPT1_CMAKE_BOOL=	TEST DEBUG
    OPT1_CMAKE_BOOL_OFF=	OPTIMIZE

эквивалентно:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    .if ${PORT_OPTIONS:MOPT1}
    CMAKE_ARGS+=	-DTEST:BOOL=true -DDEBUG:BOOL=true \
    		-DOPTIMIZE:BOOL=false
    .else
    CMAKE_ARGS+=	-DTEST:BOOL=false -DDEBUG:BOOL=false \
    		-DOPTIMIZE:BOOL=true
    .endif

#### 5.14.3.5. Помощники `MESON_ARGS`

##### 5.14.3.5.1. `OPT_MESON_ON` и `OPT_MESON_OFF`

Когда выбрана опция OPT, значение `OPT_MESON_ON`, если оно определено, добавляется к `MESON_ARGS`. `OPT_MESON_OFF` работает аналогичным образом, но когда `OPT` не выбрана. Например:

    OPTIONS_DEFINE=	OPT1
    OPT1_MESON_ON=	-Dopt=1
    OPT1_MESON_OFF=	-Dopt=2

эквивалентно:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    .if ${PORT_OPTIONS:MOPT1}
    MESON_ARGS+=	-Dopt=1
    .else
    MESON_ARGS+=	-Dopt=2
    .endif

##### 5.14.3.5.2. `OPT_MESON_TRUE` и `OPT_MESON_FALSE`

Когда выбрана опция OPT, для каждого элемента в `OPT_MESON_TRUE` добавляется `-D_элемент_=true` в `MESON_ARGS`. Если опция OPT не выбрана, добавляется `-D_элемент_=false` в `MESON_ARGS`. `OPT_MESON_FALSE` работает противоположным образом: `-D_элемент_=false` добавляется в `MESON_ARGS`, когда опция выбрана, и `-D_элемент_=true`, когда опция не выбрана. Например:

    OPTIONS_DEFINE=	OPT1
    OPT1_MESON_TRUE=	test debug
    OPT1_MESON_FALSE=	optimize

эквивалентно:

    OPTIONS_DEFINE=	OPT1

    .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

##### 5.14.3.5.3. `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`, когда опция не выбрана. Например:

    OPTIONS_DEFINE=	OPT1
    OPT1_MESON_YES=	test debug
    OPT1_MESON_NO=	optimize

эквивалентно:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    .if ${PORT_OPTIONS:MOPT1}
    MESON_ARGS+=	-Dtest=yes -Ddebug=yes \
    		-Doptimize=no
    .else
    MESON_ARGS+=	-Dtest=no -Ddebug=no \
    		-Doptimize=yes
    .endif

##### 5.14.3.5.4. `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`, когда опция не выбрана. Например:

    OPTIONS_DEFINE=	OPT1
    OPT1_MESON_ENABLED=	test
    OPT1_MESON_DISABLED=	debug

эквивалентно:

    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

#### 5.14.3.6. `OPT_QMAKE_ON` и `OPT_QMAKE_OFF`

Когда выбрана опция OPT, значение `OPT_QMAKE_ON`, если оно определено, добавляется к `QMAKE_ARGS`. `OPT_QMAKE_OFF` работает аналогичным образом, но когда `OPT` не выбрана. Например:

    OPTIONS_DEFINE=	OPT1
    OPT1_QMAKE_ON=	-DTEST:BOOL=true
    OPT1_QMAKE_OFF=	-DPRODUCTION:BOOL=true

эквивалентно:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    .if ${PORT_OPTIONS:MOPT1}
    QMAKE_ARGS+=	-DTEST:BOOL=true
    .else
    QMAKE_ARGS+=	-DPRODUCTION:BOOL=true
    .endif

#### 5.14.3.7. `OPT_IMPLIES`

Предоставляет способ добавления зависимостей между опциями.

При выборе OPT все перечисленные в этой переменной опции также будут выбраны. В качестве примера можно использовать описанный ранее `OPT_CONFIGURE_ENABLE`:

    OPTIONS_DEFINE=	OPT1 OPT2
    OPT1_IMPLIES=	OPT2

    OPT1_CONFIGURE_ENABLE=	opt1
    OPT2_CONFIGURE_ENABLE=	opt2

Эквивалентно:

    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

Пример 44. Простое использование `OPT_IMPLIES`

Этот порт имеет опцию `X11` и опцию `GNOME`, для сборки которой необходимо выбрать опцию `X11`.

    OPTIONS_DEFINE=	X11 GNOME
    OPTIONS_DEFAULT=	X11

    X11_USES=	xorg
    X11_USE=	xorg=xi,xextproto
    GNOME_USE=	gnome=gtk30
    GNOME_IMPLIES=	X11

#### 5.14.3.8. `OPT_PREVENTS` и `OPT_PREVENTS_MSG`

Предоставляет способ добавления конфликтов между опциями.

Когда выбрана OPT, все опции, перечисленные в `OPT_PREVENTS`, должны быть сняты. Если задано `OPT_PREVENTS_MSG` и возникает конфликт, его содержимое будет показано с объяснением причины конфликта. Например:

    OPTIONS_DEFINE=	OPT1 OPT2
    OPT1_PREVENTS=	OPT2
    OPT1_PREVENTS_MSG=	OPT1 and OPT2 enable conflicting options

Примерно эквивалентно:

    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`, предлагая изменить выбранные настройки.

Пример 45. Простое использование `OPT_PREVENTS`

Этот порт имеет опции `X509` и `SCTP`. Обе опции добавляют патчи, но патчи конфликтуют друг с другом, поэтому их нельзя выбрать одновременно.

    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

#### 5.14.3.9. `OPT_VARS` и `OPT_VARS_OFF`

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

| Перед использованием `OPT_VARS` и `OPT_VARS_OFF` проверьте, доступен ли более специфичный вспомогательный инструмент в Универсальная замена переменных.

Когда выбрана опция OPT и определены `OPT_VARS`, пары `key=value` и `key+=value` обрабатываются из `OPT_VARS`. Оператор `=` приводит к перезаписи существующего значения `KEY`, а `+=` добавляет к значению. `OPT_VARS_OFF` работает аналогично, но когда `OPT` не выбрана.

    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}"

эквивалентно:

    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

| Значения, содержащие пробелы, должны быть заключены в кавычки:
    OPT_VARS=	foo="bar baz"
Это связано с тем, как make(1) обрабатывает пробелы при раскрытии переменных. Когда `OPT_VARS= foo=bar baz` раскрывается, переменная в итоге содержит две строки: `foo=bar` и `baz`. Однако отправитель, вероятно, предполагал, что должна быть только одна строка — `foo=bar baz`. Заключение значения в кавычки предотвращает использование пробела в качестве разделителя. Также не добавляйте лишние пробелы после знака `var=` и перед значением, это также разобьёт строку на две части. Это не сработает:
    OPT_VARS=	foo=	bar

#### 5.14.3.10. Зависимости, `OPT_DEPTYPE` и `OPT_DEPTYPE_OFF`

Для любого из этих типов зависимостей:

- `PKG_DEPENDS`

- `EXTRACT_DEPENDS`

- `PATCH_DEPENDS`

- `FETCH_DEPENDS`

- `BUILD_DEPENDS`

- `LIB_DEPENDS`

- `RUN_DEPENDS`

Когда выбрана опция OPT, значение `OPT_DEPTYPE`, если оно определено, добавляется к `DEPTYPE`. `OPT_DEPTYPE_OFF` работает аналогично, но когда не выбрана `OPT`. Например:

    OPTIONS_DEFINE=	OPT1
    OPT1_LIB_DEPENDS=	liba.so:devel/a
    OPT1_LIB_DEPENDS_OFF=	libb.so:devel/b

эквивалентно:

    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

#### 5.14.3.11. Универсальная замена переменных, `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` не выбрана. Например:

    OPTIONS_DEFINE=	OPT1
    OPT1_USES=	gmake
    OPT1_CFLAGS_OFF=	-DTEST

эквивалентно:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    .if ${PORT_OPTIONS:MOPT1}
    USES+=		gmake
    .else
    CFLAGS+=	-DTEST
    .endif

| Некоторые переменные отсутствуют в этом списке, в частности `PKGNAMEPREFIX` и `PKGNAMESUFFIX`. Это сделано намеренно. Порт не должен изменять своё имя при изменении набора опций.

| Некоторые из этих переменных, по крайней мере `ALL_TARGET`, `DISTFILES` и `INSTALL_TARGET`, получают свои значения по умолчанию после обработки опций. С такими строками в Makefile:
    ALL_TARGET=	all

    DOCS_ALL_TARGET=	doc
Если опция `DOCS` включена, `ALL_TARGET` будет иметь конечное значение `all doc`; если опция отключена, значение будет `all`. Только со строкой помощника опций в Makefile:
    DOCS_ALL_TARGET=	doc
Если опция `DOCS` включена, `ALL_TARGET` будет иметь окончательное значение `doc`; если опция отключена, значение будет `all`.

#### 5.14.3.12. Дополнительные цели сборки, `target-OPT-on` и `target-OPT-off`

Эти цели в 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` не выбрана. Например:

    OPTIONS_DEFINE=	OPT1

    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

эквивалентно:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    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

## 5.15. Указание рабочего каталога

Каждый порт извлекается в рабочий каталог, который должен быть доступен для записи. Система портов по умолчанию распаковывает `DISTFILES` в каталог с именем `${DISTNAME}`. Другими словами, если в Makefile указано:

    PORTNAME=	foo
    DISTVERSION=	1.0

то файлы дистрибутива порта содержат каталог верхнего уровня foo-1.0, и остальные файлы находятся в этом каталоге.

Если нужно расположение файлов в других каталогах, можно переопределить ряд переменных.

### 5.15.1. `WRKSRC`

Переменная указывает имя каталога, который создается при распаковке distfiles приложения. Чтобы в нашем предыдущем примере распаковка происходила в каталог с именем foo (а не foo-1.0), напишите:

    WRKSRC=	${WRKDIR}/foo

или можно

    WRKSRC=	${WRKDIR}/${PORTNAME}

### 5.15.2. `WRKSRC_SUBDIR`

Если исходные файлы, необходимые для порта, находятся в подкаталоге распакованного дистрибутива, присвойте `WRKSRC_SUBDIR` имя этого каталога.

    WRKSRC_SUBDIR=	src

### 5.15.3. `NO_WRKSUBDIR`

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

    NO_WRKSUBDIR=	yes

| Поскольку `WRKDIR` является единственным каталогом, который должен быть доступен для записи во время сборки, и используется для хранения многих файлов, фиксирующих состояние сборки, извлечение порта будет принудительно выполнено в подкаталог.

## 5.16. Обработка конфликтов

Существует три различные переменные для регистрации конфликтов между пакетами и портами: `CONFLICTS`, `CONFLICTS_INSTALL` и `CONFLICTS_BUILD`.

| Эти переменные автоматически устанавливают переменную `IGNORE`, более подробно описанную в Пометка порта как неустанавливаемого с помощью `BROKEN`.

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

`CONFLICTS_INSTALL`

  Если пакет не может сосуществовать с другими пакетами (из-за конфликтов файлов, несовместимости во время выполнения и т.д.). Проверка `CONFLICTS_INSTALL` выполняется после этапа сборки и перед этапом установки.

`CONFLICTS_BUILD`

  Если порт не может быть собран, когда уже установлены другие определённые порты. Конфликты сборки не фиксируются в результирующем пакете.

`CONFLICTS`

  Если порт не может быть собран, когда определённый порт уже установлен и итоговый пакет не может сосуществовать с другим пакетом. Проверка `CONFLICTS` выполняется до этапа сборки и до этапа установки.

Каждый элемент, разделённый пробелами, в значениях переменных `CONFLICTS*` сопоставляется с пакетами(кроме того, который собирается) с использованием правил раскрытия шаблонов имён файлов в оболочке shell. Это позволяет перечислить все варианты порта в списке конфликтов вместо необходимости исключать собираемый вариант из этого списка. Например, если установлен git-lite, `CONFLICTS_INSTALL=git git-lite` позволит выполнить:

    % make -C devel/git FLAVOR=lite all deinstall install

Но следующая команда сообщит о конфликте, так как установленное имя базового пакета — `git-lite`, а `git` будет собран, но не может быть установлен вместе с `git-lite`:

    % make -C devel/git FLAVOR=default all deinstall install

Без этой функции Makefile потребовал бы по одному `_flavor__CONFLICTS_INSTALL` для каждого варианта, перечисляя все остальные варианты.

Наиболее распространённым содержимым одной из этих переменных является база пакета другого порта. База пакета — это имя пакета без указания версии, её можно получить, выполнив команду `make -V PKGBASE`.

Пример 46. Простой пример использования `CONFLICTS*`

Пакет dns/bind99 не может быть установлен, если присутствует пакет dns/bind910, так как они устанавливают одинаковые файлы. Сначала соберите базовый пакет для использования:

    % make -C dns/bind99 -V PKGBASE
    bind99
    % make -C dns/bind910 -V PKGBASE
    bind910

Затем добавьте в Makefile пакета dns/bind99:

    CONFLICTS_INSTALL=	bind910

И добавьте в Makefile пакета dns/bind910:

    CONFLICTS_INSTALL=	bind99

Иногда только определённые версии другого порта несовместимы. В этом случае используйте полное имя пакета, включая версию. При необходимости используйте подстановочные символы шаблонов имён файлов оболочки, такие как `*` и `?`, чтобы охватить все необходимые версии.

Пример 47. Использование `CONFLICTS*` с шаблонами имён файлов.

В версиях с 2.0 по 2.4.1_2 пакет deskutils/gnotime устанавливал встроенную версию пакета databases/qof.

Чтобы отразить это прошлое, Makefile пакета databases/qof содержит:

    CONFLICTS_INSTALL=	gnotime-2.[0-3]* \
    			gnotime-2.4.0* gnotime-2.4.1 \
    			gnotime-2.4.1_[12]

Первый элемент соответствует версиям `2.0`–`2.3`, второй — всем редакциям `2.4.0`, третий — точно версии `2.4.1`, а последний — первой и второй редакциям версии `2.4.1`.

deskutils/gnotime не имеет строки конфликтов, потому что его текущая версия не конфликтует ни с чем другим.

Переменная `DISABLE_CONFLICTS` может быть временно установлена при выполнении целей, на которые не влияют конфликты. Эту переменную не следует устанавливать в Makefiles портов.

    % make -DDISABLE_CONFLICTS patch

## 5.17. Установка файлов

| Фаза `install` очень важна для конечного пользователя, так как она добавляет файлы в его систему. Все дополнительные команды, выполняемые в целях `*-install` Makefile порта, должны выводиться на экран. Не заглушайте эти команды с помощью `@` или `.SILENT`.

### 5.17.1. Макросы `INSTALL_*`

Используйте макросы, предоставленные в bsd.port.mk, чтобы обеспечить корректные режимы файлов в целях `*-install` порта. Устанавливайте владельца напрямую в pkg-plist в соответствующих записях, таких как `@(владелец,группа,)`, `@owner владелец` и `@group группа`. Эти операторы действуют до переопределения или до конца pkg-plist, поэтому не забудьте сбросить их, когда они больше не нужны. Владелец по умолчанию — `root:wheel`. Дополнительную информацию см. в Базовые Ключевые Слова.

- `INSTALL_PROGRAM` — команда для установки бинарных исполняемых файлов.

- `INSTALL_SCRIPT` — команда для установки исполняемых скриптов.

- `INSTALL_LIB` — это команда для установки общих библиотек (но не статических библиотек).

- `INSTALL_KLD` — это команда для установки загружаемых модулей ядра. Некоторые архитектуры не поддерживают удаление символов из модулей, поэтому используйте эту команду вместо `INSTALL_PROGRAM`.

- `INSTALL_DATA` — это команда для установки общих данных, включая статические библиотеки.

- `INSTALL_MAN` — это команда для установки man-страниц и другой документации (она ничего не сжимает).

Эти переменные передаются команде install(1) с соответствующими флагами для каждой ситуации.

| Не используйте `INSTALL_LIB` для установки статических библиотек, так как их удаление делает их бесполезными. Вместо этого используйте `INSTALL_DATA`.

### 5.17.2. Удаление символов из бинарных файлов и разделяемых библиотек

Установленные бинарные файлы должны быть очищены от отладочной информации. Не очищайте бинарные файлы вручную, если это не является абсолютно необходимым. Макрос `INSTALL_PROGRAM` устанавливает и очищает бинарный файл одновременно. Макрос `INSTALL_LIB` делает то же самое с разделяемыми библиотеками.

Когда файл необходимо очистить, но ни макросы `INSTALL_PROGRAM`, ни `INSTALL_LIB` не подходят, `${STRIP_CMD}` очищает программу или разделяемую библиотеку. Обычно это делается в цели `post-install`. Например:

    post-install:
    	${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/xdl

Когда необходимо удалить отладочную информацию из нескольких файлов:

    post-install:
    .for l in geometry media body track world
    	${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/lib${PORTNAME}-${l}.so.0
    .endfor

Используйте file(1) для файла, чтобы определить, был ли он подвергнут удалению символов. file(1) сообщает, что бинарные файлы либо `stripped` (удалены символы), либо `not stripped` (символы не удалены). Кроме того, strip(1) обнаружит программы, которые уже были подвергнуты удалению символов, и завершит работу без ошибок.

| Когда определён `WITH_DEBUG`, elf-файлы не должны быть очищены. Переменные (`STRIP_CMD`, `INSTALL_PROGRAM`, `INSTALL_LIB`, …​) и `USES`, предоставляемые фреймворком, обрабатывают это автоматически. Некоторое программное обеспечение добавляет `-s` к своим `LDFLAGS`. В этом случае либо удалите `-s`, если установлен `WITH_DEBUG`, либо удалите его безусловно и используйте `STRIP_CMD` в `post-install`.

### 5.17.3. Установка целого дерева файлов

Иногда необходимо установить большое количество файлов с сохранением их иерархической структуры. Например, копирование всего дерева каталогов из `WRKSRC` в целевой каталог под `PREFIX`. Обратите внимание, что `PREFIX`, `EXAMPLESDIR`, `DATADIR` и другие переменные путей всегда должны предваряться `STAGEDIR` для соблюдения процедуры промежуточной установки (см. Промежуточная установка).

Для этой ситуации существуют два макроса. Преимущество использования этих макросов вместо `cp` заключается в том, что они гарантируют целевым файлам правильные значения владельца и разрешений. Первый макрос, `COPYTREE_BIN`, устанавливает все установленные файлы как исполняемые, что делает его подходящим для установки в PREFIX/bin. Второй макрос, `COPYTREE_SHARE#, не устанавливает исполняемые разрешения для файлов и, следовательно, подходит для установки файлов в PREFIX/share.

    post-install:
    	${MKDIR} ${STAGEDIR}${EXAMPLESDIR}
    	(cd ${WRKSRC}/examples && ${COPYTREE_SHARE} . ${STAGEDIR}${EXAMPLESDIR})

Этот пример установит содержимое каталога examples из дистрибутива вендора в соответствующее расположение примеров порта.

    post-install:
    	${MKDIR} ${STAGEDIR}${DATADIR}/summer
    	(cd ${WRKSRC}/temperatures && ${COPYTREE_SHARE} "June July August" ${STAGEDIR}${DATADIR}/summer)

И этот пример установит данные летних месяцев в подкаталог summer каталога DATADIR.

Дополнительные аргументы `find` могут быть переданы через третий аргумент макросов `COPYTREE_*`. Например, чтобы установить все файлы из первого примера, кроме Makefiles, можно использовать следующие команды.

    post-install:
    	${MKDIR} ${STAGEDIR}${EXAMPLESDIR}
    	(cd ${WRKSRC}/examples && \
    	${COPYTREE_SHARE} . ${STAGEDIR}${EXAMPLESDIR} "! -name Makefile")

Эти макросы не добавляют установленные файлы в pkg-plist. Их необходимо добавлять вручную. Для дополнительной документации (`PORTDOCS`, см. Установка дополнительной документации) и примеров (`PORTEXAMPLES`), префиксы `%%PORTDOCS%%` или `%%PORTEXAMPLES%%` должны быть добавлены в pkg-plist.

### 5.17.4. Установка дополнительной документации

Если у программного обеспечения есть документация, помимо стандартных страниц man и info, которая может быть полезна пользователю, установите её в `DOCSDIR`. Это можно сделать, как и в предыдущем пункте, в цели `post-install`.

Создайте новый каталог для порта. Имя каталога — `DOCSDIR`. Обычно оно равно `PORTNAME`. Однако, если пользователю может потребоваться установка разных версий порта одновременно, можно использовать полное имя `PKGNAME`.

Поскольку устанавливаются только файлы, перечисленные в pkg-plist, можно безопасно всегда устанавливать документацию в `STAGEDIR` (см. Staging). Поэтому блоки `.if` требуются только в тех случаях, когда устанавливаемые файлы достаточно велики, чтобы вызвать значительные накладные расходы на ввод-вывод.

    post-install:
    	${MKDIR} ${STAGEDIR}${DOCSDIR}
    	${INSTALL_DATA} ${WRKSRC}/docs/xvdocs.ps ${STAGEDIR}${DOCSDIR}

С другой стороны, если в порте есть опция DOCS, установите документацию в цели `post-install-DOCS-on`. Эти цели описаны в Дополнительные цели сборки.

Вот несколько полезных переменных и их стандартное раскрытие при использовании в Makefile:

- `DATADIR` раскрывается в PREFIX/share/PORTNAME.

- `DATADIR_REL` раскрывается в share/PORTNAME.

- `DOCSDIR` раскрывается в PREFIX/share/doc/PORTNAME.

- `DOCSDIR_REL` раскрывается в share/doc/PORTNAME.

- `EXAMPLESDIR` раскрывается в PREFIX/share/examples/PORTNAME.

- `EXAMPLESDIR_REL` раскрывается в share/examples/PORTNAME.

| Опция `DOCS` управляет только дополнительной документацией, устанавливаемой в `DOCSDIR`. Она не применяется к стандартным man-страницам и info-страницам. Содержимое, устанавливаемое в `EXAMPLESDIR`, контролируется опцией `EXAMPLES`.

Эти переменные экспортируются в `PLIST_SUB`. Их значения будут представлены там в виде путей относительно PREFIX, если это возможно. То есть, share/doc/PORTNAME будет заменено на `%%DOCSDIR%%` в списке упаковки по умолчанию и так далее. (Подробнее о подстановках в pkg-plist см. здесь.)

Все условно устанавливаемые файлы и каталоги документации включаются в pkg-plist с префиксом `%%PORTDOCS%%`, например:

    %%PORTDOCS%%%%DOCSDIR%%/AUTHORS
    %%PORTDOCS%%%%DOCSDIR%%/CONTACT

В качестве альтернативы перечислению файлов документации в pkg-plist, порт может установить переменную `PORTDOCS` в список имён файлов и шаблонов имён файлов shell для добавления в итоговый список упаковки. Имена будут относительны к `DOCSDIR`. Поэтому порт, использующий `PORTDOCS` и нестандартное расположение документации, должен соответствующим образом установить `DOCSDIR`. Если в `PORTDOCS` указан каталог или он соответствует шаблону из этой переменной, всё поддерево содержащихся файлов и каталогов будет зарегистрировано в итоговом списке упаковки. Если опция `DOCS` отключена, файлы и каталоги, перечисленные в `PORTDOCS`, не будут установлены или добавлены в список упаковки порта. Установка документации в `PORTDOCS`, как показано выше, остаётся на усмотрение самого порта. Типичный пример использования `PORTDOCS`:

    PORTDOCS=	README.* ChangeLog docs/*

| Эквивалентами `PORTDOCS` для файлов, установленных в `DATADIR` и `EXAMPLESDIR`, являются `PORTDATA` и `PORTEXAMPLES` соответственно. Содержимое файла pkg-message отображается при установке. Подробности см. в разделе использование файла pkg-message. Файл pkg-message не нужно добавлять в pkg-plist.

### 5.17.5. Подкаталоги в `PREFIX`

Попробуйте сделать так, чтобы порт размещал файлы в правильных подкаталогах `PREFIX`. Некоторые порты собирают всё в кучу и помещают в подкаталог с именем порта, что неверно. Также многие порты размещают все файлы, кроме бинарников, заголовочных файлов и страниц руководства, в подкаталоге lib, что плохо согласуется с парадигмой BSD. Многие из этих файлов должны быть перемещены в один из следующих каталогов: etc (файлы настройки/конфигурации), libexec (исполняемые файлы для внутреннего использования), sbin (исполняемые файлы для суперпользователей/администраторов), info (документация для браузера info) или share (архитектурно-независимые файлы). Подробности см. в hier(7); правила, действующие для /usr, в основном применимы и к /usr/local. Исключение составляют порты, связанные с USENET "news". Они могут использовать PREFIX/news в качестве места назначения для своих файлов.

## 5.18. Использование `BINARY_ALIAS` для переименования команд вместо исправления сборки

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

Используйте это для замены жёстко заданных команд, от которых зависит этап сборки, без необходимости исправлять какие-либо файлы сборки.

Пример 48. Использование `BINARY_ALIAS` для предоставления `gsed` в качестве `sed`

Некоторые порты ожидают, что `sed` будет вести себя как GNU sed и используют возможности, которые sed(1) не предоставляет. GNU sed доступен в пакете textproc/gsed на FreeBSD.

Используйте `BINARY_ALIAS` для замены `sed` на `gsed` на время сборки:

    BUILD_DEPENDS=	gsed:textproc/gsed
    ...
    BINARY_ALIAS=	sed=gsed

Пример 49. Использование `BINARY_ALIAS` для создания псевдонимов жёстко заданных команд `python3`

Порт, в котором есть жёсткая ссылка на `python3` в скриптах сборки, требует его наличия в `PATH` во время сборки. Используйте `BINARY_ALIAS` для создания псевдонима, указывающего на нужный бинарный файл Python 3:

    USES=	python:3.4+,build
    ...
    BINARY_ALIAS=	python3=${PYTHON_CMD}

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

| Бинарные псевдонимы создаются после обработки зависимостей, указанных через `BUILD_DEPENDS` и `LIB_DEPENDS`, но до цели `configure`. Это приводит к различным ограничениям. Например, программы, установленные через `TEST_DEPENDS`, нельзя использовать для создания бинарного псевдонима, так как тестовые зависимости, указанные таким образом, обрабатываются после создания бинарных псевдонимов.

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

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