--- description: 'Настройка Makefile для портов FreeBSD' next: books/porters-handbook/special params: path: /books/porters-handbook/makefiles/ prev: books/porters-handbook/slow-porting showBookMenu: 'true' tags: ["makefiles", "configuring", "naming", "versions"] title: 'Глава 5. Настройка Makefile' weight: 5 --- [[makefiles]] = Настройка Makefile :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 5 :partnums: :source-highlighter: rouge :experimental: :g-plus-plus: g++ :images-path: books/porters-handbook/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] Настройка [.filename]#Makefile# довольно проста, и мы снова рекомендуем изучить существующие примеры перед началом. Также в этом руководстве есть crossref:porting-samplem[porting-samplem,пример Makefile], поэтому ознакомьтесь с ним и, пожалуйста, соблюдайте порядок переменных и разделов в этом шаблоне, чтобы порт был удобнее для чтения другими. Рассмотрите эти проблемы последовательно при разработке нового [.filename]#Makefile#: [[makefile-source]] == Оригинальный исходный код Находится ли он в `DISTDIR` в виде стандартного архива ``gzip`` с именем вроде [.filename]#foozolix-1.2.tar.gz#? Если да, переходите к следующему шагу. Если нет, возможно, для формата имени файла дистрибутива потребуется переопределить одну или несколько переменных: `DISTVERSION`, `DISTNAME`, `EXTRACT_CMD`, `EXTRACT_BEFORE_ARGS`, `EXTRACT_AFTER_ARGS`, `EXTRACT_SUFX` или `DISTFILES`. В худшем случае создайте пользовательскую цель `do-extract`, чтобы переопределить стандартную. Это редко, если вообще когда-либо, необходимо. [[makefile-naming]] == Именование Первая часть [.filename]#Makefile# порта указывает его название, описывает номер версии и помещает его в соответствующую категорию. [[makefile-portname]] === `PORTNAME` Установите `PORTNAME` как базовое имя программы. Оно используется в качестве основы для пакета FreeBSD и для crossref:makefiles[makefile-distname,`DISTNAME`]. [IMPORTANT] ==== Название пакета должно быть уникальным во всём дереве портов. Убедитесь, что `PORTNAME` ещё не используется существующим портом и что никакой другой порт уже не имеет такой же `PKGBASE`. Если имя уже занято, добавьте либо crossref:makefiles[porting-pkgnameprefix-suffix,`PKGNAMEPREFIX`, либо `PKGNAMESUFFIX`]. ==== [[makefile-versions]] === Версии, `DISTVERSION` _или_ `PORTVERSION` Установите `DISTVERSION` в номер версии программы. `PORTVERSION` — это версия, используемая для пакета FreeBSD. Она будет автоматически вычислена из `DISTVERSION` в соответствии со схемой версионирования пакетов FreeBSD. Если версия содержит _буквы_, может потребоваться задать `PORTVERSION` вместо `DISTVERSION`. [IMPORTANT] ==== Только одна из переменных `PORTVERSION` и `DISTVERSION` может быть установлена одновременно. ==== Время от времени некоторые программы используют схему версионирования, которая несовместима с тем, как `DISTVERSION` преобразуется в `PORTVERSION`. [TIP] ==== При обновлении порта можно использовать аргумент `-t` утилиты man:pkg-version[8], чтобы проверить, является ли новая версия больше или меньше предыдущей. Смотрите ниже, как использовать man:pkg-version[8] для сравнения версий. ==== [[makefile-versions-ex-pkg-version]] .Использование man:pkg-version[8] для сравнения версий [example] ==== `pkg version -t` принимает две версии в качестве аргументов и возвращает `<`, `=` или `>`, если первая версия меньше, равна или больше второй версии соответственно. [source, shell] .... % pkg version -t 1.2 1.3 < <.> % pkg version -t 1.2 1.2 = <.> % pkg version -t 1.2 1.2.0 = <.> % pkg version -t 1.2 1.2.p1 > <.> % pkg version -t 1.2.a1 1.2.b1 < <.> % pkg version -t 1.2 1.2p1 < <.> .... <.> `1.2` идёт перед `1.3`. <.> `1.2` и `1.2` равны, так как имеют одинаковую версию. <.> `1.2` и `1.2.0` равны, так как ноль ничего не значит. <.> `1.2` идёт после `1.2.p1`, так как `.p1` означает «pre-release 1» (предрелизная версия 1). <.> `1.2.a1` предшествует `1.2.b1`, представьте "alpha" и "beta", где `a` идёт перед `b`. <.> `1.2` находится перед `1.2p1`, так же как `2p1` (читается как "2, уровень исправления 1") — это версия, следующая после любой `2.X`, но перед `3`. [NOTE] **** Здесь `a`, `b` и `p` используются так, как если бы они означали "альфа", "бета" или "пре-релиз" и "уровень патча", но на самом деле это просто буквы, которые сортируются в алфавитном порядке, поэтому можно использовать любую букву, и они будут отсортированы соответствующим образом. **** ==== .Примеры `DISTVERSION` и производной `PORTVERSION` [cols="10%,90%", frame="none", options="header"] |=== | DISTVERSION | .PORTVERSION |0.7.1d |0.7.1.d |10Alpha3 |10.a3 |3Beta7-pre2 |3.b7.p2 |8:f_17 |8f.17 |=== [[makefile-versions-ex1]] .Использование `DISTVERSION` [example] ==== Если версия содержит только числа, разделённые точками, тире или подчёркиваниями, используйте `DISTVERSION`. [.programlisting] .... PORTNAME= nekoto DISTVERSION= 1.2-4 .... Это сгенерирует `PORTVERSION` равный `1.2.4`. ==== [[makefile-versions-ex2]] .Использование `DISTVERSION` когда версия начинается с буквы или префикса [example] ==== Когда версия начинается или заканчивается буквой, или префиксом, или суффиксом, которые не являются частью версии, используйте `DISTVERSIONPREFIX`, `DISTVERSION` и `DISTVERSIONSUFFIX`. Если версия `v1.2-4`: [.programlisting] .... PORTNAME= nekoto DISTVERSIONPREFIX= v DISTVERSION= 1_2_4 .... Некоторые проекты, использующие GitHub, могут включать своё название в версии. Например, версия может выглядеть как `nekoto-1.2-4`: [.programlisting] .... PORTNAME= nekoto DISTVERSIONPREFIX= nekoto- DISTVERSION= 1.2_4 .... Эти проекты также иногда используют строку в конце версии, например, `1.2-4_RELEASE`: [.programlisting] .... PORTNAME= nekoto DISTVERSION= 1.2-4 DISTVERSIONSUFFIX= _RELEASE .... Или они делают и то, и другое, например, `nekoto-1.2-4_RELEASE`: [.programlisting] .... PORTNAME= nekoto DISTVERSIONPREFIX= nekoto- DISTVERSION= 1.2-4 DISTVERSIONSUFFIX= _RELEASE .... `DISTVERSIONPREFIX` и `DISTVERSIONSUFFIX` не будут использоваться при формировании `PORTVERSION`, а только в `DISTNAME`. Все сгенерируют `PORTVERSION` равный `1.2.4`. ==== [[makefile-versions-ex3]] .Использование `DISTVERSION`, когда версия содержит буквы, означающие "alpha", "beta" или "pre-release" [example] ==== Если версия содержит числа, разделённые точками, тире или подчёркиваниями, а буквы используются для обозначения "альфа", "бета" или "предварительной версии" (то есть до версии без букв), используйте `DISTVERSION`. [.programlisting] .... PORTNAME= nekoto DISTVERSION= 1.2-pre4 .... [.programlisting] .... PORTNAME= nekoto DISTVERSION= 1.2p4 .... Оба варианта создадут `PORTVERSION` равную `1.2.p4`, что предшествует версии 1.2. Для проверки этого факта можно использовать man:pkg-version[8]: [source, shell] .... % pkg version -t 1.2.p4 1.2 < .... ==== [[makefile-versions-ex4]] .Не использовать `DISTVERSION`, если версия содержит буквы, означающие "уровень патча" [example] ==== Если версия содержит буквы, которые не означают "alpha", "beta" или "pre", а скорее указывают на "уровень исправления" и следуют после версии без букв, используйте `PORTVERSION`. [.programlisting] .... PORTNAME= nekoto PORTVERSION= 1.2p4 .... В данном случае использование `DISTVERSION` невозможно, так как это приведёт к генерации версии `1.2.p4`, которая будет считаться более ранней, чем `1.2`, а не более поздней. man:pkg-version[8] подтвердит это: [source, shell] .... % pkg version -t 1.2 1.2.p4 > <.> % pkg version -t 1.2 1.2p4 < <.> .... <.> `1.2` идёт после `1.2.p4`, что в данном случае _неверно_. <.> `1.2` находится перед `1.2p4`, что и требовалось. ==== Для более сложных примеров настройки `PORTVERSION`, когда версия программного обеспечения действительно несовместима с FreeBSD, или `DISTNAME`, когда файл дистрибутива не содержит саму версию, см. crossref:makefiles[makefile-distname, `DISTNAME`]. [[makefile-naming-revepoch]] === `PORTREVISION` и `PORTEPOCH` [[makefile-portrevision]] ==== `PORTREVISION` `PORTREVISION` — это монотонно возрастающее значение, которое сбрасывается в 0 при каждом увеличении `DISTVERSION`, обычно при каждом новом официальном выпуске от поставщика. Если `PORTREVISION` не равен нулю, его значение добавляется к имени пакета. Изменения `PORTREVISION` используются автоматизированными инструментами, такими как man:pkg-version[8], для определения доступности нового пакета. `PORTREVISION` должен быть увеличен каждый раз, когда в порт вносятся изменения, которые так или иначе влияют на сгенерированный пакет. Это включает изменения, затрагивающие только пакеты, собранные с нестандартными crossref:makefiles[makefile-options,опциями]. Примеры случаев, когда необходимо увеличить `PORTREVISION`: * Добавление исправлений для устранения уязвимостей безопасности, ошибок или для добавления новой функциональности в порт. * Изменения в [.filename]#Makefile# порта для включения или отключения параметров сборки в пакете. * Изменения в списке файлов пакета или в поведении во время установки. Например, изменение скрипта, который генерирует начальные данные для пакета, такие как ключи хоста man:ssh[1]. * Увеличение версии зависимости порта от общей библиотеки (в данном случае, попытка установить старый пакет после установки более новой версии зависимости завершится неудачей, так как будет искаться старая версия libfoo.x вместо libfoo.(x+1)). * Тихие изменения в дистрибутивном файле порта, которые имеют значительные функциональные отличия. Например, изменения в дистрибутивном файле, требующие корректировки файла [.filename]#distinfo# без соответствующего изменения `DISTVERSION`, когда сравнение `diff -ru` старой и новой версий показывает нетривиальные изменения в коде. * Изменения в `MAINTAINER`. Примеры изменений, которые не требуют увеличения `PORTREVISION`: * Стилевые изменения в каркасе портов без функциональных изменений в итоговом пакете. * Изменения в `MASTER_SITES` или другие функциональные изменения порта, которые не влияют на итоговый пакет. * Тривиальные исправления в дистрибутивном файле, такие как исправление опечаток, которые не настолько важны, чтобы пользователи пакета были вынуждены тратить время на обновление. * Исправления сборки, которые позволяют пакету компилироваться там, где ранее это не удавалось. При условии, что изменения не вносят функциональных изменений на других платформах, где порт ранее собирался. Поскольку `PORTREVISION` отражает содержимое пакета, если пакет ранее не мог быть собран, то нет необходимости увеличивать `PORTREVISION` для обозначения изменений. Эмпирическое правило заключается в том, чтобы решить, является ли изменение, внесённое в порт, чем-то, что принесёт пользу _некоторым_ пользователям. Будь то улучшение, исправление или просто факт, что новый пакет вообще будет работать. Затем необходимо сопоставить это с тем, что всем, кто регулярно обновляет своё дерево портов, придётся выполнить обновление. Если ответ положительный, необходимо увеличить `PORTREVISION`. [NOTE] ==== Пользователи бинарных пакетов _никогда_ не увидят обновления, если `PORTREVISION` не увеличен. Без увеличения `PORTREVISION` сборщики пакетов не могут обнаружить изменение и, следовательно, не пересоберут пакет. ==== [[makefile-portepoch]] ==== `PORTEPOCH` Время от времени разработчики программного обеспечения или сопровождающие портов FreeBSD совершают ошибку и выпускают версию своего ПО, которая фактически имеет меньший номер по сравнению с предыдущей. Примером может служить переход с foo-20000801 на foo-1.0 (первая версия будет ошибочно считаться более новой, поскольку число 20000801 больше, чем 1.0). [TIP] ==== Результаты сравнения номеров версий не всегда очевидны. Команда `pkg version` (см. man:pkg-version[8]) может быть использована для проверки сравнения двух строк с номерами версий. Например: [source, shell] .... % pkg version -t 0.031 0.29 > .... Символ `>` в выводе указывает, что версия 0.031 считается больше, чем версия 0.29, что могло быть неочевидно для сопровождающего. ==== В таких ситуациях необходимо увеличить `PORTEPOCH`. Если `PORTEPOCH` не равен нулю, он добавляется к имени пакета, как описано в разделе 0 выше. `PORTEPOCH` никогда не должен уменьшаться или сбрасываться до нуля, потому что это приведёт к ошибке при сравнении с пакетом из более ранней эпохи. Например, пакет не будет обнаружен как устаревший. Новый номер версии, `1.0,1` в приведённом выше примере, всё ещё численно меньше предыдущей версии, 20000801, но суффикс `,1` обрабатывается автоматизированными инструментами особым образом и считается большим, чем подразумеваемый суффикс `,0` у предыдущего пакета. Неправильное удаление или сброс `PORTEPOCH` приводит к бесконечным проблемам. Если приведённое выше объяснение недостаточно ясно, обратитесь к {freebsd-ports}. Ожидается, что `PORTEPOCH` не будет использоваться для большинства портов, и что разумное использование `DISTVERSION` или аккуратное применение `PORTVERSION` часто может предотвратить необходимость его использования, если будущий выпуск программного обеспечения изменит структуру версий. Однако разработчикам портов FreeBSD следует быть осторожными, когда вендор выпускает релиз без официального номера версии — например, релиз в виде "снимка" кода. Возникает соблазн обозначить такой релиз датой выпуска, что вызовет проблемы, как в примере выше, когда будет сделан новый "официальный" релиз. Например, если снимок выпущен на дату `20000917`, а предыдущая версия программного обеспечения была `1.2`, не следует использовать `20000917` для `DISTVERSION`. Правильным будет указать `DISTVERSION` как `1.2.20000917` или подобное, чтобы следующая версия, например `1.3`, оставалась численно большей. [[makefile-portrevision-example]] ==== Пример использования `PORTREVISION` и `PORTEPOCH` Порт `gtkmumble` версии `0.10` добавлен в коллекцию портов: [.programlisting] .... PORTNAME= gtkmumble DISTVERSION= 0.10 .... `PKGNAME` становится `gtkmumble-0.10`. Обнаружена уязвимость в безопасности, требующая локального исправления FreeBSD. `PORTREVISION` соответствующим образом увеличивается. [.programlisting] .... 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 (или удаляется из [.filename]#Makefile#). [.programlisting] .... PORTNAME= gtkmumble DISTVERSION= 0.2 PORTEPOCH= 1 .... `PKGNAME` становится `gtkmumble-0.2,1` Следующий выпуск — 0.3. Поскольку `PORTEPOCH` никогда не уменьшается, переменные версий теперь выглядят так: [.programlisting] .... PORTNAME= gtkmumble DISTVERSION= 0.3 PORTEPOCH= 1 .... `PKGNAME` принимает значение `gtkmumble-0.3,1` [NOTE] ==== Если бы `PORTEPOCH` был сброшен в `0` при этом обновлении, пользователь, установивший пакет `gtkmumble-0.10_1`, не увидел бы пакет `gtkmumble-0.3` как более новый, поскольку `3` всё ещё численно меньше, чем `10`. Помните, в этом и заключается вся суть `PORTEPOCH` изначально. ==== [[porting-pkgnameprefix-suffix]] === `PKGNAMEPREFIX` и `PKGNAMESUFFIX` Две необязательные переменные, `PKGNAMEPREFIX` и `PKGNAMESUFFIX`, объединяются с `PORTNAME` и `PORTVERSION` для формирования `PKGNAME` в виде `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Убедитесь, что это соответствует нашим crossref:makefiles[porting-pkgname,рекомендациям по именованию пакетов]. В частности, использование дефиса (`-`) в `PORTVERSION` _не_ допускается. Кроме того, если имя пакета содержит часть _language-_ или _-compiled.specifics_ (см. ниже), используйте `PKGNAMEPREFIX` и `PKGNAMESUFFIX` соответственно. Не включайте их в `PORTNAME`. [[porting-pkgname]] === Соглашения о наименовании пакетов Вот соглашения, которым следует придерживаться при наименовании пакетов. Это сделано для того, чтобы каталог пакетов было легко просматривать, поскольку там уже тысячи пакетов, и пользователи могут отказаться от их использования, если это будет напрягать их глаза! Имена пакетов имеют формат [.filename]#language_region-name-compiled.specifics-version.numbers#. Имя пакета определяется как `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Убедитесь, что переменные заданы в соответствии с этим форматом. [[porting-pkgname-language]] [.filename]#language_region-#:: FreeBSD стремится поддерживать родной язык своих пользователей. Часть _language-_ представляет собой двухбуквенное сокращение естественного языка, определённое стандартом ISO-639, когда порт относится к определённому языку. Примерами являются `ja` для японского, `ru` для русского, `vi` для вьетнамского, `zh` для китайского, `ko` для корейского и `de` для немецкого. + Если порт относится к определённому региону в языковой зоне, добавьте также двухбуквенный код страны. Например, `en_US` для американского английского и `fr_CH` для швейцарского французского. + Часть _language-_ задается в `PKGNAMEPREFIX`. [[porting-pkgname-name]] [.filename]#name#:: Убедитесь, что название порта и его версия четко разделены и указаны в `PORTNAME` и `DISTVERSION`. Единственная причина, по которой `PORTNAME` может содержать часть версии, — это если вышестоящее распространяемое ПО действительно так названо, как в портах package:textproc/libxml2[] или package:japanese/kinput2-freewnn[]. В противном случае `PORTNAME` не может содержать информацию о версии. Довольно нормально, когда несколько портов имеют одинаковый `PORTNAME`, как это делают порты package:www/apache*[]; в таком случае разные версии (и разные записи в индексе) различаются значениями `PKGNAMEPREFIX` и `PKGNAMESUFFIX`. + Существует традиция называть модули `Perl 5`, добавляя префикс `p5-` и заменяя разделитель в виде двойного двоеточия на дефис. Например, модуль `Data::Dumper` становится `p5-Data-Dumper`. [[porting-pkgname-compiled-specifics]] [.filename]#-compiled.specifics#:: Если порт может быть собран с различными crossref:makefiles[makefile-masterdir,жёстко заданными значениями по умолчанию] (обычно это часть имени каталога в семействе портов), часть _-compiled.specifics_ указывает скомпилированные значения по умолчанию. Дефис является необязательным. Примерами могут служить размер бумаги и единицы измерения шрифтов. + Часть _-compiled.specifics_ задаётся в `PKGNAMESUFFIX`. [[porting-pkgname-version-numbers]] [.filename]#-version.numbers#:: Строка версии следует после тире (`-`) и представляет собой разделённый точками список целых чисел и строчных букв латинского алфавита. В частности, не допускается использование дополнительных тире внутри строки версии. Единственное исключение — строка `pl` (означающая "уровень исправления"), которую можно использовать _только_ в случае отсутствия у программного обеспечения номеров основной и дополнительной версий. Если в версии программного обеспечения встречаются строки типа "alpha", "beta", "rc" или "pre", следует взять первую букву и поместить её сразу после точки. Если после таких названий строка версии продолжается, числа следуют за буквой без дополнительной точки между ними (например, `1.0b2`). + Идея заключается в упрощении сортировки портов за счёт анализа строки версии. В частности, необходимо убедиться, что компоненты номера версии всегда разделены точкой, а если дата является частью строки, использовать формат `d__yyyy.mm.dd__`, а не `_dd.mm.yyyy_` или не соответствующий стандарту Y2K формат `_yy.mm.dd_`. Важно добавлять перед версией букву, в данном случае `d` (от слова "дата"), на случай, если будет выпущена версия с фактическим номером, который численно окажется меньше `_yyyy_`. [IMPORTANT] ==== Название пакета должно быть уникальным среди всех портов в дереве. Убедитесь, что порт с таким же `PORTNAME` ещё не существует, и если он есть, добавьте один из crossref:makefiles[porting-pkgnameprefix-suffix,`PKGNAMEPREFIX` или `PKGNAMESUFFIX`]. ==== Вот несколько (реальных) примеров преобразования названия, указанного авторами программного обеспечения, в подходящее имя пакета. В каждой строке указана только одна из переменных `DISTVERSION` или `PORTVERSION`, в зависимости от того, какая используется в [.filename]#Makefile# порта: .Примеры наименования пакетов [cols="1,1,1,1,1,1,1", frame="none", options="header"] |=== | Имя дистрибутива | PKGNAMEPREFIX | PORTNAME | PKGNAMESUFFIX | DISTVERSION | .PORTVERSION | Причина или комментарий |mule-2.2.2 |(пусто) |mule |(пусто) |2.2.2 | |Никаких изменений не требуется |mule-1.0.1 |(пусто) |mule |1 |1.0.1 | |Это версия 1 mule, а версия 2 уже существует |EmiClock-1.0.2 |(пусто) |emiclock |(пусто) |1.0.2 | |Нет имён в верхнем регистре для отдельных программ |rdist-1.3alpha |(пусто) |rdist |(пусто) |1.3alpha | |Версия будет `1.3.a` |es-0.9-beta1 |(пусто) |es |(пусто) |0.9-beta1 | |Версия будет `0.9.b1` |mailman-2.0rc3 |(пусто) |mailman |(пусто) |2.0rc3 | |Версия будет `2.0.r3` |v3.3beta021.src |(пусто) |tiff |(пусто) | |3.3 |Что это вообще было? |tvtwm |(пусто) |tvtwm |(пусто) | |p11 |Нет версии в имени файла, используйте то, что указано в исходном коде |piewm |(пусто) |piewm |(пусто) |1.0 | |Нет версии в имени файла, используйте то, что указано в исходном коде |xvgr-2.10pl1 |(пусто) |xvgr |(пусто) | |2.10.pl1 |В таком случае, `pl1` означает уровень патча, поэтому использование DISTVERSION невозможно. |gawk-2.15.6 |ja- |gawk |(пусто) |2.15.6 | |Японская языковая версия |psutils-1.13 |(пусто) |psutils |-letter |1.13 | |Размер бумаги жёстко задан во время сборки пакета |pkfonts |(пусто) |pkfonts |300 |1.0 | |Пакет для шрифтов с разрешением 300dpi |=== Если в исходном источнике полностью отсутствует информация о версии и маловероятно, что автор когда-либо выпустит новую версию, просто укажите строку версии как `1.0` (как в примере с `piewm` выше). В противном случае, спросите автора или используйте дату выпуска исходного файла в формате `d__yyyy.mm.dd__` или `d__yyyymmdd__` в качестве версии. [TIP] ==== Используйте любую букву. Здесь `d` означает дату, если источник — это репозиторий Git, часто используется `g` с последующей датой коммита, также распространено использование `s` для снимка. ==== [[makefile-categories]] == Категоризация [[makefile-categories-definition]] === `CATEGORIES` При создании пакета он помещается в [.filename]#/usr/ports/packages/All#, и ссылки на него создаются в одном или нескольких подкаталогах [.filename]#/usr/ports/packages#. Имена этих подкаталогов задаются переменной `CATEGORIES`. Это предназначено для облегчения поиска пакетов пользователем при просмотре большого количества пакетов на FTP-сайте или CDROM. Пожалуйста, ознакомьтесь с crossref:makefiles[porting-categories,текущим списком категорий] и выберите подходящие для данного порта. Этот список также определяет, где в дереве портов будет размещён порт. Если здесь указано несколько категорий, файлы порта должны быть помещены в подкаталог с названием первой категории. Дополнительные сведения о выборе подходящих категорий см. в crossref:makefiles[choosing-categories,ниже]. [[porting-categories]] === Текущий список категорий Вот текущий список категорий портов. Категории, помеченные звёздочкой (`*`), являются _виртуальными_ — они не имеют соответствующего подкаталога в дереве портов. Они используются только как вторичные категории и исключительно для целей поиска. [NOTE] ==== Для невиртуальных категорий в `COMMENT` в [.filename]#Makefile# соответствующего подкаталога содержится однострочное описание. ==== [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Категория | Описание | Заметки |[.filename]#accessibility# |Порты для помощи пользователям с ограниченными возможностями. | |[.filename]#afterstep#`*` |Порты для поддержки оконного менеджера http://www.afterstep.org/[AfterStep]. | |[.filename]#arabic# |Поддержка арабского языка. | |[.filename]#archivers# |Инструменты для архивирования. | |[.filename]#astro# |Астрономические порты. | |[.filename]#audio# |Поддержка звука. | |[.filename]#benchmarks# |Утилиты для тестирования производительности. | |[.filename]#biology# |Программное обеспечение, связанное с биологией. | |[.filename]#budgie#`*` |Программное обеспечение, связанное со средой рабочего стола Budgie. | |[.filename]#cad# |Компьютерные средства автоматизированного проектирования. | |[.filename]#chinese# |Поддержка китайского языка. | |[.filename]#comms# |Программное обеспечение для связи. |В основном программное обеспечение для работы с последовательным портом. |[.filename]#converters# |Преобразователи символьных кодировок. | |[.filename]#databases# |Базы данных. | |[.filename]#deskutils# |Вещи, которые раньше находились на рабочем столе до изобретения компьютеров. | |[.filename]#devel# |Средства разработки. |Не размещайте библиотеки здесь только потому, что они являются библиотеками. Они _не_ должны быть в этой категории, если только они действительно не подходят никуда больше. |[.filename]#dns# |Программное обеспечение, связанное с DNS. | |[.filename]#docs#`*` |Мета-порты для документации FreeBSD. | |[.filename]#editors# |Общие редакторы. |Специализированные редакторы помещаются в раздел соответствующих инструментов. Например, редактор математических формул будет помещён в [.filename]#math#, а [.filename]#editors# будет для него второй категорией. |[.filename]#education#`*` |Программное обеспечение для образования. |Это включает приложения, утилиты или игры, разработанные в первую очередь или в значительной степени для помощи пользователю в изучении конкретной темы или обучении в целом. Также сюда входят приложения для создания курсов, приложения для предоставления курсов и приложения для управления классом или школой |[.filename]#elisp#`*` |Порты Emacs-lisp. | |[.filename]#emulators# |Эмуляторы других операционных систем. |Терминальные эмуляторы _не_ относятся сюда. Основанные на X идут в [.filename]#x11#, а текстовые — либо в [.filename]#comms#, либо в [.filename]#misc#, в зависимости от конкретной функциональности. |[.filename]#enlightenment#`*` |Порты, связанные с оконным менеджером Enlightenment. | |[.filename]#filesystems# |Файловые системы и связанные утилиты. | |[.filename]#finance# |Монетарные, финансовые и связанные с ними приложения. | |[.filename]#french# |Поддержка французского языка. | |[.filename]#ftp# |Клиентские и серверные утилиты FTP. |Если порт поддерживает как FTP, так и HTTP, поместите его в [.filename]#ftp# с дополнительной категорией [.filename]#www#. |[.filename]#games# |Игры. | |[.filename]#география#`*` |Программное обеспечение, связанное с географией. | |[.filename]#german# |Поддержка немецкого языка. | |[.filename]#gnome#`*` |Порты из проекта https://www.gnome.org/[GNOME]. | |[.filename]#gnustep#`*` |Программное обеспечение, связанное со средой рабочего стола GNUstep. | |[.filename]#graphics# |Графические утилиты. | |[.filename]#hamradio#`*` |Программное обеспечение для радиолюбителей. | |[.filename]#haskell#`*` |Программное обеспечение, связанное с языком Haskell. | |[.filename]#hebrew# |Поддержка иврита. | |[.filename]#hungarian# |Венгерская языковая поддержка. | |[.filename]#irc# |Утилиты Internet Relay Chat. | |[.filename]#japanese# |Поддержка японского языка. | |[.filename]#java# |Программное обеспечение, связанное с языком Java(TM). |Категория [.filename]#java# не должна быть единственной для порта. За исключением портов, непосредственно связанных с языком Java, разработчикам также рекомендуется не использовать [.filename]#java# в качестве основной категории для порта. |[.filename]#kde#`*` |Порты проекта https://www.kde.org/[KDE] (общие). | |[.filename]#kde-приложения#`*` |Приложения от проекта https://www.kde.org/[KDE]. | |[.filename]#kde-frameworks#`*` |Дополнительные библиотеки от проекта https://www.kde.org/[KDE] для программирования с использованием Qt. | |[.filename]#kde-plasma#`*` |Рабочий стол от проекта https://www.kde.org/[KDE]. | |[.filename]#kld#`*` |Загружаемые модули ядра. | |[.filename]#korean# |Поддержка корейского языка. | |[.filename]#lang# |Языки программирования. | |[.filename]#linux#`*` |Приложения и вспомогательные утилиты Linux. | |[.filename]#lisp#`*` |Программное обеспечение, связанное с языком Lisp. | |[.filename]#mail# |Почтовое программное обеспечение. | |[.filename]#mate#`*` |Порты, связанные с окружением рабочего стола MATE, форком GNOME 2. | |[.filename]#math# |Численные расчеты и другие математические утилиты. | |[.filename]#mbone#`*` |Приложения MBone. | |[.filename]#misc# |Различные утилиты |Вещи, которые не подходят никуда больше. По возможности, попытайтесь найти для порта категорию лучше, чем `misc`, так как порты здесь часто остаются без внимания. |[.filename]#multimedia# |Мультимедийное программное обеспечение. | |[.filename]#net# |Различное сетевое программное обеспечение. | |[.filename]#net-im# |Программное обеспечение для обмена мгновенными сообщениями. | |[.filename]#net-mgmt# |Программное обеспечение для управления сетями. | |[.filename]#net-p2p# |Одноранговые сетевые приложения. | |[.filename]#сеть-vpn#`*` |Виртуальные частные сети. | |[.filename]#news# |Программное обеспечение для USENET-новостей. | |[.filename]#parallel#`*` |Приложения, работающие с параллелизмом в вычислениях. | |[.filename]#pear#`*` |Порты, связанные с PHP-фреймворком Pear. | |[.filename]#perl5#`*` |Порты, требующие Perl версии 5 для работы. | |[.filename]#plan9#`*` |Различные программы с https://9p.io/wiki/plan9/Download/index.html[Plan9]. | |[.filename]#polish# |Поддержка польского языка. | |[.filename]#ports-mgmt# |Порты для управления, установки и разработки портов и пакетов FreeBSD. | |[.filename]#portuguese# |Поддержка португальского языка. | |[.filename]#print# |Программное обеспечение для печати. |Инструменты для настольных издательских систем (превьюеры и т. д.) также относятся сюда. |[.filename]#python#`*` |Программное обеспечение, связанное с языком https://www.python.org/[Python]. | |[.filename]#ruby#`*` |Программное обеспечение, связанное с языком https://www.ruby-lang.org/[Ruby]. | |[.filename]#rubygems#`*` |Порты пакетов https://www.rubygems.org/[RubyGems]. | |[.filename]#russian# |Поддержка русского языка. | |[.filename]#scheme#`*` |Программное обеспечение, связанное с языком Scheme. | |[.filename]#science# |Научные порты, которые не входят в другие категории, такие как [.filename]#astro#, [.filename]#biology# и [.filename]#math#. | |[.filename]#security# |Средства обеспечения безопасности. | |[.filename]#shells# |Командные оболочки. | |[.filename]#spanish#`*` |Поддержка испанского языка. | |[.filename]#sysutils# |Системные утилиты. | |[.filename]#tcl#`*` |Порты, использующие Tcl для запуска. | |[.filename]#textproc# |Средства обработки текста. |Он не включает инструменты для настольных издательских систем, которые помещаются в [.filename]#print#. |[.filename]#tk#`*` |Порты, использующие Tk для работы. | |[.filename]#ukrainian# |Поддержка украинского языка. | |[.filename]#vietnamese# |Поддержка вьетнамского языка. | |[.filename]#wayland#`*` |Порты для поддержки сервера дисплея Wayland. | |[.filename]#windowmaker#`*` |Порты для поддержки оконного менеджера Window Maker. | |[.filename]#www# |Программное обеспечение, связанное с Всемирной паутиной. |Поддержка языка HTML также относится сюда. |[.filename]#x11# |Система X Window и связанные компоненты. |Эта категория предназначена только для программного обеспечения, которое напрямую поддерживает оконную систему. Не помещайте сюда обычные X-приложения. Большинство из них относятся к другим категориям [.filename]#x11-*# (см. ниже). |[.filename]#x11-clocks# |Часы X11. | |[.filename]#x11-drivers# |Драйверы X11. | |[.filename]#x11-fm# |Менеджеры файлов X11. | |[.filename]#x11-fonts# |Шрифты и утилиты для работы со шрифтами в X11. | |[.filename]#x11-servers# |Серверы X11. | |[.filename]#x11-themes# |Темы X11. | |[.filename]#x11-toolkits# |Инструментарии X11. | |[.filename]#x11-wm# |Оконные менеджеры X11. | |[.filename]#xfce#`*` |Порты, связанные с окружением рабочего стола https://www.xfce.org/[Xfce]. | |[.filename]#zope#`*` |https://www.zope.org/[Zope] поддержка. | |=== [[choosing-categories]] === Выбор подходящей категории Поскольку многие категории пересекаются, выбор основной категории для порта может быть утомительным. Существует несколько правил, регулирующих этот вопрос. Вот список приоритетов в порядке убывания важности: * Первая категория должна быть физической (см. crossref:makefiles[porting-categories,выше]). Это необходимо для работы упаковки. Виртуальные категории и физические категории могут чередоваться после этого. * Языковые категории всегда указываются первыми. Например, если порт устанавливает японские шрифты для X11, то строка `CATEGORIES` будет выглядеть так: [.filename]#japanese x11-fonts#. * Конкретные категории перечислены перед менее специфичными. Например, HTML-редактор указывается как [.filename]#www editors#, а не наоборот. Также не следует указывать [.filename]#net#, если порт принадлежит к любой из категорий [.filename]#irc#, [.filename]#mail#, [.filename]#news#, [.filename]#security# или [.filename]#www#, так как [.filename]#net# подразумевается автоматически. * [.filename]#x11# используется как вторичная категория только в случае, когда основной категорией указан естественный язык. В частности, не указывайте [.filename]#x11# в строке категории для X-приложений. * Режимы Emacs размещаются в той же категории портов, что и приложение, поддерживаемое данным режимом, а не в [.filename]#editors#. Например, режим Emacs для редактирования исходных файлов какого-либо языка программирования попадает в [.filename]#lang#. * Порты, устанавливающие загружаемые модули ядра, также имеют виртуальную категорию [.filename]#kld# в строке `CATEGORIES`. Это одна из вещей, автоматически обрабатываемых при добавлении `USES=kmod`. * [.filename]#misc# не встречается вместе с другими невиртуальными категориями. Если `misc` указан вместе с чем-то ещё в `CATEGORIES`, это означает, что `misc` можно безопасно удалить, а порт разместить только в другом подкаталоге. * Если порт действительно не подходит никуда больше, поместите его в [.filename]#misc#. Если категория не определена четко, пожалуйста, укажите это в комментарии при https://bugs.freebsd.org/submit/[отправке порта] в баг-трекере, чтобы мы могли обсудить её перед импортом. Как коммиттер, отправьте сообщение в рассылку {freebsd-ports}, чтобы мы сначала обсудили это. Слишком часто новые порты импортируются в неправильную категорию, после чего их сразу же приходится перемещать. [[proposing-categories]] === Предложение новой категории По мере роста Коллекции портов со временем были введены различные новые категории. Новые категории могут быть _виртуальными_ — те, у которых нет соответствующего подкаталога в дереве портов, или _физическими_ — те, у которых он есть. В этом разделе обсуждаются вопросы, связанные с созданием новой физической категории. Внимательно ознакомьтесь с ним, прежде чем предлагать новую. Наша текущая практика заключается в том, чтобы избегать создания новой физической категории, если только либо большое количество портов логически принадлежит к ней, либо порты, которые к ней относятся, представляют собой логически обособленную группу, представляющую ограниченный общий интерес (например, категории, связанные с разговорными человеческими языками), или, желательно, оба условия одновременно. Обоснование этого заключается в том, что такое изменение создает extref:{committers-guide}[значительный объём работы, ports] как для коммиттеров, так и для всех пользователей, которые отслеживают изменения в Коллекции портов. Кроме того, предлагаемые изменения категорий, как правило, вызывают споры. (Возможно, это связано с отсутствием четкого консенсуса относительно того, когда категория становится «слишком большой», а также относительно того, должны ли категории способствовать удобству просмотра (и, следовательно, какое количество категорий было бы идеальным), и так далее.) Вот процедура: [.procedure] . Предложите новую категорию на {freebsd-ports}. Включите подробное обоснование для новой категории, объясните, почему существующие категории недостаточны, и укажите список существующих портов, предлагаемых к перемещению. (Если в Bugzilla есть ожидающие рассмотрения новые порты, которые подходят под эту категорию, также перечислите их.) Если вы являетесь сопровождающим или подающим предложение, укажите это, так как это может помочь в рассмотрении. . Участвуйте в обсуждении. . Если кажется, что идея находит поддержку, оформите PR, включающий как обоснование, так и список существующих портов, которые необходимо переместить. В идеале, этот PR также должен содержать следующие исправления: ** [.filename]##Makefile## для новых портов после копирования их репозитория ** [.filename]#Makefile# для новой категории ** [.filename]#Makefile# для старых категорий портов ** [.filename]##Makefile## для портов, зависящих от старых портов ** (для дополнительной оценки включите другие файлы, которые необходимо изменить, в соответствии с процедурой, описанной в Руководстве коммиттера.) . Поскольку это затрагивает инфраструктуру портов и включает перемещение и исправление многих портов, а также, возможно, проведение регрессионных тестов на сборочном кластере, назначьте PR для {portmgr}. . Если этот PR будет одобрен, коммиттер должен будет выполнить оставшуюся часть процедуры, extref:{committers-guide}[описанной в Руководстве коммиттера,ports]. Предложение новой виртуальной категории аналогично описанному выше, но гораздо менее трудоёмко, так как фактически не потребуется перемещать порты. В этом случае единственные патчи, которые нужно включить в PR, — это добавление новой категории в `CATEGORIES` затронутых портов. [[proposing-reorg]] === Предложение о реорганизации всех категорий Изредка кто-то предлагает реорганизовать категории, используя либо двухуровневую структуру, либо какую-либо другую структуру ключевых слов. На сегодняшний день ни одно из этих предложений не было реализовано, потому что, хотя их очень легко выдвинуть, усилия, необходимые для переработки всей существующей коллекции портов в рамках любой реорганизации, пугают, мягко говоря. Пожалуйста, ознакомьтесь с историей этих предложений в архивах списка рассылки, прежде чем публиковать эту идею. Более того, будьте готовы к тому, что вас попросят предоставить рабочий прототип. [[makefile-distfiles]] == Файлы дистрибутива Вторая часть [.filename]#Makefile# описывает файлы, которые необходимо загрузить для сборки порта, и места, откуда их можно скачать. [[makefile-distname]] === `DISTNAME` `DISTNAME` — это имя порта, используемое авторами программного обеспечения. По умолчанию `DISTNAME` имеет значение `${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}`, а если не задано, `DISTVERSION` по умолчанию принимает значение `${PORTVERSION}`, поэтому переопределяйте `DISTNAME` только при необходимости. `DISTNAME` используется только в двух случаях. Во-первых, список файлов дистрибутива (`DISTFILES`) по умолчанию имеет значение `${DISTNAME}${EXTRACT_SUFX}`. Во-вторых, ожидается, что файл дистрибутива распакуется в подкаталог с именем `WRKSRC`, который по умолчанию равен [.filename]#work/${DISTNAME}#. Некоторые названия дистрибутивов от поставщиков, которые не соответствуют схеме `${PORTNAME}-${PORTVERSION}`, могут обрабатываться автоматически путем установки `DISTVERSIONPREFIX`, `DISTVERSION` и `DISTVERSIONSUFFIX`. `PORTVERSION` будет автоматически вычисляться из `DISTVERSION`. [IMPORTANT] ==== Только одна из переменных `PORTVERSION` и `DISTVERSION` может быть установлена одновременно. Если `DISTVERSION` не определяет корректную `PORTVERSION`, не используйте `DISTVERSION`. ==== Если схема версий исходного проекта может быть преобразована в схему, совместимую с портами, установите некоторую переменную в версию исходного проекта, _не используйте_ имя переменной `DISTVERSION`. Установите `PORTVERSION` в вычисленную версию на основе созданной переменной и задайте `DISTNAME` соответствующим образом. Если схема версионирования вышестоящего проекта не может быть легко преобразована в значение, совместимое с портами, установите `PORTVERSION` в разумное значение и задайте `DISTNAME` как `PORTNAME` с дословной версией вышестоящего проекта. [[makefile-distname-ex1]] .Получение `PORTVERSION` вручную [example] ==== BIND9 использует схему версионирования, несовместимую с версиями портов (в версиях используется `-`), и её нельзя получить с помощью `DISTVERSION`, так как после выпуска 9.9.9 выходят «уровни исправлений» в формате `9.9.9-P1`. `DISTVERSION` преобразует это в `9.9.9.p1`, что в схеме версионирования портов означает 9.9.9 pre-release 1, то есть версию, предшествующую 9.9.9, а не следующую за ней. Поэтому `PORTVERSION` вручную формируется из переменной `ISCVERSION`, чтобы получить `9.9.9p1`. Порядок, в котором система портов и pkg будут сортировать версии, проверяется с помощью аргумента `-t` из man:pkg-version[8]: [source, shell] .... % pkg version -t 9.9.9 9.9.9.p1 > <.> % pkg version -t 9.9.9 9.9.9p1 < <.> .... <.> Знак `>` означает, что первый аргумент, переданный в `-t`, больше второго аргумента. `9.9.9` находится после `9.9.9.p1`. <.> Знак `<` означает, что первый аргумент, переданный в `-t`, меньше второго аргумента. `9.9.9` находится перед `9.9.9p1`. В файле [.filename]#Makefile# порта, например package:dns/bind99[], это достигается с помощью: [.programlisting] .... PORTNAME= bind PORTVERSION= ${ISCVERSION:S/-P/P/:S/b/.b/:S/a/.a/:S/rc/.rc/} CATEGORIES= dns net MASTER_SITES= ISC/bind9/${ISCVERSION} PKGNAMESUFFIX= 99 DISTNAME= ${PORTNAME}-${ISCVERSION} MAINTAINER= mat@FreeBSD.org COMMENT= BIND DNS suite with updated DNSSEC and DNS64 WWW= https://www.isc.org/bind/ LICENSE= ISCL # ISC releases things like 9.8.0-P1 or 9.8.1rc1, which our versioning does not like ISCVERSION= 9.9.9-P6 .... Определите версию вышестоящего пакета в `ISCVERSION`, с комментарием, объясняющим, _почему_ это необходимо. Используйте `ISCVERSION` для получения совместимого с портами `PORTVERSION`. Используйте `ISCVERSION` напрямую для получения правильного URL для загрузки файла дистрибутива. Используйте `ISCVERSION` напрямую для именования дистрибутивного файла. ==== [[makefile-distname-ex2]] .Получить `DISTNAME` из `PORTVERSION` [example] ==== Время от времени имя файла дистрибутива имеет мало отношения или вообще никакого отношения к версии программного обеспечения. В пакете package:comms/kermit[], в файле дистрибутива присутствует только последний элемент версии: [.programlisting] .... PORTNAME= kermit PORTVERSION= 9.0.304 CATEGORIES= comms ftp net MASTER_SITES= ftp://ftp.kermitproject.org/kermit/test/tar/ DISTNAME= cku${PORTVERSION:E}-dev20 .... Модификатор `:E` man:make[1] возвращает суффикс переменной, в данном случае `304`. Файл дистрибутива корректно создаётся как `cku304-dev20.tar.gz`. ==== [[makefile-distname-ex3]] .Экзотический случай 1 [example] ==== Иногда нет связи между названием программы, её версией и файлом дистрибутива, в котором она распространяется. Из пакета package:audio/libworkman[]: [.programlisting] .... PORTNAME= libworkman PORTVERSION= 1.4 CATEGORIES= audio MASTER_SITES= LOCAL/jim DISTNAME= ${PORTNAME}-1999-06-20 .... ==== [[makefile-distname-ex4]] .Экзотический случай 2 [example] ==== В пакете package:comms/librs232[] файл дистрибутива не имеет версии, поэтому необходимо использовать crossref:makefiles[makefile-dist_subdir,`DIST_SUBDIR`]: [.programlisting] .... PORTNAME= librs232 PORTVERSION= 20160710 CATEGORIES= comms MASTER_SITES= http://www.teuniz.net/RS-232/ DISTNAME= RS-232 DIST_SUBDIR= ${PORTNAME}-${PORTVERSION} .... ==== [NOTE] ==== `PKGNAMEPREFIX` и `PKGNAMESUFFIX` не влияют на `DISTNAME`. Также обратите внимание, что если `WRKSRC` равно [.filename]#${WRKDIR}/${DISTNAME}#, а исходный архив с исходным кодом называется иначе, чем `${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}`, оставьте `DISTNAME` без изменений — определение только `DISTFILES` проще, чем определение и `DISTNAME`, и `WRKSRC` (а возможно, и `EXTRACT_SUFX`). ==== [[makefile-master_sites]] === `MASTER_SITES` Запишите именем каталога из FTP/HTTP-URL, указывающего на исходный tarball, в `MASTER_SITES`. Не забудьте завершающий слэш ([.filename]#/#)! Макросы `make` будут пытаться использовать эту спецификацию для загрузки файла дистрибутива с помощью `FETCH`, если не смогут найти его уже в системе. Рекомендуется включать в этот список несколько сайтов, желательно с разных континентов. Это обеспечит защиту от проблем в глобальной сети. [IMPORTANT] ==== `MASTER_SITES` не должен быть пустым. Он должен указывать на реальный сайт, где размещены файлы дистрибутива. Он не может указывать на веб-архивы или кэшированные сайты с файлами дистрибутива FreeBSD. Единственное исключение из этого правила — порты, у которых нет файлов дистрибутива. Например, мета-порты не имеют файлов дистрибутива, поэтому `MASTER_SITES` не нужно задавать. ==== [[makefile-master_sites-shorthand]] ==== Использование переменных `MASTER_SITE_*` Для популярных архивов, таких как SourceForge (`SOURCEFORGE`), GNU (`GNU`) или Perl CPAN (`PERL_CPAN`), доступны сокращённые обозначения. `MASTER_SITES` может использовать их напрямую: [.programlisting] .... MASTER_SITES= GNU/make .... Старый расширенный формат по-прежнему работает, но все порты были преобразованы в компактный формат. Расширенный формат выглядит следующим образом: [.programlisting] .... MASTER_SITES= ${MASTER_SITE_GNU} MASTER_SITE_SUBDIR= make .... Эти значения и переменные определены в https://cgit.freebsd.org/ports/tree/Mk/bsd.sites.mk[Mk/bsd.sites.mk]. Новые записи добавляются часто, поэтому обязательно проверяйте последнюю версию этого файла перед отправкой порта. [TIP] ==== Для любой переменной `MASTER_SITE_FOO` можно использовать сокращение `_FOO_`. Например, используйте: [.programlisting] .... MASTER_SITES= FOO .... Если требуется `MASTER_SITE_SUBDIR`, используйте следующее: [.programlisting] .... MASTER_SITES= FOO/bar .... ==== [NOTE] ==== Некоторые имена `MASTER_SITE_*` довольно длинные, и для удобства использования были определены сокращения: [[makefile-master_sites-shortcut]] .Сокращения для макросов `MASTER_SITE_*` [cols="1,1", frame="none", options="header"] |=== | Макрос | Сокращение |`PERL_CPAN` |`CPAN` |`GITHUB` |`GH` |`GITHUB_CLOUD` |`GHC` |`LIBREOFFICE_DEV` |`LODEV` |`NETLIB` |`NL` |`RUBYGEMS` |`RG` |`SOURCEFORGE` |`SF` |=== ==== [[makefile-master_sites-magic]] ==== Волшебные макросы MASTER_SITES Существует несколько "волшебных" макросов для популярных сайтов с предсказуемой структурой каталогов. Для них достаточно использовать сокращение, и система автоматически выберет подкаталог. Например, для порта с именем `Stardict`, версии `1.2.3`, размещенного на SourceForge, добавьте следующую строку: [.programlisting] .... MASTER_SITES= SF .... подразумевает подкаталог с именем `/project/stardict/stardict/1.2.3`. Если подразумеваемый каталог указан неверно, его можно переопределить: [.programlisting] .... MASTER_SITES= SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION} .... Это также можно записать как [.programlisting] .... MASTER_SITES= SF MASTER_SITE_SUBDIR= stardict/WyabdcRealPeopleTTS/${PORTVERSION} .... [[makefile-master_sites-popular]] .Волшебные макросы `MASTER_SITES` [cols="1,1", frame="none", options="header"] |=== | Макрос | Предполагаемый подкаталог |`APACHE_COMMONS_BINARIES` |`${PORTNAME:S,commons-,,}` |`APACHE_COMMONS_SOURCE` |`${PORTNAME:S,commons-,,}` |`APACHE_JAKARTA` |`${PORTNAME:S,-,/,}/source` |`BERLIOS` |`${PORTNAME:tl}.berlios` |`PYPI` |`source/${DISTNAME:C/(.).\*/\1/}/${DISTNAME:C/(.*)-[0-9].*/\1/}` |`CPAN` |`${PORTNAME:C/-.*//}` |`DEBIAN` |`pool/main/${PORTNAME:C/^((lib)?.).*$/\1/}/${PORTNAME}` |`FARSIGHT` |`${PORTNAME}` |`FESTIVAL` |`${PORTREVISION}` |`GCC` |`releases/${DISTNAME}` |`GENTOO` |`distfiles` |`GIMP` |`${PORTNAME}/${PORTVERSION:R}/` |`GH` |`${GH_ACCOUNT}/${GH_PROJECT}/tar.gz/${GH_TAGNAME}?dummy=/` |`GHC` |`${GH_ACCOUNT}/${GH_PROJECT}/` |`GNOME` |`sources/${PORTNAME}/${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}` |`GNU` |`${PORTNAME}` |`GNUPG` |`${PORTNAME}` |`GNU_ALPHA` |`${PORTNAME}` |`HORDE` |`${PORTNAME}` |`LODEV` |`${PORTNAME}` |`MATE` |`${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}` |`MOZDEV` |`${PORTNAME:tl}` |`NL` |`${PORTNAME}` |`QT` |`archive/qt/${PORTVERSION:R}` |`SAMBA` |`${PORTNAME}` |`SAVANNAH` |`${PORTNAME:tl}` |`SF` |`${PORTNAME:tl}/${PORTNAME:tl}/${PORTVERSION}` |=== [[makefile-master_sites-github]] === `USE_GITHUB` Если файл дистрибутива получен из определённого коммита или тега на https://github.com/[GitHub], для которого нет официально выпущенного файла, существует простой способ автоматически установить правильные значения `DISTNAME` и `MASTER_SITES`. [WARNING] ==== По состоянию на 2023-02-21 link:https://github.blog/2023-02-21-update-on-the-future-stability-of-source-code-archives-and-hashes/[GitHub] объявили, что загрузки исходного кода будут стабильными в течение года. Пожалуйста, переключитесь на ресурсы выпусков (release assets), а если они недоступны, запросите их создание у вышестоящих разработчиков. ==== Доступны следующие переменные: [[makefile-master_sites-github-description]] .`USE_GITHUB` Описание [cols="1,1,1", options="header"] |=== | Переменная | Описание | По умолчанию |`GH_ACCOUNT` |Имя учётной записи пользователя GitHub, который размещает проект |`${PORTNAME}` |`GH_PROJECT` |Название проекта на GitHub |`${PORTNAME}` |`GH_TAGNAME` |Имя тега для загрузки (2.0.1, хэш, ...) Использование имени ветки здесь некорректно. Также можно использовать хэш идентификатора коммита для создания снимка состояния. |`${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}` |`GH_SUBDIR` |Когда программному обеспечению требуется дополнительный файл дистрибутива для извлечения в `${WRKSRC}`, можно использовать эту переменную. Примеры можно найти в crossref:makefiles[makefile-master_sites-github-multiple, Загрузка нескольких файлов из GitHub] для получения дополнительной информации. |(отсутствует) |`GH_TUPLE` |`GH_TUPLE` позволяет объединить `GH_ACCOUNT`, `GH_PROJECT`, `GH_TAGNAME` и `GH_SUBDIR` в одну переменную. Формат следующий: _account_`:`_project_`:`_tagname_`:`_group_`/`_subdir_. Часть `/`_subdir_ является необязательной. Это полезно, когда требуется получить несколько проектов с GitHub. | |=== [IMPORTANT] ==== Не используйте `GH_TUPLE` для файла дистрибутива по умолчанию, так как у него нет значения по умолчанию. ==== [[makefile-master_sites-github-ex1]] .Простое использование `USE_GITHUB` [example] ==== При попытке создать порт для версии `1.2.7` pkg от пользователя FreeBSD на github, по адресу https://github.com/freebsd/pkg/[], файл [.filename]#Makefile# в итоге будет выглядеть следующим образом (незначительно сокращено для примера): [.programlisting] .... PORTNAME= pkg DISTVERSION= 1.2.7 USE_GITHUB= yes GH_ACCOUNT= freebsd .... Он автоматически получит `MASTER_SITES` установленным в `GH` и `WRKSRC` в `${WRKDIR}/pkg-1.2.7`. ==== [[makefile-master_sites-github-ex2]] .Более полное использование `USE_GITHUB` [example] ==== При попытке создать порт для самой последней версии pkg от пользователя FreeBSD на github, по адресу https://github.com/freebsd/pkg/[], файл [.filename]#Makefile# в итоге выглядит следующим образом (незначительно сокращено для примера): [.programlisting] .... PORTNAME= pkg-devel DISTVERSION= 1.3.0.a.20140411 USE_GITHUB= yes GH_ACCOUNT= freebsd GH_PROJECT= pkg GH_TAGNAME= 6dbb17b .... Он автоматически получит `MASTER_SITES` со значением `GH` и `WRKSRC` со значением `${WRKDIR}/pkg-6dbb17b`. [TIP] **** `20140411` — это дата коммита, указанного в `GH_TAGNAME`, а не дата редактирования файла [.filename]#Makefile# или дата создания коммита. **** ==== [[makefile-master_sites-github-ex3]] .Использование `USE_GITHUB` с `DISTVERSIONPREFIX` [example] ==== Время от времени `GH_TAGNAME` немного отличается от `DISTVERSION`. Например, если версия `1.0.2`, то тег будет `v1.0.2`. В таких случаях можно использовать `DISTVERSIONPREFIX` или `DISTVERSIONSUFFIX`: [.programlisting] .... PORTNAME= foo DISTVERSIONPREFIX= v DISTVERSION= 1.0.2 USE_GITHUB= yes .... Он автоматически установит `GH_TAGNAME` в `v1.0.2`, в то время как `WRKSRC` останется `${WRKDIR}/foo-1.0.2`. ==== [[makefile-master_sites-github-ex4]] .Использование `USE_GITHUB` при отсутствии версий у исходного проекта [example] ==== Если никогда не было версии вышестоящего репозитория, не изобретайте её, например `0.1` или `1.0`. Создайте порт с `DISTVERSION` в формате `g__YYYYMMDD__`, где `g` означает Git, а `_YYYYMMDD_` представляет дату коммита, указанного в `GH_TAGNAME`. [.programlisting] .... PORTNAME= bar DISTVERSION= g20140411 USE_GITHUB= yes GH_TAGNAME= c472d66b .... Это создаёт схему версионирования, которая увеличивается со временем и всё ещё находится до версии `0`. Подробности об использовании man:pkg-version[8] для сравнения версий смотрите в crossref:makefiles[makefile-versions-ex-pkg-version, этой секции]: [source, shell] .... % pkg version -t g20140411 0 < .... Что означает, что использование `PORTEPOCH` не потребуется, если вышестоящий проект решит сократить версии в будущем. ==== [[makefile-master_sites-github-ex5]] .Использование `USE_GITHUB` для доступа к коммиту между двумя версиями [example] ==== Если текущая версия программного обеспечения использует тег Git, и порт необходимо обновить до более новой промежуточной версии без тега, используйте man:git-describe[1], чтобы определить версию для использования: [source, shell] .... % git describe --tags f0038b1 v0.7.3-14-gf0038b1 .... `v0.7.3-14-gf0038b1` можно разделить на три части: `v0.7.3`:: Это последний тег Git, который появляется в истории коммитов перед запрошенным коммитом. `-14`:: Это означает, что запрошенный коммит `f0038b1` является 14-м коммитом после тега `v0.7.3`. `-gf0038b1`:: `-g` означает "Git", а `f0038b1` — это хеш коммита, на который указывает данная ссылка. [.programlisting] .... PORTNAME= bar DISTVERSIONPREFIX= v DISTVERSION= 0.7.3-14 DISTVERSIONSUFFIX= -gf0038b1 USE_GITHUB= yes .... Это создаёт схему версионирования, которая увеличивается со временем (точнее, с коммитами) и не конфликтует с созданием версии `0.7.4`. Подробности об использовании man:pkg-version[8] для сравнения версий смотрите в crossref:makefiles[makefile-versions-ex-pkg-version, этой секции] : [source, shell] .... % pkg version -t 0.7.3 0.7.3.14 < % pkg version -t 0.7.3.14 0.7.4 < .... [NOTE] **** Если запрошенный коммит совпадает с тегом, по умолчанию отображается более короткое описание. Полная версия эквивалентна: [source, shell] .... % git describe --tags c66c71d v0.7.3 % git describe --tags --long c66c71d v0.7.3-0-gc66c71d .... **** ==== [[makefile-master_sites-github-multiple]] ==== Извлечение нескольких файлов из GitHub Фреймворк `USE_GITHUB` также поддерживает загрузку нескольких файлов дистрибутива из разных мест в GitHub. Он работает очень похоже на crossref:makefiles[porting-master-sites-n, Файлы дистрибуции или патчей из нескольких мест]. В `GH_ACCOUNT`, `GH_PROJECT` и `GH_TAGNAME` добавляются несколько значений. Каждому различному значению присваивается группа. Основное значение может не иметь группы или принадлежать группе `:DEFAULT`. Значение может быть опущено, если оно совпадает со значением по умолчанию, указанным в crossref:makefiles[makefile-master_sites-github-description,описании `USE_GITHUB`]. `GH_TUPLE` также можно использовать, когда имеется множество файлов дистрибутива. Это помогает сохранять учётные данные, проект, имя тега и информацию о группе в одном месте. Для каждой группы создаётся вспомогательная переменная `${WRKSRC_group}`, содержащая каталог, в который был извлечён файл. Переменные `${WRKSRC_group}` могут использоваться для перемещения каталогов во время `post-extract`, добавления в `CONFIGURE_ARGS` или любых других действий, необходимых для корректной сборки программного обеспечения. [CAUTION] ==== Часть `:__group__` _должна_ использоваться _только для одного_ файла дистрибутива. Она служит уникальным ключом, и её повторное использование приведёт к перезаписи предыдущих значений. ==== [NOTE] ==== Поскольку это всего лишь синтаксический сахар над `DISTFILES` и `MASTER_SITES`, имена групп должны соответствовать ограничениям на имена групп, описанным в crossref:makefiles[porting-master-sites-n, Файлы дистрибутивов или патчей из нескольких источников] ==== При получении нескольких файлов из GitHub иногда файл дистрибутива по умолчанию не загружается из GitHub. Чтобы отключить загрузку файла дистрибутива по умолчанию, установите: [.programlisting] .... USE_GITHUB= nodefault .... [IMPORTANT] ==== При использовании `USE_GITHUB=nodefault` в [.filename]#Makefile# необходимо указать `DISTFILES` в его crossref:porting-order[porting-order-portname,верхнем блоке]. Определение должно быть следующим: [.programlisting] .... DISTFILES= ${DISTNAME}${EXTRACT_SUFX} .... ==== [[makefile-master_sites-github-multi]] .Использование `USE_GITHUB` с несколькими файлами дистрибутива [example] ==== Время от времени возникает необходимость загрузить более одного файла дистрибутива. Например, когда вышестоящий репозиторий git использует подмодули. Это можно легко сделать с помощью групп в переменных `GH_*`: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0.2 USE_GITHUB= yes GH_ACCOUNT= bar:icons,contrib GH_PROJECT= foo-icons:icons foo-contrib:contrib GH_TAGNAME= 1.0:icons fa579bc:contrib GH_SUBDIR= ext/icons:icons CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... Это загрузит три файла дистрибутива с github. Стандартный берется из [.filename]#foo/foo# и имеет версию `1.0.2`. Второй, с группой `icons`, берется из [.filename]#bar/foo-icons# и имеет версию `1.0`. Третий берется из [.filename]#bar/foo-contrib# и использует Git-коммит `fa579bc`. Файлы дистрибутива называются [.filename]#foo-foo-1.0.2_GH0.tar.gz#, [.filename]#bar-foo-icons-1.0_GH0.tar.gz# и [.filename]#bar-foo-contrib-fa579bc_GH0.tar.gz#. Все файлы дистрибутива извлекаются в `${WRKDIR}` в соответствующих подкаталогах. Основной файл по-прежнему извлекается в `${WRKSRC}`, в данном случае, [.filename]#${WRKDIR}/foo-1.0.2#. Каждый дополнительный файл дистрибутива извлекается в `${WRKSRC_group}`. Здесь, для группы `icons`, он называется `${WRKSRC_icons}` и содержит [.filename]#${WRKDIR}/foo-icons-1.0#. Файл с группой `contrib` называется `${WRKSRC_contrib}` и содержит `${WRKDIR}/foo-contrib-fa579bc`. Система сборки программы ожидает найти иконки в подкаталоге [.filename]#ext/icons# в её исходниках, поэтому используется `GH_SUBDIR`. `GH_SUBDIR` гарантирует, что [.filename]#ext# существует, но [.filename]#ext/icons# ещё не существует. Затем он выполняет следующее: [.programlisting] .... post-extract: @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons .... ==== [[makefile-master_sites-github-multi2]] .Использование `USE_GITHUB` с несколькими файлами дистрибутива с помощью `GH_TUPLE` [example] ==== Это функционально эквивалентно crossref:makefiles[makefile-master_sites-github-multi,Использованию `USE_GITHUB` с несколькими файлами дистрибутива], но с использованием `GH_TUPLE`: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0.2 USE_GITHUB= yes GH_TUPLE= bar:foo-icons:1.0:icons/ext/icons \ bar:foo-contrib:fa579bc:contrib CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... В предыдущем примере использовалась группировка с `bar:icons,contrib`. В `GH_TUPLE` присутствует избыточная информация, так как группировка невозможна. ==== [[makefile-master_sites-github-submodules]] .Как использовать `USE_GITHUB` с подмодулями Git? [example] ==== Порты, использующие GitHub в качестве вышестоящего репозитория, иногда применяют подмодули. Подробнее см. man:git-submodule[1]. Проблема с подмодулями заключается в том, что каждый из них является отдельным репозиторием. Таким образом, каждый из них должен быть загружен отдельно. В качестве примера используем пакет package:finance/moneymanagerex[], его репозиторий на GitHub находится по адресу https://github.com/moneymanagerex/moneymanagerex/[]. В корне репозитория есть файл https://github.com/moneymanagerex/moneymanagerex/blob/master/.gitmodules[.gitmodules]. Этот файл описывает все подмодули, используемые в данном репозитории, и перечисляет дополнительные необходимые репозитории. Этот файл покажет, какие дополнительные репозитории требуются: [.programlisting] .... [submodule "lib/wxsqlite3"] path = lib/wxsqlite3 url = https://github.com/utelle/wxsqlite3.git [submodule "3rd/mongoose"] path = 3rd/mongoose url = https://github.com/cesanta/mongoose.git [submodule "3rd/LuaGlue"] path = 3rd/LuaGlue url = https://github.com/moneymanagerex/LuaGlue.git [submodule "3rd/cgitemplate"] path = 3rd/cgitemplate url = https://github.com/moneymanagerex/html-template.git [...] .... Единственная информация, отсутствующая в этом файле, — это хэш коммита или тег, который следует использовать в качестве версии. Эта информация находится после клонирования репозитория: [source, shell] .... % git clone --recurse-submodules https://github.com/moneymanagerex/moneymanagerex.git Cloning into 'moneymanagerex'... remote: Counting objects: 32387, done. [...] Submodule '3rd/LuaGlue' (https://github.com/moneymanagerex/LuaGlue.git) registered for path '3rd/LuaGlue' Submodule '3rd/cgitemplate' (https://github.com/moneymanagerex/html-template.git) registered for path '3rd/cgitemplate' Submodule '3rd/mongoose' (https://github.com/cesanta/mongoose.git) registered for path '3rd/mongoose' Submodule 'lib/wxsqlite3' (https://github.com/utelle/wxsqlite3.git) registered for path 'lib/wxsqlite3' [...] Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/LuaGlue'... Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/cgitemplate'... Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/mongoose'... Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/lib/wxsqlite3'... [...] Submodule path '3rd/LuaGlue': checked out 'c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b' Submodule path '3rd/cgitemplate': checked out 'cd434eeeb35904ebcd3d718ba29c281a649b192c' Submodule path '3rd/mongoose': checked out '2140e5992ab9a3a9a34ce9a281abf57f00f95cda' Submodule path 'lib/wxsqlite3': checked out 'fb66eb230d8aed21dec273b38c7c054dcb7d6b51' [...] % cd moneymanagerex % git submodule status c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b 3rd/LuaGlue (heads/master) cd434eeeb35904ebcd3d718ba29c281a649b192c 3rd/cgitemplate (cd434ee) 2140e5992ab9a3a9a34ce9a281abf57f00f95cda 3rd/mongoose (6.2-138-g2140e59) fb66eb230d8aed21dec273b38c7c054dcb7d6b51 lib/wxsqlite3 (v3.4.0) [...] .... Это также можно найти на GitHub. Каждый подкаталог, который является подмодулем, отображается как `_каталог @ хэш_`, например, `mongoose @ 2140e59`. [NOTE] **** Хотя получение информации из GitHub кажется более простым, данные, полученные с помощью `git submodule status`, будут более информативными. Например, здесь хеш коммита ``lib/wxsqlite3`` `fb66eb2` соответствует `v3.4.0`. Оба варианта можно использовать взаимозаменяемо, но если доступен тег, предпочтительнее использовать его. **** Теперь, когда вся необходимая информация собрана, можно написать [.filename]#Makefile# (показаны только строки, связанные с GitHub): [.programlisting] .... PORTNAME= moneymanagerex DISTVERSIONPREFIX= v DISTVERSION= 1.3.0 USE_GITHUB= yes GH_TUPLE= utelle:wxsqlite3:v3.4.0:wxsqlite3/lib/wxsqlite3 \ moneymanagerex:LuaGlue:c51d11a:lua_glue/3rd/LuaGlue \ moneymanagerex:html-template:cd434ee:html_template/3rd/cgitemplate \ cesanta:mongoose:2140e59:mongoose/3rd/mongoose \ [...] .... ==== [[makefile-master_sites-gitlab]] === `USE_GITLAB` Подобно GitHub, если файл дистрибутива поставляется с https://gitlab.com/[gitlab.com] или использует программное обеспечение GitLab, эти переменные доступны для использования и могут потребовать установки. [[makefile-master_sites-gitlab-description]] .Описание `USE_GITLAB` [cols="1,1,1", options="header"] |=== | Переменная | Описание | По умолчанию |`GL_SITE` |Название сайта, на котором размещен проект GitLab |https://gitlab.com/ |`GL_ACCOUNT` |Имя учётной записи пользователя GitLab, размещающего проект |`${PORTNAME}` |`GL_PROJECT` |Название проекта на GitLab |`${PORTNAME}` |`GL_COMMIT` |Хэш коммита для загрузки. Должен быть полным 160-битным, 40-символьным шестнадцатеричным хэшем sha1. Это обязательная переменная для GitLab. |`(нет)` |`GL_SUBDIR` |Когда программному обеспечению требуется дополнительный файл дистрибутива для извлечения в `${WRKSRC}`, можно использовать эту переменную. Примеры можно найти в crossref:makefiles[makefile-master_sites-gitlab-multiple, Загрузка нескольких файлов из GitLab] для получения дополнительной информации. |(отсутствует) |`GL_TUPLE` |`GL_TUPLE` позволяет объединить `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT`, `GL_COMMIT` и `GL_SUBDIR` в одну переменную. Формат записи: _сайт_`:`_учётная запись_`:`_проект_`:`_коммит_`:`_группа_`/`_подкаталог_. Части _сайт_`:` и `/`_подкаталог_ являются необязательными. Это полезно, когда требуется загрузить данные из нескольких проектов GitLab. | |=== [[makefile-master_sites-gitlab-ex1]] .Простое использование `USE_GITLAB` [example] ==== Пытаясь создать порт для версии `1.14` библиотеки libsignon-glib от пользователя accounts-sso на gitlab.com, по адресу https://gitlab.com/accounts-sso/libsignon-glib/[], файл [.filename]#Makefile# будет выглядеть следующим образом для загрузки дистрибутивных файлов: [.programlisting] .... PORTNAME= libsignon-glib DISTVERSION= 1.14 USE_GITLAB= yes GL_ACCOUNT= accounts-sso GL_COMMIT= e90302e342bfd27bc8c9132ab9d0ea3d8723fd03 .... Он автоматически получит `MASTER_SITES`, установленный на https://gitlab.com/[gitlab.com], и `WRKSRC` на `${WRKDIR}/libsignon-glib-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03`. ==== [[makefile-master_sites-gitlab-ex2]] .Более полное использование `USE_GITLAB` [example] ==== Более полный пример использования вышеописанного, если порт не имеет версионирования и foobar принадлежит пользователю foo в проекте bar на самостоятельно размещенном сайте GitLab `https://gitlab.example.com/`, тогда [.filename]#Makefile# будет выглядеть следующим образом для загрузки дистрибутивных файлов: [.programlisting] .... PORTNAME= foobar DISTVERSION= g20170906 USE_GITLAB= yes GL_SITE= https://gitlab.example.com GL_ACCOUNT= foo GL_PROJECT= bar GL_COMMIT= 9c1669ce60c3f4f5eb43df874d7314483fb3f8a6 .... В нём будет установлено `MASTER_SITES` в `"https://gitlab.example.com"` и `WRKSRC` в `${WRKDIR}/bar-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6`. [TIP] ====== `20170906` — это дата коммита, указанного в `GL_COMMIT`, а не дата редактирования файла [.filename]#Makefile# или дата коммита в дерево портов FreeBSD. ====== [NOTE] ====== Протокол, порт и корневой каталог веб-сервера ``GL_SITE`` могут быть изменены в той же переменной. ====== ==== [[makefile-master_sites-gitlab-multiple]] ==== Извлечение нескольких файлов из GitLab Фреймворк `USE_GITLAB` также поддерживает загрузку нескольких файлов дистрибутивов из различных мест GitLab и сайтов, размещённых на GitLab. Он работает очень похоже на crossref:makefiles[porting-master-sites-n, Несколько файлов дистрибутивов или патчей из разных местоположений] и crossref:makefiles[makefile-master_sites-gitlab-multiple, Загрузка нескольких файлов из GitLab]. В `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT` и `GL_COMMIT` добавляются множественные значения. Каждое уникальное значение назначается группе. crossref:makefiles[makefile-master_sites-gitlab-description,Описание `USE_GITLAB`]. `GL_TUPLE` также может использоваться, когда имеется множество файлов дистрибутива. Это помогает хранить информацию о сайте, учётной записи, проекте, коммите и группе в одном месте. Для каждой группы создаётся вспомогательная переменная `${WRKSRC_group}`, содержащая каталог, в который был извлечён файл. Переменные `${WRKSRC_group}` могут использоваться для перемещения каталогов во время `post-extract`, добавления в `CONFIGURE_ARGS` или любых других действий, необходимых для корректной сборки программного обеспечения. [CAUTION] ==== Часть `:__group__` _должна_ использоваться _только для одного_ файла дистрибутива. Она служит уникальным ключом, и её повторное использование приведёт к перезаписи предыдущих значений. ==== [NOTE] ==== Поскольку это всего лишь синтаксический сахар над `DISTFILES` и `MASTER_SITES`, имена групп должны соответствовать ограничениям на имена групп, описанным в crossref:makefiles[porting-master-sites-n, Файлы дистрибутивов или патчей из нескольких источников] ==== При получении нескольких файлов с использованием GitLab иногда файл дистрибутива по умолчанию не загружается с сайта GitLab. Чтобы отключить загрузку файла дистрибутива по умолчанию, установите: [.programlisting] .... USE_GITLAB= nodefault .... [IMPORTANT] ==== При использовании `USE_GITLAB=nodefault`, [.filename]#Makefile# должен устанавливать `DISTFILES` в своём crossref:makefiles[porting-order-portname,верхнем блоке]. Определение должно быть следующим: [.programlisting] .... DISTFILES= ${DISTNAME}${EXTRACT_SUFX} .... ==== [[makefile-master_sites-gitlab-multi]] .Использование `USE_GITLAB` с несколькими файлами дистрибутива [example] ==== Время от времени возникает необходимость загрузить более одного файла дистрибутива. Например, когда вышестоящий git-репозиторий использует подмодули. Это можно легко сделать с помощью групп в переменных `GL_*`: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0.2 USE_GITLAB= yes GL_SITE= https://gitlab.example.com:9434/gitlab:icons GL_ACCOUNT= bar:icons,contrib GL_PROJECT= foo-icons:icons foo-contrib:contrib GL_COMMIT= c189207a55da45305c884fe2b50e086fcad4724b ae7368cab1ca7ca754b38d49da064df87968ffe4:icons 9e4dd76ad9b38f33fdb417a4c01935958d5acd2a:contrib GL_SUBDIR= ext/icons:icons CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... Это загрузит два файла дистрибутива с gitlab.com и один с `gitlab.example.com`, где размещается GitLab. По умолчанию файл берется из [.filename]#https://gitlab.com/foo/foo#, а коммит — `c189207a55da45305c884fe2b50e086fcad4724b`. Второй файл, из группы `icons`, берется из [.filename]#https://gitlab.example.com:9434/gitlab/bar/foo-icons#, а коммит — `ae7368cab1ca7ca754b38d49da064df87968ffe4`. Третий файл берется из [.filename]#https://gitlab.com/bar/foo-contrib#, а коммит — `9e4dd76ad9b38f33fdb417a4c01935958d5acd2a`. Файлы дистрибутива называются [.filename]#foo-foo-c189207a55da45305c884fe2b50e086fcad4724b_GL0.tar.gz#, [.filename]#bar-foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4_GL0.tar.gz# и [.filename]#bar-foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a_GL0.tar.gz#. Все файлы дистрибутива извлекаются в `${WRKDIR}` в соответствующих подкаталогах. Основной файл по-прежнему извлекается в `${WRKSRC}`, в данном случае это [.filename]#${WRKDIR}/foo-c189207a55da45305c884fe2b50e086fcad4724b-c189207a55da45305c884fe2b50e086fcad4724b#. Каждый дополнительный файл дистрибутива извлекается в `${WRKSRC_group}`. Здесь для группы `icons` он называется `${WRKSRC_icons}` и содержит [.filename]#${WRKDIR}/foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4-ae7368cab1ca7ca754b38d49da064df87968ffe4#. Файл группы `contrib` называется `${WRKSRC_contrib}` и содержит `${WRKDIR}/foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a`. Система сборки программного обеспечения ожидает найти иконки в подкаталоге [.filename]#ext/icons# в своих исходниках, поэтому используется `GL_SUBDIR`. `GL_SUBDIR` гарантирует, что [.filename]#ext# существует, но [.filename]#ext/icons# ещё не существует. Затем она выполняет следующее: [.programlisting] .... post-extract: @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons .... ==== [[makefile-master_sites-gitlab-multi2]] .Использование `USE_GITLAB` с несколькими файлами дистрибуции с помощью `GL_TUPLE` [example] ==== Это функционально эквивалентно crossref:makefiles[makefile-master_sites-gitlab-multi,Использование `USE_GITLAB` с несколькими файлами дистрибуции], но с использованием `GL_TUPLE`: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0.2 USE_GITLAB= yes GL_COMMIT= c189207a55da45305c884fe2b50e086fcad4724b GL_TUPLE= https://gitlab.example.com:9434/gitlab:bar:foo-icons:ae7368cab1ca7ca754b38d49da064df87968ffe4:icons/ext/icons \ bar:foo-contrib:9e4dd76ad9b38f33fdb417a4c01935958d5acd2a:contrib CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} .... В предыдущем примере использовалась группировка с `bar:icons,contrib`. Некоторую избыточную информацию приходится указывать с `GL_TUPLE`, так как группировка невозможна. ==== [[makefile-extract_sufx]] === `EXTRACT_SUFX` Если имеется один файл дистрибутива, и он использует нестандартное суффикс для указания механизма сжатия, установите `EXTRACT_SUFX`. Например, если файл дистрибутива был назван [.filename]#foo.tar.gzip# вместо более привычного [.filename]#foo.tar.gz#, напишите: [.programlisting] .... DISTNAME= foo EXTRACT_SUFX= .tar.gzip .... `USES=tar[:__xxx__]`, `USES=lha` или `USES=zip` автоматически устанавливают `EXTRACT_SUFX` в наиболее распространённые расширения архивов при необходимости, подробнее см. crossref:uses[uses,Использование макросов `USES`]. Если ни один из них не задан, `EXTRACT_SUFX` по умолчанию принимает значение `.tar.gz`. [NOTE] ==== Как `EXTRACT_SUFX` используется только в `DISTFILES`, следует задавать только один из них. ==== [[makefile-distfiles-definition]] === `DISTFILES` Иногда названия файлов для загрузки не имеют ничего общего с именем порта. Например, файл может называться [.filename]#source.tar.gz# или подобным образом. В других случаях исходный код приложения может быть разбит на несколько различных архивов, все из которых необходимо загрузить. Если это так, установите `DISTFILES` как список разделённых пробелами файлов, которые необходимо загрузить. [.programlisting] .... DISTFILES= source1.tar.gz source2.tar.gz .... Если явно не задано, `DISTFILES` по умолчанию равно `${DISTNAME}${EXTRACT_SUFX}`. [[makefile-extract_only]] === `EXTRACT_ONLY` Если необходимо извлечь только некоторые из `DISTFILES` — например, один из них является исходным кодом, а другой — несжатым документом — укажите имена файлов, которые нужно извлечь, в `EXTRACT_ONLY`. [.programlisting] .... DISTFILES= source.tar.gz manual.html EXTRACT_ONLY= source.tar.gz .... Если ни один из `DISTFILES` не требует распаковки, установите `EXTRACT_ONLY` в пустую строку. [.programlisting] .... EXTRACT_ONLY= .... [[porting-patchfiles]] === `PATCHFILES` Если порт требует дополнительных исправлений, доступных через FTP или HTTP, установите `PATCHFILES` в имена файлов, а `PATCH_SITES` — в URL каталога, содержащего их (формат такой же, как у `MASTER_SITES`). Если патч не относится к корню исходного дерева (то есть к `WRKSRC`), потому что содержит дополнительные пути, установите `PATCH_DIST_STRIP` соответствующим образом. Например, если все пути в патче имеют дополнительный префикс `foozolix-1.0/` перед именами файлов, задайте `PATCH_DIST_STRIP=-p1`. Не беспокойтесь, если патчи сжаты; они будут автоматически распакованы, если их имена заканчиваются на [.filename]#.Z#, [.filename]#.gz#, [.filename]#.bz2# или [.filename]#.xz#. Если патч распространяется вместе с другими файлами, такими как документация, в сжатом tarball, использование `PATCHFILES` невозможно. В таком случае добавьте имя и расположение tarball с патчами в `DISTFILES` и `MASTER_SITES`. Затем используйте `EXTRA_PATCHES`, чтобы указать на эти файлы, и [.filename]#bsd.port.mk# автоматически применит их. В частности, _не_ копируйте файлы патчей в [.filename]#${PATCHDIR}#. Этот каталог может быть недоступен для записи. [TIP] ==== Если есть несколько патчей и для них требуются разные значения параметра strip, его можно добавить рядом с именем патча в `PATCHFILES`, например: [.programlisting] .... PATCHFILES= patch1 patch2:-p1 .... Это не конфликтует с crossref:makefiles[porting-master-sites-n,функцией группировки мастер-сайтов], добавление группы также работает: [.programlisting] .... PATCHFILES= patch2:-p1:source2 .... ==== [NOTE] ==== Tarball уже будет распакован вместе с обычными исходными кодами, поэтому нет необходимости явно его распаковывать, если это обычный сжатый tarball. Будьте особенно осторожны, чтобы не перезаписать существующие файлы в этом каталоге при ручной распаковке. Также не забудьте добавить команду для удаления скопированного патча в цель `pre-clean`. ==== [[porting-master-sites-n]] === Несколько файлов дистрибутивов или исправлений из нескольких местоположений (Считайте, что это несколько «продвинутая тема»; тем, кто впервые читает этот документ, возможно, стоит сначала пропустить этот раздел). Этот раздел содержит информацию о механизме загрузки, известном как `MASTER_SITES:n` и `MASTER_SITES_NN`. Мы будем называть этот механизм `MASTER_SITES:n`. Небольшая предыстория. В OpenBSD есть удобная функция внутри `DISTFILES` и `PATCHFILES`, которая позволяет добавлять постфикс `:n` к файлам и патчам. Здесь `n` может быть любым словом, содержащим `[0-9a-zA-Z_]`, и обозначать группу. Например: [.programlisting] .... DISTFILES= alpha:0 beta:1 .... В OpenBSD файл дистрибутива [.filename]#alpha# будет связан с переменной `MASTER_SITES0`, а не с нашей общей `MASTER_SITES`, а [.filename]#beta# — с `MASTER_SITES1`. Это очень интересная функция, которая может сократить бесконечные поиски нужного сайта для загрузки. Представьте 2 файла в `DISTFILES` и 20 сайтов в `MASTER_SITES`, причём сайты медленные как черепаха, где [.filename]#beta# есть на всех сайтах из `MASTER_SITES`, а [.filename]#alpha# можно найти только на 20-м сайте. Было бы так обидно проверять их все, если бы сопровождающий знал это заранее, не так ли? Не самое лучшее начало для чудесных выходных! Теперь, когда идея понятна, представьте больше `DISTFILES` и больше `MASTER_SITES`. Безусловно, наш "мастер по исследованию distfiles" оценил бы снижение нагрузки на сеть, которое это принесло бы. В следующих разделах будет приведена информация о реализации этой идеи в FreeBSD. Мы немного улучшили концепцию OpenBSD. [IMPORTANT] ==== Имена групп не могут содержать дефисы (`-`), более того, они не могут содержать любые символы вне диапазона `[a-zA-Z0-9_]`. Это связано с тем, что, хотя man:make[1] допускает использование имён переменных с дефисами, man:sh[1] — нет. ==== [[porting-master-sites-n-simplified]] ==== Упрощенная информация В этом разделе объясняется, как быстро настроить детализированное получение нескольких файлов дистрибутивов и патчей с разных сайтов и подкаталогов. Здесь описывается случай упрощённого использования `MASTER_SITES:n`. Этого будет достаточно для большинства сценариев. Более подробная информация доступна в crossref:makefiles[ports-master-sites-n-detailed, Подробная Информация]. Некоторые приложения состоят из нескольких распространяемых файлов, которые необходимо загрузить с различных сайтов. Например, Ghostscript включает основную часть программы и множество драйверов, используемых в зависимости от принтера пользователя. Некоторые из этих драйверов поставляются вместе с основной частью, но многие другие необходимо загружать с различных сайтов. Для поддержки этого, каждая запись в `DISTFILES` может сопровождаться двоеточием и "именем группы". Затем каждый сайт, указанный в `MASTER_SITES`, сопровождается двоеточием и группой, которая указывает, какие файлы дистрибутива загружаются с данного сайта. Например, рассмотрим приложение, исходный код которого разделён на две части: [.filename]#source1.tar.gz# и [.filename]#source2.tar.gz#, которые необходимо загрузить с двух разных сайтов. В [.filename]#Makefile# порта будут присутствовать строки, подобные crossref:makefiles[ports-master-sites-n-example-simple-use-one-file-per-site,Упрощённое использование `MASTER_SITES:n` с одним файлом на сайт]. [[ports-master-sites-n-example-simple-use-one-file-per-site]] .Упрощённое использование `MASTER_SITES:n` с одним файлом на сайт [example] ==== [.programlisting] .... MASTER_SITES= ftp://ftp1.example.com/:source1 \ http://www.example.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 .... ==== Несколько файлов дистрибутивов могут принадлежать одной группе. Продолжая предыдущий пример, предположим, что существует третий файл дистрибутива [.filename]#source3.tar.gz#, который загружается с `ftp.example2.com`. Тогда [.filename]#Makefile# будет записан, как показано в crossref:makefiles[ports-master-sites-n-example-simple-use-more-than-one-file-per-site,Упрощённое использование `MASTER_SITES:n` с несколькими файлами на один сайт]. [[ports-master-sites-n-example-simple-use-more-than-one-file-per-site]] .Упрощённое использование `MASTER_SITES:n` с несколькими файлами на одном сайте [example] ==== [.programlisting] .... 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 .... ==== [[ports-master-sites-n-detailed]] ==== Подробная информация Хорошо, значит, предыдущий пример не отражал потребности нового порта? В этом разделе мы подробно объясним, как работает механизм детализированного получения `MASTER_SITES:n` и как его можно использовать. . Элементы могут иметь постфикс `:__n__`, где _n_ — это `[^:,]+`, то есть _n_ концептуально может быть любой буквенно-цифровой строкой, но пока мы ограничим её `[a-zA-Z_][0-9a-zA-Z_]+`. + Более того, сравнение строк чувствительно к регистру; то есть, `n` отличается от `N`. + Однако эти слова не могут использоваться для постфиксных целей, так как имеют специальное значение: `default`, `all` и `ALL` (они используются внутри системы, см. crossref:makefiles[porting-master-sites-n-what-changes-in-port-targets, ii]). Кроме того, `DEFAULT` является словом специального назначения (проверьте пункт crossref:makefiles[porting-master-sites-n-DEFAULT-group,3]). . Элементы с постфиксом `:n` принадлежат группе `n`, `:m` — группе `m` и так далее. + . [[porting-master-sites-n-DEFAULT-group]] Элементы без постфикса не принадлежат к группам, все они относятся к специальной группе `DEFAULT`. Элементы с постфиксом `DEFAULT` избыточны, за исключением случаев, когда элемент одновременно принадлежит и к `DEFAULT`, и к другим группам (см. пункт crossref:makefiles[porting-master-sites-n-comma-operator,5]). + Эти примеры эквивалентны, но первый предпочтительнее: + [.programlisting] .... MASTER_SITES= alpha .... + [.programlisting] .... MASTER_SITES= alpha:DEFAULT .... . Группы не являются исключительными, элемент может принадлежать нескольким разным группам одновременно, а группа может содержать несколько разных элементов или не содержать их вовсе. + . [[porting-master-sites-n-comma-operator]] Когда элемент принадлежит нескольким группам одновременно, используйте оператор запятую (`,`). + Вместо повторения несколько раз, каждый раз с разным постфиксом, мы можем перечислить несколько групп сразу в одном постфиксе. Например, `:m,n,o` обозначает элемент, принадлежащий группам `m`, `n` и `o`. + Все эти примеры эквивалентны, но последний является предпочтительным: + [.programlisting] .... MASTER_SITES= alpha alpha:SOME_SITE .... + [.programlisting] .... MASTER_SITES= alpha:DEFAULT alpha:SOME_SITE .... + [.programlisting] .... MASTER_SITES= alpha:SOME_SITE,DEFAULT .... + [.programlisting] .... MASTER_SITES= alpha:DEFAULT,SOME_SITE .... . Все сайты в заданной группе сортируются согласно `MASTER_SORT_AWK`. Все группы в `MASTER_SITES` и `PATCH_SITES` также сортируются. + . [[porting-master-sites-n-group-semantics]] Семантика групп может использоваться в любых переменных `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR`, `PATCH_SITE_SUBDIR`, `DISTFILES` и `PATCHFILES` согласно следующему синтаксису: .. Все элементы `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR` и `PATCH_SITE_SUBDIR` должны заканчиваться символом дробной черты `/`. Если элементы принадлежат к какой-либо группе, постфикс группы `:__n__` должен следовать сразу после завершающего символа `/`. Механизм `MASTER_SITES:n` полагается на наличие завершающего символа `/`, чтобы избежать путаницы между элементами, где `:n` является допустимой частью элемента, и случаями, где `:n` обозначает группу `n`. В целях совместимости, поскольку ранее завершающий символ `/` не требовался в элементах `MASTER_SITE_SUBDIR` и `PATCH_SITE_SUBDIR`, если символ, непосредственно предшествующий постфиксу, не является `/`, то `:n` будет считаться допустимой частью элемента, а не постфиксом группы, даже если элемент оканчивается на `:n`. См. оба раздела crossref:makefiles[ports-master-sites-n-example-detailed-use-master-site-subdir,Подробное использование `MASTER_SITES:n` в `MASTER_SITE_SUBDIR`] и crossref:makefiles[ports-master-sites-n-example-detailed-use-complete-example-master-sites,Подробное использование `MASTER_SITES:n` с оператором запятая, несколькими файлами, несколькими сайтами и несколькими подкаталогами]. + [[ports-master-sites-n-example-detailed-use-master-site-subdir]] .Подробное использование `MASTER_SITES:n` в `MASTER_SITE_SUBDIR` [example] ==== [.programlisting] .... MASTER_SITE_SUBDIR= old:n new/:NEW .... *** Каталоги в группе `DEFAULT` -> old:n *** Каталоги в группе `NEW` -> new ==== + [[ports-master-sites-n-example-detailed-use-complete-example-master-sites]] .Подробное использование `MASTER_SITES:n` с оператором запятая, несколькими файлами, сайтами и подкаталогами [example] ==== [.programlisting] .... 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 .... Предыдущий пример приводит к такой детализированной загрузке файлов. Сайты перечислены в точном порядке их использования. *** [.filename]#file1# будет загружен из **** `MASTER_SITE_OVERRIDE` **** http://site1/directory-trial:1/ **** http://site1/directory-one/ **** http://site1/directory/ **** http://site2/ **** http://site7/ **** `MASTER_SITE_BACKUP` *** [.filename]#file2# будет загружен точно так же, как [.filename]#file1#, поскольку они оба принадлежат к одной и той же группе **** `MASTER_SITE_OVERRIDE` **** http://site1/directory-trial:1/ **** http://site1/directory-one/ **** http://site1/directory/ **** http://site2/ **** http://site7/ **** `MASTER_SITE_BACKUP` *** [.filename]#file3# будет загружен из **** `MASTER_SITE_OVERRIDE` **** http://site3/ **** `MASTER_SITE_BACKUP` *** [.filename]#file4# будет загружен из **** `MASTER_SITE_OVERRIDE` **** http://site4/ **** http://site5/ **** http://site6/ **** http://site7/ **** http://site8/directory-one/ **** `MASTER_SITE_BACKUP` *** [.filename]#file5# будет загружен из **** `MASTER_SITE_OVERRIDE` **** `MASTER_SITE_BACKUP` *** [.filename]#file6# будет получен из **** `MASTER_SITE_OVERRIDE` **** http://site8/ **** `MASTER_SITE_BACKUP` ==== . Как сгруппировать один из специальных макросов из [.filename]#bsd.sites.mk#, например, SourceForge (`SF`)? + Это максимально упрощено. См. crossref:makefiles[ports-master-sites-n-example-detailed-use-master-site-sourceforge,Подробное использование `MASTER_SITES:n` с SourceForge (`SF`)]. + [[ports-master-sites-n-example-detailed-use-master-site-sourceforge]] .Подробное использование `MASTER_SITES:n` с SourceForge (`SF`) [example] ==== [.programlisting] .... MASTER_SITES= http://site1/ SF/something/1.0:sourceforge,TEST DISTFILES= something.tar.gz:sourceforge .... [.filename]#something.tar.gz# будет загружен со всех сайтов в пределах SourceForge. ==== . Как использовать это с `PATCH*`? + Все примеры были выполнены с `MASTER*`, но они работают точно так же для `PATCH*`, как можно увидеть в crossref:makefiles[ports-master-sites-n-example-detailed-use-patch-sites,Упрощённое использование `MASTER_SITES:n` с `PATCH_SITES`]. + [[ports-master-sites-n-example-detailed-use-patch-sites]] .Упрощённое использование `MASTER_SITES:n` с `PATCH_SITES` [example] ==== [.programlisting] .... PATCH_SITES= http://site1/ http://site2/:test PATCHFILES= patch1:test .... ==== [[port-master-sites-n-what-changed]] ==== Что меняется для портов? Что остаётся неизменным? [lowerroman] . Все текущие порты остаются без изменений. Функция `MASTER_SITES:n` активируется только при наличии элементов с постфиксом `:__n__`, соответствующих указанным выше синтаксическим правилам, в частности, как показано в пункте crossref:makefiles[porting-master-sites-n-group-semantics, 7]. + . [[porting-master-sites-n-what-changes-in-port-targets]] Порты сохраняют те же цели: `checksum`, `makesum`, `patch`, `configure`, `build` и т.д., за исключением очевидных случаев: `do-fetch`, `fetch-list`, `master-sites` и `patch-sites`. ** `do-fetch`: развертывает новую группировку с постфиксом `DISTFILES` и `PATCHFILES` с соответствующими групповыми элементами в `MASTER_SITES` и `PATCH_SITES`, которые используют соответствующие групповые элементы в `MASTER_SITE_SUBDIR` и `PATCH_SITE_SUBDIR`. Проверьте crossref:makefiles[ports-master-sites-n-example-detailed-use-complete-example-master-sites,Подробное использование `MASTER_SITES:n` с оператором запятой, множественными файлами, множественными сайтами и множественными подкаталогами]. ** `fetch-list`: работает как старый `fetch-list`, за исключением того, что группировка происходит так же, как в `do-fetch`. ** `master-sites` и `patch-sites`: (несовместимо с более старыми версиями) возвращают только элементы группы `DEFAULT`; фактически они выполняют цели `master-sites-default` и `patch-sites-default` соответственно. + Кроме того, предпочтительнее использовать цель `master-sites-all` или `patch-sites-all`, чем напрямую проверять `MASTER_SITES` или `PATCH_SITES`. Кроме того, прямая проверка не гарантирует работу в будущих версиях. Для получения дополнительной информации об этих новых целях портов см. пункт crossref:makefiles[porting-master-sites-n-new-port-targets-master-sites-all, B]. . Новые цели портов .. Существуют цели `master-sites-_n_` и `patch-sites-_n_`, которые будут выводить элементы соответствующей группы _n_ в `MASTER_SITES` и `PATCH_SITES` соответственно. Например, и `master-sites-DEFAULT`, и `patch-sites-DEFAULT` вернут элементы группы `DEFAULT`, `master-sites-test` и `patch-sites-test` — группы `test`, и так далее. + .. [[porting-master-sites-n-new-port-targets-master-sites-all]] Существуют новые цели `master-sites-all` и `patch-sites-all`, которые выполняют работу старых `master-sites` и `patch-sites`. Они возвращают элементы всех групп, как если бы они все принадлежали одной группе, с оговоркой, что перечисляется столько же `MASTER_SITE_BACKUP` и `MASTER_SITE_OVERRIDE`, сколько определено групп в `DISTFILES` или `PATCHFILES`; соответственно для `master-sites-all` и `patch-sites-all`. [[makefile-dist_subdir]] === `DIST_SUBDIR` Не допускайте захламления портом каталога [.filename]#/usr/ports/distfiles#. Если порт требует загрузки большого количества файлов или содержит файл с именем, которое может конфликтовать с другими портами (например, [.filename]#Makefile#), установите `DIST_SUBDIR` в имя порта (подойдут `${PORTNAME}` или `${PKGNAMEPREFIX}${PORTNAME}`). Это изменит `DISTDIR` со значения по умолчанию [.filename]#/usr/ports/distfiles# на [.filename]#/usr/ports/distfiles/${DIST_SUBDIR}#, фактически помещая все необходимые для порта файлы в этот подкаталог. Также будет проверяться подкаталог с тем же именем на основном резервном сайте по адресу http://distcache.FreeBSD.org[http://distcache.FreeBSD.org] (Явное указание `DISTDIR` в [.filename]#Makefile# не решит эту задачу, поэтому используйте `DIST_SUBDIR`.) [NOTE] ==== Это не влияет на сайты в `MASTER_SITES`, определённые в [.filename]#Makefile#. ==== [[makefile-maintainer]] == `MAINTAINER` Установите здесь свой адрес электронной почты. Пожалуйста. _:-)_ Только один адрес без комментария допускается в качестве значения `MAINTAINER`. Используемый формат: `user@hostname.domain`. Пожалуйста, не включайте в эту запись описательный текст, например, настоящее имя. Это только вносит путаницу в инфраструктуру Ports и большинство инструментов, которые её используют. Ответственный за поддержку порта обязан поддерживать порт в актуальном состоянии и обеспечивать его корректную работу. Подробное описание обязанностей ответственного за поддержку порта приведено в разделе extref:{contributing}[Задача для сопровождающих портов,maintain-port]. [NOTE] ==== Сопровождающий добровольно поддерживает порт в рабочем состоянии. Сопровождающие несут основную ответственность за свои порты, но не имеют исключительных прав на них. Порты существуют для пользы сообщества и, по сути, принадлежат сообществу. Это означает, что люди, не являющиеся сопровождающими, также могут вносить изменения в порт. Крупные изменения в коллекции портов могут потребовать правок во многих портах. Команда управления портами FreeBSD или члены других команд могут изменять порты для исправления проблем с зависимостями или других проблем, таких как обновление версии динамической библиотеки. Некоторые типы исправлений имеют "автоматическое согласование" от {portmgr}, что позволяет любому коммиттеру исправлять эти категории проблем в любом порте. Такие исправления не требуют одобрения от сопровождающего. Автоматическое согласование для большинства портов применяется к исправлениям, таким как изменения инфраструктуры, или тривиальным и _проверенным_ исправлениям сборки и выполнения. Текущий список доступен в extref:{committers-guide}[разделе Портов Руководства коммиттера, ports-qa-misc-blanket-approval]. ==== Другие изменения в порте будут отправлены сопровождающему на проверку и утверждение перед внесением. Если сопровождающий не отвечает на запрос об обновлении в течение двух недель (за исключением основных государственных праздников), это считается превышением времени ожидания сопровождающего, и обновление может быть внесено без его явного одобрения. Если сопровождающий не отвечает в течение трёх месяцев или если произошло три последовательных превышения времени ожидания, то сопровождающий считается отсутствующим без уведомления, и все его порты могут быть возвращены в общий пул. Исключениями являются порты, сопровождаемые {portmgr} или {security-officer}. Никакие несанкционированные изменения не могут быть внесены в порты, сопровождаемые этими группами. Мы оставляем за собой право изменять представленные сопровождающим материалы, чтобы лучше соответствовать существующим политикам и стилю Коллекции портов, без явного одобрения отправителя или сопровождающего. Кроме того, масштабные инфраструктурные изменения могут привести к модификации порта без согласия сопровождающего. Подобные изменения никогда не повлияют на функциональность порта. {portmgr} оставляет за собой право отозвать или изменить права сопровождающего по любой причине, а {security-officer} оставляет за собой право отозвать или изменить права сопровождающего по соображениям безопасности. [[makefile-comment]] == `COMMENT` Комментарий — это однострочное описание порта, отображаемое командой `pkg info`. При составлении придерживайтесь следующих правил: . Строка COMMENT должна быть не длиннее 70 символов. . Не включайте название пакета или номер версии программного обеспечения. . Комментарий должен начинаться с заглавной буквы и заканчиваться без точки. . Не начинайте с неопределённого артикля (то есть A или An). . Пишите названия с заглавной буквы, например: Apache, JavaScript или Perl. . Используйте запятую для списков слов: "green, red, and blue." . Проверяйте на наличие орфографических ошибок. Вот пример: [.programlisting] .... COMMENT= Cat chasing a mouse all over the screen .... Переменная COMMENT следует сразу за переменной MAINTAINER в файле [.filename]#Makefile#. [[makefile-www]] == Веб-сайт проекта Каждый порт должен указывать на веб-сайт, предоставляющий дополнительную информацию о программном обеспечении. Везде, где это возможно, следует использовать официальный сайт проекта, поддерживаемый разработчиками программного обеспечения. [.programlisting] .... WWW= https://ffmpeg.org/ .... Но это также может быть каталог или ресурс в репозитории исходного кода: [.programlisting] .... WWW= https://sourceforge.net/projects/mpd/ .... Переменная WWW следует сразу за переменной COMMENT в файле [.filename]#Makefile#. Если один и тот же контент доступен по HTTP и HTTPS, следует использовать URL, начинающийся с `https://`. Если URI является корнем веб-сайта или каталогом, он должен заканчиваться косой чертой. Эта информация ранее размещалась в последней строке файла [.filename]#pkg-descr#. Она была перенесена в Makefile для удобства обслуживания и обработки. Наличие строки `WWW:` в конце файла [.filename]#pkg-descr# считается устаревшим. [[licenses]] == Лицензии Каждый порт должен содержать документацию о лицензии, под которой он распространяется. Если лицензия не одобрена OSI, необходимо также указать любые ограничения на распространение. [[licenses-license]] === `LICENSE` Краткое название лицензии или лицензий, если применяется более одной лицензии. Если это одна из лицензий, перечисленных в crossref:makefiles[licenses-license-list,Предопределённый список лицензий], можно задать только переменные `LICENSE_FILE` и `LICENSE_DISTFILES`. Если это лицензия, которая не определена в рамках портов (см. crossref:makefiles[licenses-license-list,Список предопределённых лицензий]), необходимо задать `LICENSE_PERMS` и `LICENSE_NAME`, а также `LICENSE_FILE` или `LICENSE_TEXT`. Также можно задать `LICENSE_DISTFILES` и `LICENSE_GROUPS`, но это не обязательно. Предопределённые лицензии показаны в crossref:makefiles[licenses-license-list,Список предопределённых лицензий]. Текущий список всегда доступен в [.filename]#Mk/bsd.licenses.db.mk#. [[licenses-license-ex1]] .Простейшее использование, предопределённые лицензии [example] ==== Когда в файле [.filename]#README# какого-либо программного обеспечения указано: «Данное программное обеспечение распространяется на условиях GNU Lesser General Public License, опубликованной Free Software Foundation; либо версии 2.1 Лицензии, либо (по вашему выбору) любой более поздней версии», но сам файл лицензии не предоставлен, используйте следующее: [.programlisting] .... LICENSE= LGPL21+ .... Когда программное обеспечение предоставляет файл лицензии, используйте это: [.programlisting] .... LICENSE= LGPL21+ LICENSE_FILE= ${WRKSRC}/COPYING .... ==== Для предопределённых лицензий права по умолчанию: `dist-mirror dist-sell pkg-mirror pkg-sell auto-accept`. [[licenses-license-list]] .Предопределённый список лицензий [cols="1,1,1,1", frame="none", options="header"] |=== | Короткое имя | Имя | Группа | Разрешения |`AGPLv3` |Универсальная общественная лицензия GNU Affero версии 3 |`FSF GPL OSI` |(по умолчанию) |`AGPLv3+` |Универсальная общественная лицензия GNU Affero версии 3 (или позднее) |`FSF GPL OSI` |(по умолчанию) |`APACHE10` |Apache License 1.0 |`FSF` |(по умолчанию) |`APACHE11` |Apache License 1.1 |`FSF OSI` |(по умолчанию) |`APACHE20` |Apache License 2.0 |`FSF OSI` |(по умолчанию) |`ART10` |Художественная лицензия версия 1.0 |`OSI` |(по умолчанию) |`ART20` |Художественная лицензия версии 2.0 |`FSF GPL OSI` |(по умолчанию) |`ARTPERL10` |Художественная лицензия (perl) версия 1.0 |`OSI` |(по умолчанию) |`BSD` |Лицензия BSD, общая версия (устарела) |`FSF OSI COPYFREE` |(по умолчанию) |`BSD2CLAUSE` |BSD 2-пунктная лицензия "Упрощенная" |`FSF OSI COPYFREE` |(по умолчанию) |`BSD3CLAUSE` |BSD 3-пунктная лицензия "Новая" или "Пересмотренная" |`FSF OSI COPYFREE` |(по умолчанию) |`BSD4CLAUSE` |BSD 4-пунктная лицензия "Оригинальная" или "Старая" |`FSF` |(по умолчанию) |`BSL` |Лицензия программного обеспечения Boost |`FSF OSI COPYFREE` |(по умолчанию) |`CC-BY-1.0` |Creative Commons с указанием авторства 1.0 | |(по умолчанию) |`CC-BY-2.0` |Creative Commons с указанием авторства 2.0 | |(по умолчанию) |`CC-BY-2.5` |Creative Commons с указанием авторства 2.5 | |(по умолчанию) |`CC-BY-3.0` |Creative Commons с указанием авторства 3.0 | |(по умолчанию) |`CC-BY-4.0` |Creative Commons с указанием авторства 4.0 | |(по умолчанию) |`CC-BY-NC-1.0` |Creative Commons с указанием авторства – некоммерческая 1.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-2.0` |Creative Commons с указанием авторства – некоммерческая 2.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-2.5` |Creative Commons с указанием авторства – некоммерческая 2.5 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-3.0` |Creative Commons с указанием авторства – некоммерческая 3.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-4.0` |Creative Commons с указанием авторства – некоммерческая 4.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-ND-1.0` |Creative Commons с указанием авторства – некоммерческая – без производных 1.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-ND-2.0` |Creative Commons с указанием авторства – некоммерческая – без производных 2.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-ND-2.5` |Creative Commons с указанием авторства – некоммерческая – без производных 2.5 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-ND-3.0` |Creative Commons с указанием авторства – некоммерческая – без производных 3.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-ND-4.0` |Creative Commons с указанием авторства – некоммерческая – без производных 4.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-SA-1.0` |Creative Commons с указанием авторства – некоммерческая – на тех же условиях 1.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-SA-2.0` |Creative Commons с указанием авторства – некоммерческая – на тех же условиях 2.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-SA-2.5` |Creative Commons с указанием авторства – некоммерческая – на тех же условиях 2.5 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-SA-3.0` |Creative Commons с указанием авторства – некоммерческая – на тех же условиях 3.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-NC-SA-4.0` |Creative Commons с указанием авторства – некоммерческая – на тех же условиях 4.0 | |`dist-mirror``pkg-mirror``auto-accept` |`CC-BY-ND-1.0` |Creative Commons с указанием авторства – без производных 1.0 | |(по умолчанию) |`CC-BY-ND-2.0` |Creative Commons с указанием авторства – без производных 2.0 | |(по умолчанию) |`CC-BY-ND-2.5` |Creative Commons с указанием авторства – без производных 2.5 | |(по умолчанию) |`CC-BY-ND-3.0` |Creative Commons с указанием авторства – без производных 3.0 | |(по умолчанию) |`CC-BY-ND-4.0` |Creative Commons с указанием авторства – без производных 4.0 | |(по умолчанию) |`CC-BY-SA-1.0` |Creative Commons с указанием авторства – на тех же условиях 1.0 | |(по умолчанию) |`CC-BY-SA-2.0` |Creative Commons с указанием авторства – на тех же условиях 2.0 | |(по умолчанию) |`CC-BY-SA-2.5` |Creative Commons с указанием авторства – на тех же условиях 2.5 | |(по умолчанию) |`CC-BY-SA-3.0` |Creative Commons с указанием авторства – на тех же условиях 3.0 | |(по умолчанию) |`CC-BY-SA-4.0` |Creative Commons с указанием авторства – на тех же условиях 4.0 | |(по умолчанию) |`CC0-1.0` |Creative Commons Zero v1.0 Universal (Отказ от прав 1.0 Универсальная) |`FSF GPL COPYFREE` |(по умолчанию) |`CDDL` |Лицензия на совместную разработку и распространение |`FSF OSI` |(по умолчанию) |`CPAL-1.0` |Публичная лицензия общего распространения с указанием авторства |`FSF OSI` |(по умолчанию) |`ClArtistic` |Уточнённая художественная лицензия |`FSF GPL OSI` |(по умолчанию) |`EPL` |Публичная лицензия Eclipse |`FSF OSI` |(по умолчанию) |`GFDL` |GNU Свободная лицензия на документацию |`FSF` |(по умолчанию) |`GMGPL` |Модифицированная Общедоступная лицензия GNAT |`FSF GPL OSI` |(по умолчанию) |`GPLv1` |Универсальная общественная лицензия GNU версии 1 |`FSF GPL OSI` |(по умолчанию) |`GPLv1+` |Универсальная общественная лицензия GNU версии 1 (или более поздняя) |`FSF GPL OSI` |(по умолчанию) |`GPLv2` |Универсальная общественная лицензия GNU версии 2 |`FSF GPL OSI` |(по умолчанию) |`GPLv2+` |Универсальная общественная лицензия GNU версии 2 (или более поздняя) |`FSF GPL OSI` |(по умолчанию) |`GPLv3` |Универсальная общественная лицензия GNU версии 3 |`FSF GPL OSI` |(по умолчанию) |`GPLv3+` |Универсальная общественная лицензия GNU версии 3 (или более поздняя) |`FSF GPL OSI` |(по умолчанию) |`GPLv3RLE` |Исключение для библиотеки времени выполнения GNU GPL версии 3 |`FSF GPL OSI` |(по умолчанию) |`GPLv3RLE+` |Исключение для библиотеки времени выполнения GNU GPL версии 3 (или более поздняя) |`FSF GPL OSI` |(по умолчанию) |`ISCL` |Лицензия Internet Systems Consortium |`FSF GPL OSI COPYFREE` |(по умолчанию) |`LGPL20` |Общедоступная лицензия GNU для библиотек, версия 2.0 |`FSF GPL OSI` |(по умолчанию) |`LGPL20+` |Общедоступная лицензия GNU для библиотек, версия 2.0 (или более поздняя) |`FSF GPL OSI` |(по умолчанию) |`LGPL21` |Универсальная общественная лицензия GNU ограниченного применения, версия 2.1 |`FSF GPL OSI` |(по умолчанию) |`LGPL21+` |Универсальная общественная лицензия GNU ограниченного применения, версия 2.1 (или более поздняя) |`FSF GPL OSI` |(по умолчанию) |`LGPL3` |Универсальная общественная лицензия GNU ограниченного применения, версия 3 |`FSF GPL OSI` |(по умолчанию) |`LGPL3+` |Универсальная общественная лицензия GNU ограниченного применения, версия 3 (или более поздней) |`FSF GPL OSI` |(по умолчанию) |`LPPL10` |Публичная лицензия проекта LaTeX, версия 1.0 |`FSF OSI` |`dist-mirror dist-sell` |`LPPL11` |Публичная лицензия проекта LaTeX, версия 1.1 |`FSF OSI` |`dist-mirror dist-sell` |`LPPL12` |Публичная лицензия проекта LaTeX, версия 1.2 |`FSF OSI` |`dist-mirror dist-sell` |`LPPL13` |Публичная лицензия проекта LaTeX, версия 1.3 |`FSF OSI` |`dist-mirror dist-sell` |`LPPL13a` |Публичная лицензия проекта LaTeX, версия 1.3a |`FSF OSI` |`dist-mirror dist-sell` |`LPPL13b` |Публичная лицензия проекта LaTeX, версия 1.3b |`FSF OSI` |`dist-mirror dist-sell` |`LPPL13c` |Публичная лицензия проекта LaTeX, версия 1.3c |`FSF OSI` |`dist-mirror dist-sell` |`MIT` |Лицензия MIT / Лицензия X11 |`COPYFREE FSF GPL OSI` |(по умолчанию) |`MPL10` |Публичная лицензия Mozilla, версия 1.0 |`FSF OSI` |(по умолчанию) |`MPL11` |Публичная лицензия Mozilla, версия 1.1 |`FSF OSI` |(по умолчанию) |`MPL20` |Публичная лицензия Mozilla, версия 2.0 |`FSF OSI` |(по умолчанию) |`NCSA` |Открытая лицензия Университета Иллинойса/NCSA |`COPYFREE FSF GPL OSI` |(по умолчанию) |`NONE` |Лицензия не указана | |`none` |`OFL10` |Лицензия SIL Open Font версия 1.0 (https://scripts.sil.org/OFL/) |`FONTS` |(по умолчанию) |`OFL11` |Лицензия SIL Open Font версия 1.1 (https://scripts.sil.org/OFL/) |`FONTS` |(по умолчанию) |`OWL` |Лицензия Открытых Произведений (owl.apotheon.org) |`COPYFREE` |(по умолчанию) |`OpenSSL` |Лицензия OpenSSL |`FSF` |(по умолчанию) |`PD` |Общественное достояние |`GPL COPYFREE` |(по умолчанию) |`PHP202` |Лицензия PHP версии 2.02 |`FSF OSI` |(по умолчанию) |`PHP30` |Лицензия PHP версии 3.0 |`FSF OSI` |(по умолчанию) |`PHP301` |Лицензия PHP версии 3.01 |`FSF OSI` |(по умолчанию) |`PSFL` |Лицензия Python Software Foundation |`FSF GPL OSI` |(по умолчанию) |`PostgreSQL` |Лицензия PostgreSQL |`FSF GPL OSI COPYFREE` |(по умолчанию) |`RUBY` |Лицензия Ruby |`FSF` |(по умолчанию) |`UNLICENSE` |Отказ от лицензии (The Unlicense) |`COPYFREE FSF GPL` |(по умолчанию) |`WTFPL` |Публичная лицензия "Делай что хочешь" версия 2 |`GPL FSF COPYFREE` |(по умолчанию) |`WTFPL1` |Публичная лицензия "Делай что хочешь" версия 1 |`GPL FSF COPYFREE` |(по умолчанию) |`ZLIB` |Лицензия zlib |`GPL FSF OSI` |(по умолчанию) |`ZPL21` |Публичная лицензия Zope версия 2.1 |`GPL OSI` |(по умолчанию) |=== [[licenses-license_perms]] === `LICENSE_PERMS` и `LICENSE_PERMS_NAME_` Разрешения. Используйте `none`, если пусто. .Список разрешений лицензии [[licenses-license_perms-dist-mirror]] `dist-mirror`:: Разрешается распространение дистрибутивных файлов. Дистрибутивные файлы будут добавлены в CDN `MASTER_SITE_BACKUP` FreeBSD. [[licenses-license_perms-no-dist-mirror]] `no-dist-mirror`:: Распространение дистрибутивных файлов запрещено. Это эквивалентно установке crossref:special[porting-restrictions-restricted,`RESTRICTED`]. Дистрибутивные файлы _не_ будут добавлены в CDN `MASTER_SITE_BACKUP` FreeBSD. [[licenses-license_perms-dist-sell]] `dist-sell`:: Продажа файлов дистрибутива разрешена. Файлы дистрибутива будут присутствовать на образах установщика. [[licenses-license_perms-no-dist-sell]] `no-dist-sell`:: Продажа файлов дистрибутива запрещена. Это эквивалентно установке crossref:special[porting-restrictions-no_cdrom,`NO_CDROM`]. [[licenses-license_perms-pkg-mirror]] `pkg-mirror`:: Свободное распространение пакета разрешено. Пакет будет распространяться через CDN пакетов FreeBSD https://pkg.freebsd.org/[https://pkg.freebsd.org/]. [[licenses-license_perms-no-pkg-mirror]] `no-pkg-mirror`:: Свободное распространение пакета запрещено. Эквивалентно установке crossref:special[porting-restrictions-no_package,`NO_PACKAGE`]. Пакет _не_ будет распространяться через FreeBSD CDN для пакетов https://pkg.freebsd.org/[https://pkg.freebsd.org/]. [[licenses-license_perms-pkg-sell]] `pkg-sell`:: Продажа пакета разрешена. Пакет будет присутствовать на образах установщика. [[licenses-license_perms-no-pkg-sell]] `no-pkg-sell`:: Продажа пакета запрещена. Это эквивалентно установке crossref:special[porting-restrictions-no_cdrom,`NO_CDROM`]. Пакет _не_ будет присутствовать на образах установщика. [[licenses-license_perms-auto-accept]] `auto-accept`:: Лицензия принимается по умолчанию. Запросы на принятие лицензии не отображаются, если пользователь не определил `LICENSES_ASK`. Используйте это, если в лицензии не указано, что пользователь должен принять условия лицензии. [[licenses-license_perms-no-auto-accept]] `no-auto-accept`:: Лицензия не принимается по умолчанию. Пользователь всегда будет запрошен на подтверждение принятия данной лицензии. Это должно использоваться, если лицензия требует, чтобы пользователь принял её условия. Когда присутствуют и `_permission_`, и `no-_permission_`, то `no-_permission_` отменяет `_permission_`. Когда `_permission_` отсутствует, это считается как `no-_permission_`. [WARNING] ==== Некоторые отсутствующие разрешения могут сделать порт (и все зависящие от него порты) непригодными для использования пользователями пакетов: Порт без разрешения `auto-accept` никогда не будет собран, и все зависящие от него порты будут проигнорированы. Порт без разрешения `pkg-mirror`, а также любые порты, зависящие от него, будут удалены после сборки, что гарантирует их отсутствие в дистрибуции. ==== [[licenses-license_perms-ex1]] .Нестандартная лицензия [example] ==== Прочитайте условия лицензии и переведите их, используя доступные разрешения. [.programlisting] .... LICENSE= UNKNOWN LICENSE_NAME= unknown LICENSE_TEXT= This program is NOT in public domain.\ It can be freely distributed for non-commercial purposes only. LICENSE_PERMS= dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept .... ==== [[licenses-license_perms-ex2]] .Стандартные и нестандартные лицензии [example] ==== Прочитайте условия лицензии и укажите их, используя доступные разрешения. В случае сомнений обратитесь за разъяснениями на {freebsd-ports}. [.programlisting] .... LICENSE= WARSOW GPLv2 LICENSE_COMB= multi LICENSE_NAME_WARSOW= Warsow Content License LICENSE_FILE_WARSOW= ${WRKSRC}/docs/license.txt LICENSE_PERMS_WARSOW= dist-mirror pkg-mirror auto-accept .... Когда разрешения лицензий GPLv2 и UNKNOWN смешиваются, порт получает `dist-mirror dist-sell pkg-mirror pkg-sell auto-accept dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept`. Опции `no-_разрешения_` отменяют соответствующие _разрешения_. Итоговый список разрешений: _dist-mirror pkg-mirror auto-accept_. Файлы дистрибутива и пакеты не будут доступны в образах установщика. ==== [[licenses-license_groups]] === `LICENSE_GROUPS` и `LICENSE_GROUPS_NAME` Группы, к которым принадлежит лицензия. .Список предопределённых групп лицензий [[licenses-license_groups-FSF]] `FSF`:: Одобрено Free Software Foundation, см. https://www.fsf.org/licensing/[Команда по лицензированию и соответствию FSF]. [[licenses-license_groups-GPL]] `GPL`:: Совместимые с GPL [[licenses-license_groups-OSI]] `OSI`:: Одобрено OSI, см. страницу https://opensource.org/licenses/[Открытых лицензий]. [[licenses-license_groups-COPYFREE]] `COPYFREE`:: Соответствует определению стандарта Copyfree, см. страницу https://copyfree.org/standard/licenses/[лицензий Copyfree]. [[licenses-license_groups-FONTS]] `FONTS`:: Лицензии на шрифты [[licenses-license_name]] === `LICENSE_NAME` и `LICENSE_NAME_NAME` Полное название лицензии. [[licenses-license_name-ex1]] .`LICENSE_NAME` [example] ==== [.programlisting] .... LICENSE= UNRAR LICENSE_NAME= UnRAR License LICENSE_FILE= ${WRKSRC}/license.txt LICENSE_PERMS= dist-mirror dist-sell pkg-mirror pkg-sell auto-accept .... ==== [[licenses-license_file]] === `LICENSE_FILE` и `LICENSE_FILE_NAME` Полный путь к файлу, содержащему текст лицензии, обычно [.filename]#${WRKSRC}/some/file#. Если файл отсутствует в дистрибутиве, а его содержимое слишком длинное для размещения в crossref:makefiles[licenses-license_text,`LICENSE_TEXT`], поместите его в новый файл в [.filename]#${FILESDIR}#. [[licenses-license_file-ex1]] .`LICENSE_FILE` [example] ==== [.programlisting] .... LICENSE= GPLv3+ LICENSE_FILE= ${WRKSRC}/COPYING .... ==== [[licenses-license_text]] === `LICENSE_TEXT` и `LICENSE_TEXT_NAME` Текст для использования в качестве лицензии. Полезно, когда лицензия отсутствует в файлах дистрибутива и её текст краток. [[licenses-license_text-ex1]] .`LICENSE_TEXT` [example] ==== [.programlisting] .... LICENSE= UNKNOWN LICENSE_NAME= unknown LICENSE_TEXT= This program is NOT in public domain.\ It can be freely distributed for non-commercial purposes only,\ and THERE IS NO WARRANTY FOR THIS PROGRAM. LICENSE_PERMS= dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept .... ==== [[licenses-license_distfiles]] === `LICENSE_DISTFILES` и `LICENSE_DISTFILES_NAME` Файлы дистрибутива, к которым применяются лицензии. По умолчанию — все файлы дистрибутива. [[licenses-license_distfiles-ex1]] .`LICENSE_DISTFILES` [example] ==== Используется, когда файлы дистрибутива имеют разные лицензии. Например, один файл имеет лицензию на код, а другой содержит некоторые произведения искусства, которые нельзя распространять: [.programlisting] .... MASTER_SITES= SF/some-game DISTFILES= ${DISTNAME}${EXTRACT_SUFX} artwork.zip LICENSE= BSD3CLAUSE ARTWORK LICENSE_COMB= dual LICENSE_NAME_ARTWORK= The game artwork license LICENSE_TEXT_ARTWORK= The README says that the files cannot be redistributed LICENSE_PERMS_ARTWORK= pkg-mirror pkg-sell auto-accept LICENSE_DISTFILES_BSD3CLAUSE= ${DISTNAME}${EXTRACT_SUFX} LICENSE_DISTFILES_ARTWORK= artwork.zip .... ==== [[licenses-license_comb]] === `LICENSE_COMB` Установите значение `multi`, если применяются все лицензии. Установите значение `dual`, если применяется любая из лицензий. По умолчанию используется значение `single`. [[licenses-license_comb-ex1]] .Двойные лицензии [example] ==== Когда порт содержит указание «Это программное обеспечение может распространяться под GNU General Public License или Artistic License», это означает, что можно использовать любую из этих лицензий. Используйте следующее: [.programlisting] .... LICENSE= ART10 GPLv1 LICENSE_COMB= dual .... Если предоставлены файлы лицензий, используйте это: [.programlisting] .... LICENSE= ART10 GPLv1 LICENSE_COMB= dual LICENSE_FILE_ART10= ${WRKSRC}/Artistic LICENSE_FILE_GPLv1= ${WRKSRC}/Copying .... ==== [[licenses-license_comb-ex2]] .Множественные лицензии [example] ==== Если часть порта имеет одну лицензию, а другая часть — другую, используйте `multi`: [.programlisting] .... LICENSE= GPLv2 LGPL21+ LICENSE_COMB= multi .... ==== [[makefile-portscout]] == `PORTSCOUT` Portscout — это автоматизированная утилита проверки distfile для Коллекции портов FreeBSD, подробно описанная в crossref:keeping-up[distfile-survey,Portscout: сканирование distfile портов FreeBSD]. `PORTSCOUT` определяет специальные условия, в рамках которых работа сканера дистрибутивных файлов Portscout ограничена. Ситуации, когда установлена переменная `PORTSCOUT`, включают: * Когда необходимо игнорировать distfiles для определённых версий. Например, чтобы исключить версию _8.2_ и версию _8.3_ из проверок версий distfiles, так как известно, что они неработоспособны, добавьте: + [.programlisting] .... PORTSCOUT= skipv:8.2,8.3 .... * Когда проверки версий distfile необходимо полностью отключить. Например, если порт больше не будет обновляться, добавьте: + [.programlisting] .... PORTSCOUT= ignore:1 .... * Когда необходимо проверять конкретные версии или определённые мажорные и минорные редакции distfile. Например, если нужно отслеживать только версию _0.6.4_, потому что более новые версии имеют проблемы совместимости с FreeBSD, добавьте: + [.programlisting] .... PORTSCOUT= limit:^0\.6\.4 .... * Когда URL-адреса, перечисляющие доступные версии, отличаются от URL-адресов загрузки. Например, чтобы ограничить проверку версий distfile страницей загрузки для пакета: package:databases/pgtune[] добавьте: + [.programlisting] .... PORTSCOUT= site:http://www.renpy.org/dl/release/ .... [[makefile-depend]] == Зависимости Многие порты зависят от других портов. Это очень удобная особенность большинства Unix-подобных операционных систем, включая FreeBSD. Несколько портов могут использовать общую зависимость вместо того, чтобы включать эту зависимость в каждый порт или пакет, который в ней нуждается. Существует семь переменных, которые можно использовать для обеспечения наличия всех необходимых компонентов на машине пользователя. Также есть предопределённые переменные зависимостей для распространённых случаев и несколько дополнительных для управления поведением зависимостей. [IMPORTANT] ==== Когда у программного обеспечения есть дополнительные зависимости, предоставляющие дополнительные возможности, основные зависимости, перечисленные в `*_DEPENDS`, должны включать те дополнительные зависимости, которые будут полезны большинству пользователей. Основные зависимости никогда не должны быть "минимальным" набором зависимостей. Цель состоит не в том, чтобы включить все возможные зависимости. Включайте только те, которые будут полезны большинству людей. ==== [[makefile-lib_depends]] === `LIB_DEPENDS` Эта переменная определяет разделяемые библиотеки, от которых зависит данный порт. Это список кортежей вида `_lib:dir_`, где `_lib_` — имя разделяемой библиотеки, а `_dir_` — каталог, в котором её следует искать, если она недоступна. Например, [.programlisting] .... LIB_DEPENDS= libjpeg.so:graphics/jpeg .... проверит наличие общей библиотеки jpeg с любой версией и перейдет в подкаталог [.filename]#graphics/jpeg# дерева портов, чтобы собрать и установить её, если она не найдена. Зависимость проверяется дважды: один раз внутри цели `build` и затем внутри цели `install`. Также имя зависимости добавляется в пакет, чтобы `pkg install` (см. man:pkg-install[8]) автоматически установил её, если её нет в системе пользователя. [[makefile-run_depends]] === `RUN_DEPENDS` Эта переменная определяет исполняемые файлы или файлы, от которых зависит порт во время выполнения. Это список кортежей ``_path:dir_``[:``_target_``], где `_path_` — это имя исполняемого файла или файла, _dir_ — каталог, в котором его следует искать, если он недоступен, а _target_ — цель, которую нужно вызвать в этом каталоге. Если _path_ начинается с косой черты (`/`), он считается файлом, и его существование проверяется с помощью `test -e`; в противном случае предполагается, что это исполняемый файл, и `which -s` используется для проверки наличия программы в пути поиска. Например, [.programlisting] .... RUN_DEPENDS= ${LOCALBASE}/news/bin/innd:news/inn \ xmlcatmgr:textproc/xmlcatmgr .... проверит, существует ли файл или каталог [.filename]#/usr/local/news/bin/innd#, и соберет и установит его из подкаталога [.filename]#news/inn# дерева портов, если он не найден. Также будет проверено, находится ли исполняемый файл `xmlcatmgr` в пути поиска, и если он не найден, будет выполнен переход в [.filename]#textproc/xmlcatmgr# для сборки и установки. [NOTE] ==== В этом случае `innd` является исполняемым файлом; если исполняемый файл находится в месте, которое не ожидается в пути поиска, используйте полный путь. ==== [NOTE] ==== Официальный путь поиска `PATH`, используемый в кластере сборки портов [.programlisting] .... /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin .... ==== Зависимость проверяется внутри цели `install`. Также имя зависимости добавляется в пакет, чтобы команда `pkg install` (см. man:pkg-install[8]) автоматически установила её, если она отсутствует в системе пользователя. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET`. Довольно распространённая ситуация, когда `RUN_DEPENDS` буквально совпадает с `BUILD_DEPENDS`, особенно если портируемое программное обеспечение написано на скриптовом языке или требует одинаковой среды для сборки и выполнения. В этом случае возникает соблазн и интуитивное желание напрямую присвоить одно другому: [.programlisting] .... RUN_DEPENDS= ${BUILD_DEPENDS} .... Однако такое присваивание может загрязнить зависимости во время выполнения записями, не определёнными в оригинальном `BUILD_DEPENDS` порта. Это происходит из-за ленивого вычисления присваивания переменных в man:make[1]. Рассмотрим [.filename]#Makefile# с `USE_*`, которые обрабатываются [.filename]#ports/Mk/bsd.*.mk# для добавления начальных зависимостей сборки. Например, `USES= gmake` добавляет package:devel/gmake[] в `BUILD_DEPENDS`. Чтобы предотвратить попадание таких дополнительных зависимостей в `RUN_DEPENDS`, создайте другую переменную с текущим содержимым `BUILD_DEPENDS` и присвойте её как `BUILD_DEPENDS`, так и `RUN_DEPENDS`: [.programlisting] .... MY_DEPENDS= some:devel/some \ other:lang/other BUILD_DEPENDS= ${MY_DEPENDS} RUN_DEPENDS= ${MY_DEPENDS} .... [IMPORTANT] ==== _Не используйте_ `:=` для присваивания `BUILD_DEPENDS` в `RUN_DEPENDS` или наоборот. Все переменные раскрываются немедленно, что является совершенно неправильным и почти всегда приводит к ошибке. ==== [[makefile-build_depends]] === `BUILD_DEPENDS` Эта переменная указывает исполняемые файлы или файлы, необходимые для сборки данного порта. Как и `RUN_DEPENDS`, это список кортежей ``_path:dir_``[:``_target_``]. Например, [.programlisting] .... BUILD_DEPENDS= unzip:archivers/unzip .... проверит наличие исполняемого файла с именем `unzip` и перейдет в подкаталог [.filename]#archivers/unzip# дерева портов, чтобы собрать и установить его, если он не будет найден. [NOTE] ==== "build" здесь означает все процессы от извлечения до компиляции. Зависимость проверяется внутри цели `extract`. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET` ==== [[makefile-fetch_depends]] === `FETCH_DEPENDS` Эта переменная определяет исполняемые файлы или файлы, необходимые для загрузки этого порта. Как и предыдущие две, это список кортежей ``_path:dir_``[:``_target_``]. Например, [.programlisting] .... FETCH_DEPENDS= ncftp2:net/ncftp2 .... проверит наличие исполняемого файла с именем `ncftp2` и перейдет в подкаталог [.filename]#net/ncftp2# дерева портов для сборки и установки, если файл не будет найден. Зависимость проверяется внутри цели `fetch`. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET`. [[makefile-extract_depends]] === `EXTRACT_DEPENDS` Эта переменная указывает исполняемые файлы или файлы, которые требуются для извлечения данного порта. Как и предыдущая, это список кортежей ``_path:dir_``[:``_target_``]. Например, [.programlisting] .... EXTRACT_DEPENDS= unzip:archivers/unzip .... проверит наличие исполняемого файла с именем `unzip` и перейдет в подкаталог [.filename]#archivers/unzip# дерева портов, чтобы собрать и установить его, если он не будет найден. Зависимость проверяется внутри цели `extract`. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET`. [NOTE] ==== Используйте эту переменную только если извлечение уже не работает (по умолчанию предполагается `tar`) и не может быть исправлено с помощью `USES=tar`, `USES=lha` или `USES=zip`, как описано в crossref:uses[uses,Использование макросов `USES`]. ==== [[makefile-patch_depends]] === `PATCH_DEPENDS` Эта переменная указывает исполняемые файлы или файлы, которые требуются этому порту для применения патчей. Как и предыдущая, это список кортежей ``_path:dir_``[:``_target_``]. Например, [.programlisting] .... PATCH_DEPENDS= ${NONEXISTENT}:java/jfc:extract .... будет спускаться в подкаталог [.filename]#java/jfc# дерева портов для его извлечения. Зависимость проверяется в рамках цели `patch`. Часть _target_ может быть опущена, если она совпадает с `DEPENDS_TARGET`. [[makefile-uses]] === `USES` Параметры могут быть добавлены для определения различных функций и зависимостей, используемых портом. Они указываются путем добавления этой строки в [.filename]#Makefile#: [.programlisting] .... USES= feature[:arguments] .... Для полного списка значений обратитесь к разделу crossref:uses[uses,Использование макросов `USES`]. [WARNING] ==== `USES` нельзя назначать после включения [.filename]#bsd.port.pre.mk#. ==== [[makefile-use-vars]] === `USE_*` Существует несколько переменных для определения общих зависимостей, используемых многими портами. Их использование необязательно, но помогает сократить многословность [.filename]##Makefile## портов. Каждая из них оформлена как `USE_*`. Эти переменные могут использоваться только в [.filename]##Makefile## портов и [.filename]#ports/Mk/bsd.*.mk#. Они не предназначены для настраиваемых пользователем опций — для этой цели используйте `PORT_OPTIONS`. [NOTE] ==== Всегда неправильно устанавливать любые `USE_*` в [.filename]#/etc/make.conf#. Например, установка [.programlisting] .... USE_GCC=X.Y .... (где X.Y — номер версии) добавит зависимость от gccXY для каждого порта, включая сам `lang/gccXY`! ==== [[makefile-use-vars-table]] .`USE_*` [cols="1,1", frame="none", options="header"] |=== | Переменная | Значение |`USE_GCC` a| Порт требует GCC (`gcc` или `{g-plus-plus}`) для сборки. Некоторые порты нуждаются в определённой, старой версии GCC, другие требуют современных, актуальных версий. Обычно устанавливается в `yes` (означает всегда использовать стабильную, современную версию GCC из портов, согласно `GCC_DEFAULT` в [.filename]#Mk/bsd.default-versions.mk#). Это также значение по умолчанию. Точная версия также может быть указана, например, значением `10`. GCC из базовой системы используется, если он удовлетворяет запрашиваемой версии, в противном случае подходящий компилятор собирается из портов, а `CC` и `CXX` корректируются соответствующим образом. Аргумент `:build`, следующий за указанием версии, добавляет только зависимость во время сборки порта. Например: [example] ==== [.programlisting] .... USE_GCC=yes # порт требует текущей версии GCC USE_GCC=11:build # порт требует GCC 11 только во время сборки .... ==== [NOTE] ==== `USE_GCC=any` устарел и не должен использоваться в новых портах ==== |=== Переменные, связанные с gmake и [.filename]#configure#, описаны в crossref:special[building,Механизмы сборки], тогда как autoconf, automake и libtool описаны в crossref:special[using-autotools,Использование GNU Autotools]. Переменные, связанные с Perl, описаны в crossref:special[using-perl,Использование Perl]. Переменные X11 перечислены в crossref:special[using-x11,Использование X11]. crossref:special[using-gnome,Использование GNOME] посвящено GNOME, а crossref:special[using-kde,Использование KDE] — переменным, связанным с KDE. crossref:special[using-java,Использование Java] документирует переменные Java, тогда как crossref:special[using-php,Веб-приложения, Apache и PHP] содержит информацию о модулях Apache, PHP и PEAR. Python обсуждается в crossref:special[using-python,Использование Python], а Ruby — в crossref:uses[uses-ruby,Использование Ruby]. crossref:special[using-sdl,Использование SDL] предоставляет переменные, используемые для приложений SDL, и, наконец, crossref:special[using-xfce,Использование Xfce] содержит информацию о Xfce. [[makefile-version-dependency]] === Минимальная версия зависимого пакета Минимальная версия зависимого пакета может быть указана в любом `*_DEPENDS`, кроме `LIB_DEPENDS`, используя следующий синтаксис: [.programlisting] .... p5-Spiffy>=0.26:devel/p5-Spiffy .... Первое поле содержит имя зависимого пакета, которое должно соответствовать записи в базе данных пакетов, знак сравнения и версию пакета. Зависимость считается удовлетворённой, если на машине установлен p5-Spiffy-0.26 или новее. [[makefile-note-on-dependencies]] === Заметки о зависимостях Как упомянуто выше, цель по умолчанию, вызываемая при необходимости зависимости, — это `DEPENDS_TARGET`. По умолчанию она установлена в `install`. Это пользовательская переменная; она никогда не определяется в [.filename]#Makefile# порта. Если порту требуется особый способ обработки зависимости, используйте часть `:target` в `*_DEPENDS` вместо переопределения `DEPENDS_TARGET`. При выполнении `make clean` зависимости портов также автоматически очищаются. Если это нежелательно, определите переменную `NOCLEANDEPENDS` в окружении. Это может быть особенно полезно, если среди зависимостей порта есть что-то, что требует много времени для пересборки, например KDE, GNOME или Mozilla. Для безусловной зависимости от другого порта используйте переменную `${NONEXISTENT}` в качестве первого поля `BUILD_DEPENDS` или `RUN_DEPENDS`. Используйте это только в случае, когда необходим исходный код другого порта. Время компиляции можно сократить, указав также цель. Например [.programlisting] .... BUILD_DEPENDS= ${NONEXISTENT}:graphics/jpeg:extract .... всегда будет переходить к порту `jpeg` и извлекать его. [[makefile-circular-dependencies]] === Циклические зависимости фатальны [IMPORTANT] ==== Не создавайте циклических зависимостей в дереве портов! ==== Технология сборки портов не допускает циклических зависимостей. Если такая зависимость будет добавлена, у кого-то в мире почти сразу окажется сломанной установка FreeBSD, а за этим последуют многие другие. Подобные проблемы бывает очень сложно обнаружить. Если есть сомнения, перед внесением изменений обязательно выполните: `cd /usr/ports; make index`. Этот процесс может быть довольно медленным на старых машинах, но он способен избавить множество людей, включая вас, от серьёзных проблем. [[makefile-automatic-dependencies]] === Проблемы, вызванные автоматическими зависимостями Зависимости должны быть объявлены явно или с использованием crossref:makefiles[makefile-options,OPTIONS framework]. Использование других методов, таких как автоматическое обнаружение, усложняет индексацию, что вызывает проблемы для управления портами и пакетами. [[makefile-automatic-dependencies-bad]] .Неправильное объявление необязательной зависимости [example] ==== [.programlisting] .... .include .if exists(${LOCALBASE}/bin/foo) LIB_DEPENDS= libbar.so:foo/bar .endif .... ==== Проблема с попыткой автоматического добавления зависимостей заключается в том, что файлы и настройки за пределами отдельного порта могут измениться в любой момент. Например: индекс строится, затем устанавливается группа портов. Но один из портов устанавливает проверяемый файл. Теперь индекс неверен, потому что у установленного порта неожиданно появилась новая зависимость. Индекс может оставаться неверным даже после пересборки, если другие порты также определяют свою потребность в зависимостях на основе существования других файлов. [[makefile-automatic-dependencies-good]] .Правильное объявление необязательной зависимости [example] ==== [.programlisting] .... OPTIONS_DEFINE= BAR BAR_DESC= Calling cellphones via bar BAR_LIB_DEPENDS= libbar.so:foo/bar .... ==== Проверка переменных опций является правильным методом. Это не вызовет несоответствий в индексе группы портов, при условии что опции были определены до сборки индекса. Затем можно использовать простые скрипты для автоматизации сборки, установки и обновления этих портов и их пакетов. [[makefile-masterdir]] == Подчиненные порты и `MASTERDIR` Если порту необходимо собирать немного разные версии пакетов, используя переменную (например, разрешение или размер бумаги) с разными значениями, создайте по одному подкаталогу для каждого пакета, чтобы пользователям было проще понять, что делать, но старайтесь максимально использовать общие файлы между портами. Обычно, при грамотном использовании переменных, во всех каталогах, кроме одного, требуется лишь очень короткий [.filename]#Makefile#. В единственном [.filename]#Makefile# укажите каталог с остальными файлами с помощью `MASTERDIR`. Также используйте переменную как часть crossref:makefiles[porting-pkgname,`PKGNAMESUFFIX`], чтобы пакеты имели разные имена. Это лучше всего продемонстрировать на примере. Это часть файла [.filename]#print/pkfonts300/Makefile#; [.programlisting] .... 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 .... Пакет `package:print/pkfonts300[]` также содержит все обычные исправления, файлы пакетов и т.д. При запуске `make` в этом месте будет взято значение разрешения по умолчанию (300), и порт будет собран в обычном режиме. Что касается других разрешений, это _полный_ [.filename]#print/pkfonts360/Makefile#: [.programlisting] .... RESOLUTION= 360 MASTERDIR= ${.CURDIR}/../pkfonts300 .include "${MASTERDIR}/Makefile" .... ([.filename]#print/pkfonts118/Makefile#, [.filename]#print/pkfonts600/Makefile# и все остальные аналогичны). Определение `MASTERDIR` указывает [.filename]#bsd.port.mk#, что стандартный набор подкаталогов, таких как `FILESDIR` и `SCRIPTDIR`, следует искать в [.filename]#pkfonts300#. Строка `RESOLUTION=360` переопределит строку `RESOLUTION=300` в [.filename]#pkfonts300/Makefile#, и порт будет собран с разрешением, установленным на 360. [[makefile-manpages]] == Страницы Справочника Если порт размещает дерево man в другом месте, отличном от `PREFIX`, используйте `MANDIRS` для указания этих каталогов. Обратите внимание, что файлы, соответствующие страницам руководства, должны быть добавлены в [.filename]#pkg-plist# вместе с остальными файлами. Назначение `MANDIRS` — обеспечить автоматическое сжатие страниц руководства, поэтому имена файлов имеют суффикс [.filename]#.gz#. [[makefile-info]] == Файлы информации Если пакету требуется установить файлы GNU info, перечислите их в `INFO` (без завершающего `.info`), по одному документу на строку. Предполагается, что эти файлы будут установлены в [.filename]#PREFIX/INFO_PATH#. Измените `INFO_PATH`, если пакет использует другое расположение. Однако это не рекомендуется. Эти записи содержат только путь относительно [.filename]#PREFIX/INFO_PATH#. Например, пакет package:lang/gcc34[] устанавливает файлы info в [.filename]#PREFIX/INFO_PATH/gcc34#, и `INFO` будет выглядеть примерно так: [.programlisting] .... INFO= gcc34/cpp gcc34/cppinternals gcc34/g77 ... .... Соответствующий код установки/удаления будет автоматически добавлен во временный файл [.filename]#pkg-plist# перед регистрацией пакета. [[makefile-options]] == Параметры Makefile Многие приложения могут быть собраны с дополнительными или различными конфигурациями. Примеры включают выбор естественного (человеческого) языка, графический интерфейс или командная строка, тип поддерживаемой базы данных. Пользователям может потребоваться конфигурация, отличная от стандартной, поэтому система портов предоставляет хуки, которые автор порта может использовать для управления вариантом сборки. Правильная поддержка этих опций сделает пользователей счастливыми и эффективно предоставит два или более порта по цене одного. [[makefile-options-options]] === `OPTIONS` [[makefile-options-background]] ==== Пояснения `OPTIONS_*` предоставляют пользователю, устанавливающему порт, диалоговое окно с доступными опциями, после чего сохраняют выбранные опции в [.filename]#${PORT_DBDIR}/${OPTIONS_NAME}/options#. При следующей сборке порта эти опции будут использованы повторно. `PORT_DBDIR` по умолчанию имеет значение [.filename]#/var/db/ports#. `OPTIONS_NAME` соответствует имени порта (origin) с заменой разделителя на подчёркивания, например, для package:dns/bind99[] это будет `dns_bind99`. Когда пользователь запускает `make config` (или впервые запускает `make build`), система проверяет наличие файла [.filename]#${PORT_DBDIR}/${OPTIONS_NAME}/options#. Если этот файл не существует, используются значения `OPTIONS_*`, и отображается диалоговое окно, где можно включить или отключить опции. Затем файл [.filename]#options# сохраняется, а настроенные переменные используются при сборке порта. Если новая версия порта добавляет новые `OPTIONS`, пользователю будет показан диалог с сохранёнными значениями старых `OPTIONS`, заполненными заранее. `make showconfig` показывает сохранённую конфигурацию. Используйте `make rmconfig` для удаления сохранённой конфигурации. [[makefile-options-syntax]] ==== Синтаксис `OPTIONS_DEFINE` содержит список `OPTIONS`, которые будут использоваться. Они независимы друг от друга и не сгруппированы: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 .... После определения `OPTIONS` описываются (необязательно, но настоятельно рекомендуется): [.programlisting] .... OPT1_DESC= Describe OPT1 OPT2_DESC= Describe OPT2 OPT3_DESC= Describe OPT3 OPT4_DESC= Describe OPT4 OPT5_DESC= Describe OPT5 OPT6_DESC= Describe OPT6 .... [.filename]#ports/Mk/bsd.options.desc.mk# содержит описания для многих распространённых `OPTIONS`. Хотя они часто полезны, переопределите их, если описание недостаточно для порта. [TIP] ==== При описании параметров рассматривайте их с точки зрения пользователя: «Какую функциональность это изменяет?» и «Зачем мне включать этот параметр?» Не просто повторяйте название. Например, описание параметра `NLS` как «включить поддержку NLS» не помогает пользователю, который уже видит название параметра, но может не знать, что оно означает. Описание вроде «Поддержка родного языка с помощью утилиты gettext» гораздо полезнее. ==== [IMPORTANT] ==== Названия параметров всегда пишутся в верхнем регистре. Они не могут использовать смешанный регистр или нижний регистр. ==== `OPTIONS` могут быть сгруппированы как переключаемые варианты, где допускается только один выбор из каждой группы: [.programlisting] .... OPTIONS_SINGLE= SG1 OPTIONS_SINGLE_SG1= OPT3 OPT4 .... [WARNING] ==== В каждый момент времени _должна_ быть выбрана одна опция из каждой группы `OPTIONS_SINGLE`, чтобы параметры были действительными. Один вариант из каждой группы _должен_ быть добавлен в `OPTIONS_DEFAULT`. ==== `OPTIONS` могут быть сгруппированы как переключаемые варианты, где ни один или только один вариант из каждой группы разрешён: [.programlisting] .... OPTIONS_RADIO= RG1 OPTIONS_RADIO_RG1= OPT7 OPT8 .... `OPTIONS` также могут быть сгруппированы в виде списков "множественного выбора", где _хотя бы одна_ опция должна быть включена: [.programlisting] .... OPTIONS_MULTI= MG1 OPTIONS_MULTI_MG1= OPT5 OPT6 .... `OPTIONS` также могут быть сгруппированы в виде списков "множественного выбора", где ни одна или любые опции могут быть включены: [.programlisting] .... OPTIONS_GROUP= GG1 OPTIONS_GROUP_GG1= OPT9 OPT10 .... `OPTIONS` по умолчанию не установлены, если они не перечислены в `OPTIONS_DEFAULT`: [.programlisting] .... OPTIONS_DEFAULT= OPT1 OPT3 OPT6 .... Определения `OPTIONS` должны быть указаны до включения файла [.filename]#bsd.port.options.mk#. Значения `PORT_OPTIONS` можно проверять только после включения [.filename]#bsd.port.options.mk#. Включение [.filename]#bsd.port.pre.mk# также может использоваться и до сих пор широко применяется в портах, написанных до введения [.filename]#bsd.port.options.mk#. Однако следует учитывать, что некоторые переменные не будут работать как ожидается после включения [.filename]#bsd.port.pre.mk#, обычно это некоторые флаги `USE_*`. [[ports-options-simple-use]] .Простое использование `OPTIONS` [example] ==== [.programlisting] .... 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 .... ==== [[ports-options-check-unset]] .Проверка неустановленных `OPTIONS` порта [example] ==== [.programlisting] .... .if ! ${PORT_OPTIONS:MEXAMPLES} CONFIGURE_ARGS+=--without-examples .endif .... Приведённая выше форма не рекомендуется. Предпочтительный метод — использование параметра configure для фактического включения и отключения функции в соответствии с опцией: [.programlisting] .... # Will add --with-examples / --without-examples EXAMPLES_CONFIGURE_WITH= examples .... ==== [[ports-options-practical-use]] .Пример реального использования `OPTIONS` [example] ==== [.programlisting] .... OPTIONS_DEFINE= EXAMPLES OPTIONS_DEFAULT= PGSQL LDAP SSL OPTIONS_SINGLE= BACKEND OPTIONS_SINGLE_BACKEND= MYSQL PGSQL BDB 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 .... ==== [[makefile-options-default]] ==== Опции по умолчанию Эти опции всегда включены по умолчанию. * `DOCS` — сборка и установка документации. * `NLS` — Поддержка родного языка. * `EXAMPLES` — сборка и установка примеров. * `IPV6` — Поддержка протокола IPv6. [NOTE] ==== Нет необходимости добавлять их в `OPTIONS_DEFAULT`. Однако, чтобы они были активны и отображались в диалоге выбора опций, их необходимо добавить в `OPTIONS_DEFINE`. ==== [[makefile-options-auto-activation]] === Автоматическая активация функций При использовании скрипта GNU configure следите за тем, какие дополнительные функции активируются автоматическим определением. Явно отключите ненужные дополнительные функции, добавив `--without-xxx` или `--disable-xxx` в `CONFIGURE_ARGS`. [[makefile-options-auto-activation-bad]] .Неправильная обработка опции [example] ==== [.programlisting] .... .if ${PORT_OPTIONS:MFOO} LIB_DEPENDS+= libfoo.so:devel/foo CONFIGURE_ARGS+= --enable-foo .endif .... ==== В приведённом выше примере представьте, что библиотека libfoo установлена в системе. Пользователь не хочет, чтобы это приложение использовало libfoo, поэтому он отключил соответствующую опцию в диалоге `make config`. Однако скрипт configure приложения обнаруживает библиотеку в системе и включает её поддержку в итоговом исполняемом файле. Теперь, когда пользователь решает удалить libfoo из системы, система портов не протестует (зависимость от libfoo не была записана), но приложение перестаёт работать. [[makefile-options-auto-activation-good]] .Правильная обработка опции [example] ==== [.programlisting] .... FOO_LIB_DEPENDS= libfoo.so:devel/foo # Will add --enable-foo / --disable-foo FOO_CONFIGURE_ENABLE= foo .... ==== [NOTE] ==== В некоторых случаях сокращенный синтаксис условных выражений может вызывать проблемы со сложными конструкциями. Ошибки обычно имеют вид `Malformed conditional`, тогда можно использовать альтернативный синтаксис. [.programlisting] .... .if !empty(VARIABLE:MVALUE) .... в качестве альтернативы [.programlisting] .... .if ${VARIABLE:MVALUE} .... ==== [[options-helpers]] === Помощники параметров Существуют макросы, которые помогают упростить условные значения, различающиеся в зависимости от установленных опций. Для удобства приведён полный список: `PLIST_SUB`, `SUB_LIST`:: Для автоматической генерации `%%_OPT_%%` и `%%NO__OPT__%%` см. crossref:makefiles[options_sub, `OPTIONS_SUB`]. + Для более сложных случаев использования см. crossref:makefiles[options-variables, Замена общих переменных, `OPT_VARIABLE` и `OPT_VARIABLE_OFF`]. `CONFIGURE_ARGS`:: Для информации о `--enable-_x_` и `--disable-_x_` см. crossref:makefiles[options-configure_enable, `OPT_CONFIGURE_ENABLE`]. + О `--with-_x_` и `--without-_x_` см. crossref:makefiles[options-configure_with, `OPT_CONFIGURE_WITH`]. + Во всех остальных случаях см. crossref:makefiles[options-configure_on, `OPT_CONFIGURE_ON` и `OPT_CONFIGURE_OFF`]. `CMAKE_ARGS`:: Для аргументов, которые являются булевыми значениями (`on`, `off`, `true`, `false`, `0`, `1`), см. crossref:makefiles[options-cmake_bool, `OPT_CMAKE_BOOL` и `OPT_CMAKE_BOOL_OFF`]. + Для всех остальных случаев см. crossref:makefiles[options-cmake_on, `OPT_CMAKE_ON` и `OPT_CMAKE_OFF`]. `MESON_ARGS`:: Для аргументов, принимающих `true` или `false`, см. crossref:makefiles[options-meson_true, `OPT_MESON_TRUE` и `OPT_MESON_FALSE`]. + Для аргументов, принимающих `yes` или `no`, используйте crossref:makefiles[options-meson_yes, `OPT_MESON_YES` и `OPT_MESON_NO`]. + Для аргументов, принимающих `enabled` или `disabled`, см. crossref:makefiles[options-meson_enabled, `OPT_MESON_ENABLED` и `OPT_MESON_DISABLED`]. + Во всех остальных случаях используйте crossref:makefiles[options-meson_on, `OPT_MESON_ON` и `OPT_MESON_OFF`]. `QMAKE_ARGS`:: См. crossref:makefiles[options-qmake_on, `OPT_QMAKE_ON` и `OPT_QMAKE_OFF`]. `USE_*`:: См. crossref:makefiles[options-use, `OPT_USE` и `OPT_USE_OFF`]. `*_DEPENDS`:: См. crossref:makefiles[options-dependencies, Зависимости, `OPT_DEPTYPE` и `OPT_DEPTYPE_OFF`]. `*` (Любая переменная):: Наиболее используемые переменные имеют своих помощников, см. crossref:makefiles[options-variables, Замена Общих Переменных, `OPT_VARIABLE` и `OPT_VARIABLE_OFF`]. + Для любой переменной без специального помощника см. crossref:makefiles[options-vars, `OPT_VARS` и `OPT_VARS_OFF`]. Зависимости параметров:: Когда для работы опции требуется другая опция, см. crossref:makefiles[options-implies, `OPT_IMPLIES`]. Конфликты опций:: Когда опция не может работать, если включена другая, см. crossref:makefiles[options-prevents, `OPT_PREVENTS` и `OPT_PREVENTS_MSG`]. Цели сборки:: Когда для опции требуется дополнительная обработка, см. crossref:makefiles[options-targets, Дополнительные цели сборки, `_target_-_OPT_-on` и `_target_-_OPT_-off`]. [[options_sub]] ==== `OPTIONS_SUB` Если `OPTIONS_SUB` установлен в `yes`, то каждая из опций, добавленных в `OPTIONS_DEFINE`, будет добавлена в `PLIST_SUB` и `SUB_LIST`, например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPTIONS_SUB= yes .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .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 .... [NOTE] ==== Значение `OPTIONS_SUB` игнорируется. Установка любого значения добавит записи `PLIST_SUB` и `SUB_LIST` для _всех_ опций. ==== [[options-use]] ==== `OPT_USE` и `OPT_USE_OFF` Когда выбрана опция _OPT_, для каждой пары `_ключ=значение_` в ``OPT_USE``, _значение_ добавляется к соответствующему `USE_KEY`. Если _значение_ содержит пробелы, замените их запятыми, и они будут преобразованы обратно в пробелы во время обработки. `OPT_USE_OFF` работает аналогично, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_USES= xorg OPT1_USE= mysql=yes xorg=x11,xextproto,xext,xrandr OPT1_USE_OFF= openssl=yes .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} USE_MYSQL= yes USES+= xorg USE_XORG= x11 xextproto xext xrandr .else USE_OPENSSL= yes .endif .... [[options-configure-helpers]] ==== Помощники `CONFIGURE_ARGS` [[options-configure_enable]] ===== `OPT_CONFIGURE_ENABLE` Когда выбрана опция _OPT_, для каждого _элемента_ в `OPT_CONFIGURE_ENABLE` к `CONFIGURE_ARGS` добавляется `--enable-_элемент_`. Если опция _OPT_ _не_ выбрана, к `CONFIGURE_ARGS` добавляется `--disable-_элемент_`. Необязательный аргумент может быть указан с помощью символа `=`. Этот аргумент добавляется только к опции конфигурации `--enable-_элемент_`. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT1_CONFIGURE_ENABLE= test1 test2 OPT2_CONFIGURE_ENABLE= test2=exhaustive .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .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 .... [[options-configure_with]] ===== `OPT_CONFIGURE_WITH` Когда выбрана опция _OPT_, для каждого _элемента_ в `_OPT_CONFIGURE_WITH` к `CONFIGURE_ARGS` добавляется `--with-_элемент_`. Если опция _OPT_ _не_ выбрана, к `CONFIGURE_ARGS` добавляется `--without-_элемент_`. Необязательный аргумент можно указать с помощью символа `=`. Этот аргумент добавляется только к опции конфигурации `--with-_элемент_`. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT1_CONFIGURE_WITH= test1 OPT2_CONFIGURE_WITH= test2=exhaustive .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 .include .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 .... [[options-configure_on]] ===== `OPT_CONFIGURE_ON` и `OPT_CONFIGURE_OFF` Когда выбрана опция _OPT_, значение `OPT_CONFIGURE_ON`, если оно определено, добавляется к `CONFIGURE_ARGS`. `OPT_CONFIGURE_OFF` работает аналогично, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_CONFIGURE_ON= --add-test OPT1_CONFIGURE_OFF= --no-test .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --add-test .else CONFIGURE_ARGS+= --no-test .endif .... [TIP] ==== В большинстве случаев помощники crossref:makefiles[options-configure_enable, `OPT_CONFIGURE_ENABLE`] и crossref:makefiles[options-configure_with, `OPT_CONFIGURE_WITH`] предоставляют более короткий и понятный функционал. ==== [[options-cmake-helpers]] ==== Помощники `CMAKE_ARGS` [[options-cmake_on]] ===== `OPT_CMAKE_ON` и `OPT_CMAKE_OFF` Когда выбрана опция _OPT_, значение `OPT_CMAKE_ON`, если оно определено, добавляется к `CMAKE_ARGS`. `OPT_CMAKE_OFF` работает аналогично, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_CMAKE_ON= -DTEST:BOOL=true -DDEBUG:BOOL=true OPT1_CMAKE_OFF= -DOPTIMIZE:BOOL=true .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} CMAKE_ARGS+= -DTEST:BOOL=true -DDEBUG:BOOL=true .else CMAKE_ARGS+= -DOPTIMIZE:BOOL=true .endif .... [TIP] ==== См. crossref:makefiles[options-cmake_bool, `OPT_CMAKE_BOOL` и `OPT_CMAKE_BOOL_OFF`] для более краткой записи, когда значение является булевым. ==== [[options-cmake_bool]] ===== `OPT_CMAKE_BOOL` и `OPT_CMAKE_BOOL_OFF` Когда выбрана опция _OPT_, для каждого _элемента_ в `OPT_CMAKE_BOOL` добавляется `-D_элемент_:BOOL=true` к `CMAKE_ARGS`. Если опция _OPT_ _не_ выбрана, `-D_элемент_:BOOL=false` добавляется к `CONFIGURE_ARGS`. `OPT_CMAKE_BOOL_OFF` работает наоборот: `-D_элемент_:BOOL=false` добавляется к `CMAKE_ARGS`, когда опция выбрана, и `-D_элемент_:BOOL=true`, когда опция _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_CMAKE_BOOL= TEST DEBUG OPT1_CMAKE_BOOL_OFF= OPTIMIZE .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .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 .... [[options-meson-helpers]] ==== Помощники `MESON_ARGS` [[options-meson_on]] ===== `OPT_MESON_ON` и `OPT_MESON_OFF` Когда выбрана опция _OPT_, значение `OPT_MESON_ON`, если оно определено, добавляется к `MESON_ARGS`. `OPT_MESON_OFF` работает аналогичным образом, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_MESON_ON= -Dopt=1 OPT1_MESON_OFF= -Dopt=2 .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dopt=1 .else MESON_ARGS+= -Dopt=2 .endif .... [[options-meson_true]] ===== `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`, когда опция _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_MESON_TRUE= test debug OPT1_MESON_FALSE= optimize .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dtest=true -Ddebug=true \ -Doptimize=false .else MESON_ARGS+= -Dtest=false -Ddebug=false \ -Doptimize=true .endif .... [[options-meson_yes]] ===== `OPT_MESON_YES` и `OPT_MESON_NO` Когда выбрана опция _OPT_, для каждого _элемента_ в `OPT_MESON_YES` добавляется `-D_элемент_=yes` к `MESON_ARGS`. Если опция _OPT_ _не_ выбрана, добавляется `-D_элемент_=no` к `MESON_ARGS`. `OPT_MESON_NO` работает противоположным образом: `-D_элемент_=no` добавляется к `MESON_ARGS`, когда опция выбрана, и `-D_элемент_=yes`, когда опция _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_MESON_YES= test debug OPT1_MESON_NO= optimize .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dtest=yes -Ddebug=yes \ -Doptimize=no .else MESON_ARGS+= -Dtest=no -Ddebug=no \ -Doptimize=yes .endif .... [[options-meson_enabled]] ===== `OPT_MESON_ENABLED` и `OPT_MESON_DISABLED` Когда выбрана опция _OPT_, для каждого _элемента_ в `OPT_MESON_ENABLED` добавляется `-D_элемент_=enabled` к `MESON_ARGS`. Когда опция _OPT_ _не_ выбрана, добавляется `-D_элемент_=disabled` к `MESON_ARGS`. `OPT_MESON_DISABLED` работает противоположным образом: `-D_элемент_=disabled` добавляется к `MESON_ARGS`, когда опция выбрана, и `-D_элемент_=enabled`, когда опция _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_MESON_ENABLED= test OPT1_MESON_DISABLED= debug .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dtest=enabled -Ddebug=disabled .else MESON_ARGS+= -Dtest=disabled -Ddebug=enabled .endif .... [[options-qmake_on]] ==== `OPT_QMAKE_ON` и `OPT_QMAKE_OFF` Когда выбрана опция _OPT_, значение `OPT_QMAKE_ON`, если оно определено, добавляется к `QMAKE_ARGS`. `OPT_QMAKE_OFF` работает аналогичным образом, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_QMAKE_ON= -DTEST:BOOL=true OPT1_QMAKE_OFF= -DPRODUCTION:BOOL=true .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} QMAKE_ARGS+= -DTEST:BOOL=true .else QMAKE_ARGS+= -DPRODUCTION:BOOL=true .endif .... [[options-implies]] ==== `OPT_IMPLIES` Предоставляет способ добавления зависимостей между опциями. При выборе _OPT_ все перечисленные в этой переменной опции также будут выбраны. В качестве примера можно использовать описанный ранее crossref:makefiles[options-configure_enable,`OPT_CONFIGURE_ENABLE`]: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT1_IMPLIES= OPT2 OPT1_CONFIGURE_ENABLE= opt1 OPT2_CONFIGURE_ENABLE= opt2 .... Эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 .include .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --enable-opt1 .else CONFIGURE_ARGS+= --disable-opt1 .endif .if ${PORT_OPTIONS:MOPT2} || ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --enable-opt2 .else CONFIGURE_ARGS+= --disable-opt2 .endif .... [[options-implies-ex1]] .Простое использование `OPT_IMPLIES` [example] ==== Этот порт имеет опцию `X11` и опцию `GNOME`, для сборки которой необходимо выбрать опцию `X11`. [.programlisting] .... OPTIONS_DEFINE= X11 GNOME OPTIONS_DEFAULT= X11 X11_USES= xorg X11_USE= xorg=xi,xextproto GNOME_USE= gnome=gtk30 GNOME_IMPLIES= X11 .... ==== [[options-prevents]] ==== `OPT_PREVENTS` и `OPT_PREVENTS_MSG` Предоставляет способ добавления конфликтов между опциями. Когда выбрана _OPT_, все опции, перечисленные в `OPT_PREVENTS`, должны быть сняты. Если задано `OPT_PREVENTS_MSG` и возникает конфликт, его содержимое будет показано с объяснением причины конфликта. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT1_PREVENTS= OPT2 OPT1_PREVENTS_MSG= OPT1 and OPT2 enable conflicting options .... Примерно эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 .include .if ${PORT_OPTIONS:MOPT2} && ${PORT_OPTIONS:MOPT1} BROKEN= Option OPT1 conflicts with OPT2 (select only one) .endif .... Единственное отличие заключается в том, что первый вариант выведет ошибку после выполнения `make config`, предлагая изменить выбранные настройки. [[options-prevents-ex1]] .Простое использование `OPT_PREVENTS` [example] ==== Этот порт имеет опции `X509` и `SCTP`. Обе опции добавляют патчи, но патчи конфликтуют друг с другом, поэтому их нельзя выбрать одновременно. [.programlisting] .... OPTIONS_DEFINE= X509 SCTP SCTP_PATCHFILES= ${PORTNAME}-6.8p1-sctp-2573.patch.gz:-p1 SCTP_CONFIGURE_WITH= sctp X509_PATCH_SITES= http://www.roumenpetrov.info/openssh/x509/:x509 X509_PATCHFILES= ${PORTNAME}-7.0p1+x509-8.5.diff.gz:-p1:x509 X509_PREVENTS= SCTP X509_PREVENTS_MSG= X509 and SCTP patches conflict .... ==== [[options-vars]] ==== `OPT_VARS` и `OPT_VARS_OFF` Предоставляет универсальный способ установки и добавления значений переменным. [WARNING] ==== Перед использованием `OPT_VARS` и `OPT_VARS_OFF` проверьте, доступен ли более специфичный вспомогательный инструмент в crossref:makefiles[options-variables, Универсальная замена переменных, `OPT_VARIABLE` и `OPT_VARIABLE_OFF`]. ==== Когда выбрана опция _OPT_ и определены `OPT_VARS`, пары `_key_=_value_` и `_key_+=_value_` обрабатываются из `OPT_VARS`. Оператор `=` приводит к перезаписи существующего значения `KEY`, а `+=` добавляет к значению. `OPT_VARS_OFF` работает аналогично, но когда `OPT` _не_ выбрана. [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 OPT3 OPT1_VARS= also_build+=bin1 OPT2_VARS= also_build+=bin2 OPT3_VARS= bin3_build=yes OPT3_VARS_OFF= bin3_build=no MAKE_ARGS= ALSO_BUILD="${ALSO_BUILD}" BIN3_BUILD="${BIN3_BUILD}" .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT2 MAKE_ARGS= ALSO_BUILD="${ALSO_BUILD}" BIN3_BUILD="${BIN3_BUILD}" .include .if ${PORT_OPTIONS:MOPT1} ALSO_BUILD+= bin1 .endif .if ${PORT_OPTIONS:MOPT2} ALSO_BUILD+= bin2 .endif .if ${PORT_OPTIONS:MOPT2} BIN3_BUILD= yes .else BIN3_BUILD= no .endif .... [IMPORTANT] ==== Значения, содержащие пробелы, должны быть заключены в кавычки: [.programlisting] .... OPT_VARS= foo="bar baz" .... Это связано с тем, как man:make[1] обрабатывает пробелы при раскрытии переменных. Когда `OPT_VARS= foo=bar baz` раскрывается, переменная в итоге содержит две строки: `foo=bar` и `baz`. Однако отправитель, вероятно, предполагал, что должна быть только одна строка — `foo=bar baz`. Заключение значения в кавычки предотвращает использование пробела в качестве разделителя. Также _не_ добавляйте лишние пробелы после знака `_var_=` и перед значением, это также разобьёт строку на две части. _Это не сработает_: [.programlisting] .... OPT_VARS= foo= bar .... ==== [[options-dependencies]] ==== Зависимости, `OPT_DEPTYPE` и `OPT_DEPTYPE_OFF` Для любого из этих типов зависимостей: * `PKG_DEPENDS` * `EXTRACT_DEPENDS` * `PATCH_DEPENDS` * `FETCH_DEPENDS` * `BUILD_DEPENDS` * `LIB_DEPENDS` * `RUN_DEPENDS` Когда выбрана опция _OPT_, значение `OPT_DEPTYPE`, если оно определено, добавляется к `DEPTYPE`. `OPT_DEPTYPE_OFF` работает аналогично, но когда _не_ выбрана `OPT`. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_LIB_DEPENDS= liba.so:devel/a OPT1_LIB_DEPENDS_OFF= libb.so:devel/b .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} LIB_DEPENDS+= liba.so:devel/a .else LIB_DEPENDS+= libb.so:devel/b .endif .... [[options-variables]] ==== Универсальная замена переменных, `OPT_VARIABLE` и `OPT_VARIABLE_OFF` Для любой из этих переменных: * `ALL_TARGET` * `BINARY_ALIAS` * `BROKEN` * `CATEGORIES` * `CFLAGS` * `CONFIGURE_ENV` * `CONFLICTS` * `CONFLICTS_BUILD` * `CONFLICTS_INSTALL` * `CPPFLAGS` * `CXXFLAGS` * `DESKTOP_ENTRIES` * `DISTFILES` * `EXTRACT_ONLY` * `EXTRA_PATCHES` * `GH_ACCOUNT` * `GH_PROJECT` * `GH_SUBDIR` * `GH_TAGNAME` * `GH_TUPLE` * `GL_ACCOUNT` * `GL_COMMIT` * `GL_PROJECT` * `GL_SITE` * `GL_SUBDIR` * `GL_TUPLE` * `IGNORE` * `INFO` * `INSTALL_TARGET` * `LDFLAGS` * `LIBS` * `MAKE_ARGS` * `MAKE_ENV` * `MASTER_SITES` * `PATCHFILES` * `PATCH_SITES` * `PLIST_DIRS` * `PLIST_FILES` * `PLIST_SUB` * `PORTDOCS` * `PORTEXAMPLES` * `SUB_FILES` * `SUB_LIST` * `TEST_TARGET` * `USES` Когда выбрана опция _OPT_, значение `OPT_ABOVEVARIABLE`, если оно определено, добавляется к `_ABOVEVARIABLE_`. `OPT_ABOVEVARIABLE_OFF` работает аналогично, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 OPT1_USES= gmake OPT1_CFLAGS_OFF= -DTEST .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include .if ${PORT_OPTIONS:MOPT1} USES+= gmake .else CFLAGS+= -DTEST .endif .... [NOTE] ==== Некоторые переменные отсутствуют в этом списке, в частности `PKGNAMEPREFIX` и `PKGNAMESUFFIX`. Это сделано намеренно. Порт _не должен_ изменять своё имя при изменении набора опций. ==== [WARNING] ==== Некоторые из этих переменных, по крайней мере `ALL_TARGET`, `DISTFILES` и `INSTALL_TARGET`, получают свои значения по умолчанию _после_ обработки опций. С такими строками в [.filename]#Makefile#: [.programlisting] .... ALL_TARGET= all DOCS_ALL_TARGET= doc .... Если опция `DOCS` включена, `ALL_TARGET` будет иметь конечное значение `all doc`; если опция отключена, значение будет `all`. Только со строкой помощника опций в [.filename]#Makefile#: [.programlisting] .... DOCS_ALL_TARGET= doc .... Если опция `DOCS` включена, `ALL_TARGET` будет иметь окончательное значение `doc`; если опция отключена, значение будет `all`. ==== [[options-targets]] ==== Дополнительные цели сборки, `_target_-_OPT_-on` и `_target_-_OPT_-off` Эти цели в [.filename]#Makefile# могут принимать дополнительные опциональные цели сборки: * `pre-fetch` * `do-fetch` * `post-fetch` * `pre-extract` * `do-extract` * `post-extract` * `pre-patch` * `do-patch` * `post-patch` * `pre-configure` * `do-configure` * `post-configure` * `pre-build` * `do-build` * `post-build` * `pre-install` * `do-install` * `post-install` * `post-stage` * `pre-package` * `do-package` * `post-package` Когда выбрана опция _OPT_, цель `_TARGET_-_OPT_-on`, если она определена, выполняется после `_TARGET_`. `_TARGET_-_OPT_-off` работает аналогично, но когда `OPT` _не_ выбрана. Например: [.programlisting] .... OPTIONS_DEFINE= OPT1 post-patch-OPT1-on: @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${EXAMPLESDIR}/|' ${WRKSRC}/Makefile post-patch-OPT1-off: @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${PREFIX}/bin/|' ${WRKSRC}/Makefile .... эквивалентно: [.programlisting] .... OPTIONS_DEFINE= OPT1 .include post-patch: .if ${PORT_OPTIONS:MOPT1} @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${EXAMPLESDIR}/|' ${WRKSRC}/Makefile .else @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${PREFIX}/bin/|' ${WRKSRC}/Makefile .endif .... [[makefile-wrkdir]] == Указание рабочего каталога Каждый порт извлекается в рабочий каталог, который должен быть доступен для записи. Система портов по умолчанию распаковывает `DISTFILES` в каталог с именем `${DISTNAME}`. Другими словами, если в [.filename]#Makefile# указано: [.programlisting] .... PORTNAME= foo DISTVERSION= 1.0 .... то файлы дистрибутива порта содержат каталог верхнего уровня [.filename]#foo-1.0#, и остальные файлы находятся в этом каталоге. Если нужно расположение файлов в других каталогах, можно переопределить ряд переменных. [[makefile-wrksrc]] === `WRKSRC` Переменная указывает имя каталога, который создается при распаковке distfiles приложения. Чтобы в нашем предыдущем примере распаковка происходила в каталог с именем [.filename]#foo# (а не [.filename]#foo-1.0#), напишите: [.programlisting] .... WRKSRC= ${WRKDIR}/foo .... или можно [.programlisting] .... WRKSRC= ${WRKDIR}/${PORTNAME} .... [[makefile-wrksrc_subdir]] === `WRKSRC_SUBDIR` Если исходные файлы, необходимые для порта, находятся в подкаталоге распакованного дистрибутива, присвойте `WRKSRC_SUBDIR` имя этого каталога. [.programlisting] .... WRKSRC_SUBDIR= src .... [[makefile-no_wrksubdir]] === `NO_WRKSUBDIR` Если порт не распаковывается в подкаталог вообще, установите `NO_WRKSUBDIR`, чтобы указать это. [.programlisting] .... NO_WRKSUBDIR= yes .... [NOTE] ==== Поскольку `WRKDIR` является единственным каталогом, который должен быть доступен для записи во время сборки, и используется для хранения многих файлов, фиксирующих состояние сборки, извлечение порта будет принудительно выполнено в подкаталог. ==== [[conflicts]] == Обработка конфликтов Существует три различные переменные для регистрации конфликтов между пакетами и портами: `CONFLICTS`, `CONFLICTS_INSTALL` и `CONFLICTS_BUILD`. [NOTE] ==== Эти переменные автоматически устанавливают переменную `IGNORE`, более подробно описанную в crossref:porting-dads[dads-noinstall,Пометка порта как неустанавливаемого с помощью `BROKEN`, `FORBIDDEN` или `IGNORE`]. ==== При удалении одного из нескольких конфликтующих портов рекомендуется оставлять `CONFLICTS` в тех других портах на несколько месяцев, чтобы учесть пользователей, которые обновляются лишь время от времени. [[conclicts-conflicts_install]] `CONFLICTS_INSTALL`:: Если пакет не может сосуществовать с другими пакетами (из-за конфликтов файлов, несовместимости во время выполнения и т.д.). Проверка `CONFLICTS_INSTALL` выполняется после этапа сборки и перед этапом установки. [[conclicts-conflicts_build]] `CONFLICTS_BUILD`:: Если порт не может быть собран, когда уже установлены другие определённые порты. Конфликты сборки не фиксируются в результирующем пакете. [[conclicts-conflicts]] `CONFLICTS`:: Если порт не может быть собран, когда определённый порт уже установлен и итоговый пакет не может сосуществовать с другим пакетом. Проверка `CONFLICTS` выполняется до этапа сборки и до этапа установки. Каждый элемент, разделённый пробелами, в значениях переменных `CONFLICTS*` сопоставляется с пакетами(кроме того, который собирается) с использованием правил раскрытия шаблонов имён файлов в оболочке shell. Это позволяет перечислить все варианты порта в списке конфликтов вместо необходимости исключать собираемый вариант из этого списка. Например, если установлен git-lite, `CONFLICTS_INSTALL=git git-lite` позволит выполнить: [source, shell] .... % make -C devel/git FLAVOR=lite all deinstall install .... Но следующая команда сообщит о конфликте, так как установленное имя базового пакета — `git-lite`, а `git` будет собран, но не может быть установлен вместе с `git-lite`: [source, shell] .... % make -C devel/git FLAVOR=default all deinstall install .... Без этой функции Makefile потребовал бы по одному `_flavor__CONFLICTS_INSTALL` для каждого варианта, перечисляя все остальные варианты. Наиболее распространённым содержимым одной из этих переменных является база пакета другого порта. База пакета — это имя пакета без указания версии, её можно получить, выполнив команду `make -V PKGBASE`. [[conflicts-ex1]] .Простой пример использования `CONFLICTS*` [example] ==== Пакет package:dns/bind99[] не может быть установлен, если присутствует пакет package:dns/bind910[], так как они устанавливают одинаковые файлы. Сначала соберите базовый пакет для использования: [source, shell] .... % make -C dns/bind99 -V PKGBASE bind99 % make -C dns/bind910 -V PKGBASE bind910 .... Затем добавьте в [.filename]#Makefile# пакета package:dns/bind99[]: [.programlisting] .... CONFLICTS_INSTALL= bind910 .... И добавьте в [.filename]#Makefile# пакета package:dns/bind910[]: [.programlisting] .... CONFLICTS_INSTALL= bind99 .... ==== Иногда только определённые версии другого порта несовместимы. В этом случае используйте полное имя пакета, включая версию. При необходимости используйте подстановочные символы шаблонов имён файлов оболочки, такие как `*` и `?`, чтобы охватить все необходимые версии. [[conflicts-ex2]] .Использование `CONFLICTS*` с шаблонами имён файлов. [example] ==== В версиях с 2.0 по 2.4.1_2 пакет package:deskutils/gnotime[] устанавливал встроенную версию пакета package:databases/qof[]. Чтобы отразить это прошлое, [.filename]#Makefile# пакета package:databases/qof[] содержит: [.programlisting] .... 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`. package:deskutils/gnotime[] не имеет строки конфликтов, потому что его текущая версия не конфликтует ни с чем другим. ==== Переменная `DISABLE_CONFLICTS` может быть временно установлена при выполнении целей, на которые не влияют конфликты. Эту переменную не следует устанавливать в Makefiles портов. [source, shell] .... % make -DDISABLE_CONFLICTS patch .... [[install]] == Установка файлов [IMPORTANT] ==== Фаза `install` очень важна для конечного пользователя, так как она добавляет файлы в его систему. Все дополнительные команды, выполняемые в целях `*-install` [.filename]#Makefile# порта, должны выводиться на экран. _Не_ заглушайте эти команды с помощью `@` или `.SILENT`. ==== [[install-macros]] === Макросы `INSTALL_*` Используйте макросы, предоставленные в [.filename]#bsd.port.mk#, чтобы обеспечить корректные режимы файлов в целях `*-install` порта. Устанавливайте владельца напрямую в [.filename]#pkg-plist# в соответствующих записях, таких как `@(_владелец_,_группа_,)`, `@owner _владелец_` и `@group _группа_`. Эти операторы действуют до переопределения или до конца [.filename]#pkg-plist#, поэтому не забудьте сбросить их, когда они больше не нужны. Владелец по умолчанию — `root:wheel`. Дополнительную информацию см. в crossref:plist[plist-keywords-base,Базовые Ключевые Слова]. * `INSTALL_PROGRAM` — команда для установки бинарных исполняемых файлов. * `INSTALL_SCRIPT` — команда для установки исполняемых скриптов. * `INSTALL_LIB` — это команда для установки общих библиотек (но не статических библиотек). * `INSTALL_KLD` — это команда для установки загружаемых модулей ядра. Некоторые архитектуры не поддерживают удаление символов из модулей, поэтому используйте эту команду вместо `INSTALL_PROGRAM`. * `INSTALL_DATA` — это команда для установки общих данных, включая статические библиотеки. * `INSTALL_MAN` — это команда для установки man-страниц и другой документации (она ничего не сжимает). Эти переменные передаются команде man:install[1] с соответствующими флагами для каждой ситуации. [IMPORTANT] ==== Не используйте `INSTALL_LIB` для установки статических библиотек, так как их удаление делает их бесполезными. Вместо этого используйте `INSTALL_DATA`. ==== [[install-strip]] === Удаление символов из бинарных файлов и разделяемых библиотек Установленные бинарные файлы должны быть очищены от отладочной информации. Не очищайте бинарные файлы вручную, если это не является абсолютно необходимым. Макрос `INSTALL_PROGRAM` устанавливает и очищает бинарный файл одновременно. Макрос `INSTALL_LIB` делает то же самое с разделяемыми библиотеками. Когда файл необходимо очистить, но ни макросы `INSTALL_PROGRAM`, ни `INSTALL_LIB` не подходят, `${STRIP_CMD}` очищает программу или разделяемую библиотеку. Обычно это делается в цели `post-install`. Например: [.programlisting] .... post-install: ${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/xdl .... Когда необходимо удалить отладочную информацию из нескольких файлов: [.programlisting] .... post-install: .for l in geometry media body track world ${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/lib${PORTNAME}-${l}.so.0 .endfor .... Используйте man:file[1] для файла, чтобы определить, был ли он подвергнут удалению символов. man:file[1] сообщает, что бинарные файлы либо `stripped` (удалены символы), либо `not stripped` (символы не удалены). Кроме того, man:strip[1] обнаружит программы, которые уже были подвергнуты удалению символов, и завершит работу без ошибок. [IMPORTANT] ==== Когда определён `WITH_DEBUG`, elf-файлы _не должны_ быть очищены. Переменные (`STRIP_CMD`, `INSTALL_PROGRAM`, `INSTALL_LIB`, ...) и crossref:uses[uses,`USES`], предоставляемые фреймворком, обрабатывают это автоматически. Некоторое программное обеспечение добавляет `-s` к своим `LDFLAGS`. В этом случае либо удалите `-s`, если установлен `WITH_DEBUG`, либо удалите его безусловно и используйте `STRIP_CMD` в `post-install`. ==== [[install-copytree]] === Установка целого дерева файлов Иногда необходимо установить большое количество файлов с сохранением их иерархической структуры. Например, копирование всего дерева каталогов из `WRKSRC` в целевой каталог под `PREFIX`. Обратите внимание, что `PREFIX`, `EXAMPLESDIR`, `DATADIR` и другие переменные путей всегда должны предваряться `STAGEDIR` для соблюдения процедуры промежуточной установки (см. crossref:special[staging,Промежуточная установка]). Для этой ситуации существуют два макроса. Преимущество использования этих макросов вместо `cp` заключается в том, что они гарантируют целевым файлам правильные значения владельца и разрешений. Первый макрос, `COPYTREE_BIN`, устанавливает все установленные файлы как исполняемые, что делает его подходящим для установки в [.filename]#PREFIX/bin#. Второй макрос, `COPYTREE_SHARE#, не устанавливает исполняемые разрешения для файлов и, следовательно, подходит для установки файлов в [.filename]#PREFIX/share#. [.programlisting] .... post-install: ${MKDIR} ${STAGEDIR}${EXAMPLESDIR} (cd ${WRKSRC}/examples && ${COPYTREE_SHARE} . ${STAGEDIR}${EXAMPLESDIR}) .... Этот пример установит содержимое каталога [.filename]#examples# из дистрибутива вендора в соответствующее расположение примеров порта. [.programlisting] .... post-install: ${MKDIR} ${STAGEDIR}${DATADIR}/summer (cd ${WRKSRC}/temperatures && ${COPYTREE_SHARE} "June July August" ${STAGEDIR}${DATADIR}/summer) .... И этот пример установит данные летних месяцев в подкаталог [.filename]#summer# каталога [.filename]#DATADIR#. Дополнительные аргументы `find` могут быть переданы через третий аргумент макросов `COPYTREE_*`. Например, чтобы установить все файлы из первого примера, кроме Makefiles, можно использовать следующие команды. [.programlisting] .... post-install: ${MKDIR} ${STAGEDIR}${EXAMPLESDIR} (cd ${WRKSRC}/examples && \ ${COPYTREE_SHARE} . ${STAGEDIR}${EXAMPLESDIR} "! -name Makefile") .... Эти макросы не добавляют установленные файлы в [.filename]#pkg-plist#. Их необходимо добавлять вручную. Для дополнительной документации (`PORTDOCS`, см. crossref:makefiles[install-documentation, Установка дополнительной документации]) и примеров (`PORTEXAMPLES`), префиксы `%%PORTDOCS%%` или `%%PORTEXAMPLES%%` должны быть добавлены в [.filename]#pkg-plist#. [[install-documentation]] === Установка дополнительной документации Если у программного обеспечения есть документация, помимо стандартных страниц man и info, которая может быть полезна пользователю, установите её в `DOCSDIR`. Это можно сделать, как и в предыдущем пункте, в цели `post-install`. Создайте новый каталог для порта. Имя каталога — `DOCSDIR`. Обычно оно равно `PORTNAME`. Однако, если пользователю может потребоваться установка разных версий порта одновременно, можно использовать полное имя `PKGNAME`. Поскольку устанавливаются только файлы, перечисленные в [.filename]#pkg-plist#, можно безопасно всегда устанавливать документацию в `STAGEDIR` (см. crossref:special[staging,Staging]). Поэтому блоки `.if` требуются только в тех случаях, когда устанавливаемые файлы достаточно велики, чтобы вызвать значительные накладные расходы на ввод-вывод. [.programlisting] .... post-install: ${MKDIR} ${STAGEDIR}${DOCSDIR} ${INSTALL_DATA} ${WRKSRC}/docs/xvdocs.ps ${STAGEDIR}${DOCSDIR} .... С другой стороны, если в порте есть опция DOCS, установите документацию в цели `post-install-DOCS-on`. Эти цели описаны в crossref:makefiles[options-targets, Дополнительные цели сборки, `_target_-_OPT_-on` и `_target_-_OPT_-off`]. Вот несколько полезных переменных и их стандартное раскрытие при использовании в [.filename]#Makefile#: * `DATADIR` раскрывается в [.filename]#PREFIX/share/PORTNAME#. * `DATADIR_REL` раскрывается в [.filename]#share/PORTNAME#. * `DOCSDIR` раскрывается в [.filename]#PREFIX/share/doc/PORTNAME#. * `DOCSDIR_REL` раскрывается в [.filename]#share/doc/PORTNAME#. * `EXAMPLESDIR` раскрывается в [.filename]#PREFIX/share/examples/PORTNAME#. * `EXAMPLESDIR_REL` раскрывается в [.filename]#share/examples/PORTNAME#. [NOTE] ==== Опция `DOCS` управляет только дополнительной документацией, устанавливаемой в `DOCSDIR`. Она не применяется к стандартным man-страницам и info-страницам. Содержимое, устанавливаемое в `EXAMPLESDIR`, контролируется опцией `EXAMPLES`. ==== Эти переменные экспортируются в `PLIST_SUB`. Их значения будут представлены там в виде путей относительно [.filename]#PREFIX#, если это возможно. То есть, [.filename]#share/doc/PORTNAME# будет заменено на `%%DOCSDIR%%` в списке упаковки по умолчанию и так далее. (Подробнее о подстановках в [.filename]#pkg-plist# см. crossref:plist[plist-sub,здесь].) Все условно устанавливаемые файлы и каталоги документации включаются в [.filename]#pkg-plist# с префиксом `%%PORTDOCS%%`, например: [.programlisting] .... %%PORTDOCS%%%%DOCSDIR%%/AUTHORS %%PORTDOCS%%%%DOCSDIR%%/CONTACT .... В качестве альтернативы перечислению файлов документации в [.filename]#pkg-plist#, порт может установить переменную `PORTDOCS` в список имён файлов и шаблонов имён файлов shell для добавления в итоговый список упаковки. Имена будут относительны к `DOCSDIR`. Поэтому порт, использующий `PORTDOCS` и нестандартное расположение документации, должен соответствующим образом установить `DOCSDIR`. Если в `PORTDOCS` указан каталог или он соответствует шаблону из этой переменной, всё поддерево содержащихся файлов и каталогов будет зарегистрировано в итоговом списке упаковки. Если опция `DOCS` отключена, файлы и каталоги, перечисленные в `PORTDOCS`, не будут установлены или добавлены в список упаковки порта. Установка документации в `PORTDOCS`, как показано выше, остаётся на усмотрение самого порта. Типичный пример использования `PORTDOCS`: [.programlisting] .... PORTDOCS= README.* ChangeLog docs/* .... [NOTE] ==== Эквивалентами `PORTDOCS` для файлов, установленных в `DATADIR` и `EXAMPLESDIR`, являются `PORTDATA` и `PORTEXAMPLES` соответственно. Содержимое файла [.filename]#pkg-message# отображается при установке. Подробности см. в разделе crossref:pkg-files[porting-message,использование файла [.filename]#pkg-message#]. Файл [.filename]#pkg-message# не нужно добавлять в [.filename]#pkg-plist#. ==== [[install-subdirs]] === Подкаталоги в `PREFIX` Попробуйте сделать так, чтобы порт размещал файлы в правильных подкаталогах `PREFIX`. Некоторые порты собирают всё в кучу и помещают в подкаталог с именем порта, что неверно. Также многие порты размещают все файлы, кроме бинарников, заголовочных файлов и страниц руководства, в подкаталоге [.filename]#lib#, что плохо согласуется с парадигмой BSD. Многие из этих файлов должны быть перемещены в один из следующих каталогов: [.filename]#etc# (файлы настройки/конфигурации), [.filename]#libexec# (исполняемые файлы для внутреннего использования), [.filename]#sbin# (исполняемые файлы для суперпользователей/администраторов), [.filename]#info# (документация для браузера info) или [.filename]#share# (архитектурно-независимые файлы). Подробности см. в man:hier[7]; правила, действующие для [.filename]#/usr#, в основном применимы и к [.filename]#/usr/local#. Исключение составляют порты, связанные с USENET "news". Они могут использовать [.filename]#PREFIX/news# в качестве места назначения для своих файлов. [[binary-alias]] == Использование `BINARY_ALIAS` для переименования команд вместо исправления сборки Когда определена переменная `BINARY_ALIAS`, будут созданы символьные ссылки на указанные команды в каталоге, который будет добавлен в начало переменной `PATH`. Используйте это для замены жёстко заданных команд, от которых зависит этап сборки, без необходимости исправлять какие-либо файлы сборки. [[binary-alias-ex1]] .Использование `BINARY_ALIAS` для предоставления `gsed` в качестве `sed` [example] ==== Некоторые порты ожидают, что `sed` будет вести себя как GNU sed и используют возможности, которые man:sed[1] не предоставляет. GNU sed доступен в пакете package:textproc/gsed[] на FreeBSD. Используйте `BINARY_ALIAS` для замены `sed` на `gsed` на время сборки: [.programlisting] .... BUILD_DEPENDS= gsed:textproc/gsed ... BINARY_ALIAS= sed=gsed .... ==== [[binary-alias-ex2]] .Использование `BINARY_ALIAS` для создания псевдонимов жёстко заданных команд `python3` [example] ==== Порт, в котором есть жёсткая ссылка на `python3` в скриптах сборки, требует его наличия в `PATH` во время сборки. Используйте `BINARY_ALIAS` для создания псевдонима, указывающего на нужный бинарный файл Python 3: [.programlisting] .... USES= python:3.4+,build ... BINARY_ALIAS= python3=${PYTHON_CMD} .... См. crossref:special[using-python,Использование Python] для получения дополнительной информации о `USES=python`. ==== [NOTE] ==== Бинарные псевдонимы создаются после обработки зависимостей, указанных через `BUILD_DEPENDS` и `LIB_DEPENDS`, но до цели `configure`. Это приводит к различным ограничениям. Например, программы, установленные через `TEST_DEPENDS`, нельзя использовать для создания бинарного псевдонима, так как тестовые зависимости, указанные таким образом, обрабатываются после создания бинарных псевдонимов. ====