Глава 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)
11.2 идёт перед 1.3.
21.2 и 1.2 равны, так как имеют одинаковую версию.
31.2 и 1.2.0 равны, так как ноль ничего не значит.
41.2 идёт после 1.2.p1, так как .p1 означает «pre-release 1» (предрелизная версия 1).
51.2.a1 предшествует 1.2.b1, представьте "alpha" и "beta", где a идёт перед b.
61.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)
11.2 идёт после 1.2.p4, что в данном случае неверно.
21.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. Примеры наименования пакетов
Имя дистрибутиваPKGNAMEPREFIXPORTNAMEPKGNAMESUFFIXDISTVERSION.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

Программное обеспечение, связанное с биологией.

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}

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

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

  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-mirrorpkg-mirrorauto-accept

CC-BY-NC-2.0

Creative Commons с указанием авторства – некоммерческая 2.0

dist-mirrorpkg-mirrorauto-accept

CC-BY-NC-2.5

Creative Commons с указанием авторства – некоммерческая 2.5

dist-mirrorpkg-mirrorauto-accept

CC-BY-NC-3.0

Creative Commons с указанием авторства – некоммерческая 3.0

dist-mirrorpkg-mirrorauto-accept

CC-BY-NC-4.0

Creative Commons с указанием авторства – некоммерческая 4.0

dist-mirrorpkg-mirrorauto-accept

CC-BY-NC-ND-1.0

Creative Commons с указанием авторства – некоммерческая – без производных 1.0

dist-mirrorpkg-mirrorauto-accept

CC-BY-NC-ND-2.0

Creative Commons с указанием авторства – некоммерческая – без производных 2.0

dist-mirrorpkg-mirrorauto-accept

CC-BY-NC-ND-2.5

Creative Commons с указанием авторства – некоммерческая – без производных 2.5

dist-mirrorpkg-mirrorauto-accept

CC-BY-NC-ND-3.0

Creative Commons с указанием авторства – некоммерческая – без производных 3.0

dist-mirrorpkg-mirrorauto-accept

CC-BY-NC-ND-4.0

Creative Commons с указанием авторства – некоммерческая – без производных 4.0

dist-mirrorpkg-mirrorauto-accept

CC-BY-NC-SA-1.0

Creative Commons с указанием авторства – некоммерческая – на тех же условиях 1.0

dist-mirrorpkg-mirrorauto-accept

CC-BY-NC-SA-2.0

Creative Commons с указанием авторства – некоммерческая – на тех же условиях 2.0

dist-mirrorpkg-mirrorauto-accept

CC-BY-NC-SA-2.5

Creative Commons с указанием авторства – некоммерческая – на тех же условиях 2.5

dist-mirrorpkg-mirrorauto-accept

CC-BY-NC-SA-3.0

Creative Commons с указанием авторства – некоммерческая – на тех же условиях 3.0

dist-mirrorpkg-mirrorauto-accept

CC-BY-NC-SA-4.0

Creative Commons с указанием авторства – некоммерческая – на тех же условиях 4.0

dist-mirrorpkg-mirrorauto-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. Страницы Cправочника

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

Изменено: 25 сентября 2025 г. by Fernando Apesteguía

Главная