path: root/documentation/content/pt-br/books/porters-handbook/makefiles/_index.adoc

---
title: Capítulo 5. Configurando o Makefile
prev: books/porters-handbook/slow-porting
next: books/porters-handbook/special
showBookMenu: true
weight: 5
path: "/books/porters-handbook/"
---

[[makefiles]]
= Configurando o Makefile
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:sectnumoffset: 5
:partnums:
:source-highlighter: rouge
:experimental:
: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::[]

Configurar o [.filename]#Makefile# é bastante simples e, novamente, sugerimos examinar os exemplos existentes antes de começar. Além disso, há um <<porting-samplem,Makefile de exemplo>> neste manual, então dê uma olhada e por favor siga a ordem das variáveis ​​e seções naquele modelo para tornar o port mais fácil para os outros lerem.

Considere estes problemas em sequência durante o projeto do novo [.filename]#Makefile#:

[[makefile-source]]
== O Código Fonte Original

Ele está em `DISTDIR` como um tarball `gzip` e é chamado de algo como [.filename]#foozolix-1.2.tar.gz#? Se assim for, vá para o próximo passo. Caso contrário, o formato do arquivo de distribuição pode necessitar da substituição de uma ou mais das variáveis `DISTVERSION`, `DISTNAME`, `EXTRACT_CMD`, `EXTRACT_BEFORE_ARGS`, `EXTRACT_AFTER_ARGS`, `EXTRACT_SUFX` ou `DISTFILES`.

Na pior das hipóteses, crie um target personalizado `do-extract` para substituir o padrão. Isso raramente é necessário.

[[makefile-naming]]
=== Nomeando

A primeira parte do [.filename]#Makefile# do port o nomeia, descreve seu número de versão e o lista na categoria correta.

[[makefile-portname]]
=== `PORTNAME`

Setar `PORTNAME` ao nome base do software. Isso é usado como base para o pacote do FreeBSD, e para o <<makefile-distname,`DISTNAME`>>.

[IMPORTANT]
====
O nome do pacote deve ser único em toda a árvore de ports. Certifique-se de que o `PORTNAME` já não está em uso por um port existente, e que nenhum outro port já tem o mesmo `PKGBASE`. Se o nome já tiver sido usado, adicione <<porting-pkgnameprefix-suffix,`PKGNAMEPREFIX` ou `PKGNAMESUFFIX`>>.
====

[[makefile-versions]]
=== Versões, `DISTVERSION` ou `PORTVERSION`

Setar `DISTVERSION` para o número da versão do software.

`PORTVERSION` é a versão usada para o pacote do FreeBSD. Será automaticamente derivado de `DISTVERSION` para ser compatível com o esquema de versionamento de pacotes do FreeBSD. Se a versão contiver _letras_, pode ser necessário definir `PORTVERSION` e não `DISTVERSION`.

[IMPORTANT]
====
Não é possível utilizar `PORTVERSION` e `DISTVERSION` juntos, deve ser ser definido um de cada vez.
====

De tempos em tempos, alguns softwares usam um esquema de versão que não é compatível em como o `DISTVERSION` traduz a versão no `PORTVERSION`.

[TIP]
====

Ao atualizar um port, é possível usar o man:pkg-version[8]`-t` para verificar se a nova versão é maior ou menor do que antes. Veja <<makefile-versions-ex-pkg-version>>.
====

[[makefile-versions-ex-pkg-version]]
.Usando man:pkg-version[8] para comparar versões.
[example]
====
`pkg version -t` recebe duas versões como argumentos, responderá com `<`, `=` ou `>` se a primeira versão for menor, igual ou maior que a segunda versão, respectivamente.

[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`  é menor que `1.3`.
<.> `1.2`  e `1.2` são iguais, pois têm a mesma versão.
<.> `1.2`  e `1.2.0` são iguais, pois valor vazio é igual a zero.
<.> `1.2`  é maior que `1.2.p1` por causa do `.p1`, pense em "pre-release 1".
<.> `1.2.a1`  é menor que `1.2.b1`, pense em "alfa" e "beta" e `a` é menor que `b`.
<.> `1.2`  é menor que `1.2p1` por causa do `2p1`, pense em "2, nível de patch 1" que é uma versão depois de qualquer `2.X` mas antes de `3`.

[NOTE]
======
Aqui, `a`, `b` e `p` são usados ​​como se significassem "alfa", "beta" ou "pre-release" e "nível de patch", mas elas são apenas letras e são classificados por ordem alfabética, portanto, qualquer letra pode ser utilizada, e elas serão ordenadas de forma adequada.
======

====

.Exemplos de `DISTVERSION` e de Derivações `PORTVERSION`
[cols="1,1", 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]]
.Usando `DISTVERSION`
[example]
====
Quando a versão contém apenas números separados por pontos, traços ou sublinhados, use `DISTVERSION`.

[.programlisting]
....
PORTNAME=   nekoto
DISTVERSION=	1.2-4
....

Isso irá gerar um `PORTVERSION 1.2.4`.
====

[[makefile-versions-ex2]]
.Usando `DISTVERSION` Quando a Versão Começa com uma Letra ou um Prefixo
[example]
====
Quando a versão começa ou termina com uma letra, um prefixo ou um sufixo que não faz parte da versão, use `DISTVERSIONPREFIX`, `DISTVERSION` e `DISTVERSIONSUFFIX`.

Se a versão for `v1.2-4`:

[.programlisting]
....
PORTNAME=   nekoto
DISTVERSIONPREFIX=  v
DISTVERSION=	1_2_4
....

Algumas vezes, projetos usando GitHub usará seu nome em suas versões. Por exemplo, a versão pode ser `nekoto-1.2-4`:

[.programlisting]
....
PORTNAME=   nekoto
DISTVERSIONPREFIX=  nekoto-
DISTVERSION=	1.2_4
....

Esses projetos também usam algumas strings no final da versão, por exemplo,`1.2-4_RELEASE`:

[.programlisting]
....
PORTNAME=   nekoto
DISTVERSION=	1.2-4
DISTVERSIONSUFFIX=  _RELEASE
....

Ou eles fazem ambos, por exemplo,`nekoto-1.2-4_RELEASE`:

[.programlisting]
....
PORTNAME=   nekoto
DISTVERSIONPREFIX=  nekoto-
DISTVERSION=	1.2-4
DISTVERSIONSUFFIX=  _RELEASE
....

`DISTVERSIONPREFIX` e `DISTVERSIONSUFFIX` não serão usados durante a construção do `PORTVERSION`, mas usado apenas em `DISTNAME`.

Todos exemplos irão gerar um `PORTVERSION` com valor `1.2.4`.
====

[[makefile-versions-ex3]]
.Usando `DISTVERSION` Quando a Versão Contém Letras Significando "alpha", "beta" ou "pre-release"
[example]
====
Quando a versão contém números separados por pontos, traços ou underlines, e letras são usadas para significar "alpha", "beta" ou "pre-release", no sentido de que vem antes das versões sem letras, use `DISTVERSION`.

[.programlisting]
....
PORTNAME=   nekoto
DISTVERSION=	1.2-pre4
....

[.programlisting]
....
PORTNAME=   nekoto
DISTVERSION=	1.2p4
....

Ambos irão gerar um `PORTVERSION` com valor `1.2.p4` que é menor do que 1.2. man:pkg-version[8] pode ser usado para verificar esse fato:

[source,shell]
....
% pkg version -t 1.2.p4 1.2
<
....

====

[[makefile-versions-ex4]]
.Não use `DISTVERSION` Quando a Versão Contém Letras que Significam "Nível de Patch"
[example]
====
Quando a versão contém letras que não significam "alpha", "beta" ou "pre", e estão mais para um "nível de patch", no sentido de que vem depois da versão sem as letras, use `PORTVERSION`.

[.programlisting]
....
PORTNAME=   nekoto
PORTVERSION=	1.2p4
....

Neste caso, usar `DISTVERSION` não é possível porque geraria uma versão `1.2.p4` o que seria menor que `1.2` e não maior.man:pkg-version[8] irá constatar isso:

[source,shell]
....
% pkg version -t 1.2 1.2.p4
> <.>
% pkg version -t 1.2 1.2p4
< <.>
....

<.> `1.2` é maior que `1.2.p4`, o que é _errado_ nesse caso.
<.> `1.2` é menor que `1.2p4`, que é o que era necessário.
====

Para alguns exemplos mais avançados de configuração do `PORTVERSION`, quando a versão do software não é realmente compatível com o FreeBSD, ou `DISTNAME` quando o arquivo de distribuição não contém a versão em si, consulte <<makefile-distname>>.

[[makefile-naming-revepoch]]
=== `PORTREVISION` e `PORTEPOCH`

[[makefile-portrevision]]
==== `PORTREVISION`

`PORTREVISION` é um valor monotonicamente crescente que é redefinido para 0 com cada incremento de `DISTVERSION`, normalmente toda vez que houver uma nova versão oficial do fornecedor. E se `PORTREVISION` é diferente de zero, o valor é anexado ao nome do pacote. Mudanças em `PORTREVISION` são usadas ​​por ferramentas automatizadas como man:pkg-version[8] para determinar se um novo pacote está disponível.

`PORTREVISION` deve ser incrementado toda vez que uma alteração for feita no port onde se altera o pacote gerado de alguma forma. Isso inclui alterações que afetam apenas um pacote compilado com <<makefile-options,options>> não padrão.

Exemplos de quando `PORTREVISION` deve ser alterado:

* Adição de correções para corrigir vulnerabilidades de segurança, bugs ou para adicionar novas funcionalidades ao port.
* Alterações no [.filename]#Makefile# do port para ativar ou desativar as opções de tempo de compilação no pacote.
* Alterações na lista de empacotamento ou no comportamento de tempo de instalação do pacote. Por exemplo, uma alteração em um script que gera dados iniciais para o pacote, como chaves de host man:ssh[1].
* Bump de versão da dependência de biblioteca compartilhada de um port (nesse caso, alguém tentando instalar o pacote antigo depois de instalar uma versão mais nova da dependência falhará, pois procurará a libfoo.x antiga em vez da libfoo.(x+1)).
* Mudanças silenciosas no distfile do port que possuem diferenças funcionais significativas. Por exemplo, mudanças no distfile que requerem uma correção para [.filename]#distinfo# sem alteração correspondente para `DISTVERSION`, onde um `diff -ru` das versões antiga e nova mostra mudanças não triviais no código.

Exemplos de alterações que não requerem uma alteração no `PORTREVISION`:

* Mudanças de estilo no esqueleto do port sem alteração funcional ao que aparece no pacote resultante.
* Mudanças para `MASTER_SITES` ou outras alterações funcionais no port que não afetem o pacote resultante.
* Patches triviais para o distfile, como correção de erros de digitação, que não são importantes o suficiente para que os usuários do pacote tenham que se dar ao trabalho de atualizar.
* Correções de compilação que fazem com que um pacote se torne compilável onde antes estava falhando. Desde que as alterações não introduzam nenhuma mudança funcional em nenhuma outra plataforma na qual o port tenha sido compilado anteriormente. `PORTREVISION` reflete o conteúdo do pacote, se o pacote não foi compilado anteriormente, então não há necessidade de incrementar o `PORTREVISION` para registrar uma mudança.

Uma regra geral é decidir se a mudança em um port é algo que _algumas_ pessoas se beneficiariam em ter. Por causa de um aprimoramento, conserto ou em virtude de que o novo pacote funcione de fato. Em seguida, pondere que, de fato, isso fará com que todos que regularmente atualizam sua árvore de ports sejam obrigados a atualiza-lo. Se sim, `PORTREVISION` deve ser incrementado.

[NOTE]
====
Pessoas usando pacotes binários _nunca_ verão a atualização se `PORTREVISION` não for incrementado. Sem incrementar `PORTREVISION`, os package builders não têm como detectar a alteração e, portanto, não irão recompilar o pacote.
====

[[makefile-portepoch]]
==== `PORTEPOCH`

De tempos em tempos, um fornecedor de software ou um mantenedor de port do FreeBSD fazem algo tolo e lançam uma versão de seu software que é numericamente menor que a versão anterior. Um exemplo disso é um port que vai de foo-20000801 para foo-1.0 ( o primeiro será incorretamente tratado como uma versão mais nova, já que 20000801 é um valor numericamente maior que 1).

[TIP]
====

Os resultados das comparações de números de versão nem sempre são óbvios. `pkg version` (veja man:pkg-version[8]) pode ser usado para testar a comparação de duas sequências de números de versão. Por exemplo:

[source,shell]
....
% pkg version -t 0.031 0.29
>
....

A saida `>` indica que a versão 0.031 é considerada maior que a versão 0.29, o que pode não ter sido óbvio para o mantenedor do port.
====

Em situações como essa, `PORTEPOCH` deve ser incrementado. E se `PORTEPOCH` é diferente de zero, ele é anexado ao nome do pacote conforme descrito na seção 0 acima. `PORTEPOCH` nunca deve ser diminuído ou redefinido para zero, porque isso faria com que a comparação com um pacote de uma época anterior falhasse. Por exemplo, o pacote não seria detectado como desatualizado. O novo número da versão, `1.0.1` no exemplo acima, ainda é numericamente menor que a versão anterior, 20000801, mas o sufixo `1` é tratado especialmente por ferramentas automatizadas e considerado maior que o sufixo `0` implícito no pacote anterior.

Remover ou resetar o `PORTEPOCH` incorretamente conduz ao luto eterno. Se a discussão acima não foi clara o suficiente, por favor consulte a http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports[ Lista de discussão de ports do FreeBSD].

É esperado que `PORTEPOCH` não seja utilizado na maioria dos ports, e que seja feito o uso sensato do `DISTVERSION`, ou que o `PORTVERSION` seja usado com cuidado também, isso muitas vezes pode evitar que uma versão futura do software altere a estrutura da versão. No entanto, é necessário que os porters do FreeBSD tenham cuidado quando uma versão do fornecedor é feita sem um número de versão oficial - como um código de release "snapshot". A tentação é rotular a release com a data de lançamento, o que causará problemas como no exemplo acima, quando um novo release "oficial" é feito.

Por exemplo, se um snapshot de release é feito na data `20000917` e a versão anterior do software era a versão `1.2`, não use `20000917` no `DISTVERSION`. A maneira correta é um `DISTVERSION` com valor `1.2.20000917`, ou similar, para que a próxima versão, digamos `1.3`, ainda seja um valor numericamente maior.

[[makefile-portrevision-example]]
==== Exemplo de Uso `PORTREVISION` e `PORTEPOCH`

O port `gtkmumble`, versão `0.10` está comitado na coleção de ports:

[.programlisting]
....
PORTNAME=	gtkmumble
DISTVERSION=	0.10
....

`PKGNAME` torna-se `gtkmumble-0.10`.

Uma falha de segurança é descoberta, o que requer um patch local do FreeBSD. `PORTREVISION` é alterado de acordo.

[.programlisting]
....
PORTNAME=	gtkmumble
DISTVERSION=	0.10
PORTREVISION=	1
....

`PKGNAME` torna-se `gtkmumble-0.10_1`

Uma nova versão é lançada pelo fornecedor, numerada como `0.2` (acontece que o autor realmente pretendia que `0.10` significa-se realmente `0.1.0`, não "o que vem depois de 0.9" - oops, tarde demais agora). Como a nova versão secundária `2` é numericamente menor que a versão anterior `10`, `PORTEPOCH` deve ser incrementado para forçar manualmente que o novo pacote seja detectado como "mais recente". Como é uma nova versão do fornecedor, `PORTREVISION` é redefinido para 0 (ou removido do [.filename]#Makefile#).

[.programlisting]
....
PORTNAME=	gtkmumble
DISTVERSION=	0.2
PORTEPOCH=	1
....

`PKGNAME` torna-se `gtkmumble-0.2,1`

O próximo lançamento é 0.3. Desde que `PORTEPOCH` nunca diminua, as variáveis ​​de versão são agora:

[.programlisting]
....
PORTNAME=	gtkmumble
DISTVERSION=	0.3
PORTEPOCH=	1
....

`PKGNAME` torna-se `gtkmumble-0.3,1`

[NOTE]
====
E se `PORTEPOCH` for redefinido para `0` com esta atualização, alguém que instalou o `gtkmumble-0.10_1` não detectaria o `gtkmumble-0.3` como pacote mais novo, desde que `3` ainda é numericamente menor que `10`. Lembre-se, este é o ponto principal de `PORTEPOCH` em primeiro lugar.
====

[[porting-pkgnameprefix-suffix]]
=== `PKGNAMEPREFIX` e `PKGNAMESUFFIX`

Duas variáveis ​​opcionais, `PKGNAMEPREFIX` e `PKGNAMESUFFIX`, são combinadas com `PORTNAME` e `PORTVERSION` para formar `PKGNAME` como `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Certifique-se de que isto está de acordo com as nossas <<porting-pkgname,diretrizes para um bom nome de pacote>>. Em particular, o uso de um hífen (`-`) dentro de `PORTVERSION` _não é_ permitido. Além disso, se o nome do pacote tiver o _language-_ ou a parte _-compiled.specifics_ (veja abaixo), use `PKGNAMEPREFIX` e `PKGNAMESUFFIX`, respectivamente. Não os faça parte de `PORTNAME`.

[[porting-pkgname]]
=== Convenções de Nomenclatura de Pacotes

Estas são as convenções a serem seguidas ao nomear pacotes. Isso é para facilitar a varredura do diretório de pacotes, já que existem milhares de pacotes e os usuários irão pegar ranço se eles machucarem seus olhos!

Nomes de pacotes tomam a forma de [.filename]#language_region-name-compiled.specifics-version.numbers#.

O nome do pacote é definido como `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Certifique-se de definir as variáveis ​​para estar em conformidade com esse formato.

[[porting-pkgname-language]]
[.filename]#language_region-#::
O FreeBSD se esforça para suportar a linguagem nativa de seus usuários. A parte _language-_ é uma abreviação de duas letras da linguagem natural definida pela ISO-639 quando o port é específico para um determinado idioma. Exemplos são `ja` para japonês, `ru` para russo,`vi` para vietnamita, `zh` para o chinês, `ko` para coreano e `de` para alemão.
+
Se o port for específico de uma determinada região dentro da área de idioma, adicione também o código do país de duas letras. Exemplos são `en_US` para Inglês dos EUA e `fr_CH` para o Francês Suíço.
+
A parte _language-_ é definida em `PKGNAMEPREFIX`.

[[porting-pkgname-name]]
[.filename]#name#::
Certifique-se de que o nome e a versão do port estejam claramente separados e colocados em `PORTNAME` e `DISTVERSION`. A única razão para `PORTNAME` conter uma parte da versão é se a distribuição upstream é realmente chamada dessa forma, como no package:textproc/libxml2[] ou package:japanese/kinput2-freewnn[]. De outra forma, `PORTNAME` não pode conter informações específicas da versão. É normal que vários ports tenham o mesmo `PORTNAME`, como os ports package:www/apache*[] fazem; Nesse caso, versões diferentes (e entradas de índice diferentes) são distinguidas por valores `PKGNAMEPREFIX` e `PKGNAMESUFFIX`.
+
Há uma tradição de nomear módulos `Perl 5` com sufixo `p5-` e convertendo o separador de dois pontos para um hífen. Por exemplo, o modulo `Data::Dumper` torna-se `p5-Data-Dumper`.

[[porting-pkgname-compiled-specifics]]
[.filename]#-compiled.specifics#::
Se o port pode ser construído com diferentes <<makefile-masterdir,padrões codificados>> (geralmente parte do nome do diretório em uma família de ports), a parte _-compiled.specifics_ indica os padrões compilados. O hífen é opcional. Exemplos são tamanho de papel e unidades de fonte.
+
A parte _-compiled.specifics_ é definida em `PKGNAMESUFFIX`.

[[porting-pkgname-version-numbers]]
[.filename]#-version.numbers#::
A string da versão segue um hífen (`-`) e é uma lista separada por pontos de números inteiros e letras minúsculas. Em particular, não é permitido ter outro hífen dentro da string de versão. A única exceção é a string `pl` (significando "patchlevel"), que pode ser usado _apenas_ quando não há números de versão maiores e menores no software. Se a versão do software tiver sequências como "alpha", "beta", "rc" ou "pre", use a primeira letra e coloque imediatamente após um ponto. Se a sequência da versão continuar após esses nomes, os números seguirão o alfabeto simples sem um ponto extra entre eles (por exemplo,`1.0b2`).
+
A ideia é facilitar a classificação dos ports observando a string de versão. Em particular, certifique-se de que os componentes do número da versão estejam sempre delimitados por um ponto e, se a data fizer parte da string, use o formato `dyyyy.mm.dd`, não `dd.mm.yyyy` ou o não compatível com o formato Y2K `yy.mm.dd`. É importante prefixar a versão com uma letra, aqui `d` (para data), no caso de uma versão com um número de versão real, que seria numericamente inferior a `_yyyy_`.

[IMPORTANT]
====
O nome do pacote deve ser único entre todos os ports, verifique se ainda não existe um port com o mesmo `PORTNAME` e se houver, adicione um dos <<porting-pkgnameprefix-suffix,`PKGNAMEPREFIX` ou `PKGNAMESUFFIX`>>.
====

Aqui estão alguns exemplos (reais) de como converter o nome como chamado pelos autores do software para um nome de pacote adequado, para cada linha, apenas um dos `DISTVERSION` ou `PORTVERSION` está definido, dependendo de qual seria usado no [.filename]#Makefile#:

.Exemplos de Nomes de Pacotes
[cols="1,1,1,1,1,1,1", frame="none", options="header"]
|===
| Nome da Distribuição
| PKGNAMEPREFIX
| PORTNAME
| PKGNAMESUFFIX
| DISTVERSION
| PORTVERSION
| Razão ou comentário

|mule-2.2.2
|(vazio)
|mule
|(vazio)
|2.2.2
|
|Nenhuma alteração é necessária

|mule-1.0.1
|(vazio)
|mule
|1
|1.0.1
|
|Esta é a versão 1 do mule e a versão 2 já existe

|EmiClock-1.0.2
|(vazio)
|emiclock
|(vazio)
|1.0.2
|
|Sem nomes em maiúsculas para programas individuais

|rdist-1.3alpha
|(vazio)
|rdist
|(vazio)
|1.3alfa
|
|Versão será `1.3.a`

|es-0.9-beta1
|(vazio)
|es
|(vazio)
|0.9-beta1
|
|Versão será `0.9.b1`

|mailman-2.0rc3
|(vazio)
|mailman
|(vazio)
|2.0rc3
|
|Versão será `2.0.r3`

|v3.3beta021.src
|(vazio)
|tiff
|(vazio)
|
|3.3
|O que diabos foi isso afinal?

|tvtwm
|(vazio)
|tvtwm
|(vazio)
|
|p11
|Nenhuma versão no nome do arquivo, use o que o upstream diz que é

|piewm
|(vazio)
|piewm
|(vazio)
|1.0
|
|Nenhuma versão no nome do arquivo, use o que o upstream diz que é

|xvgr-2.10pl1
|(vazio)
|xvgr
|(vazio)
|
|2.10.pl1
|Nesse caso,`pl1` significa nível de patch, então usar DISTVERSION não é possível.

|gawk-2.15.6
|ja-
|gawk
|(vazio)
|2.15.6
|
|Versão em japonês

|psutils-1.13
|(vazio)
|psutils
|-letter
|1.13
|
|Tamanho do papel codificado no tempo de compilação do pacote

|pkfonts
|(vazio)
|pkfonts
|300
|1.0
|
|Pacote para fontes de 300dpi
|===

Se não houver absolutamente nenhum rastro de informações de versão co código fonte original e é improvável que o autor original vá liberar outra versão, basta definir a string de versão para `1.0` (como o exemplo `piewm` acima). Caso contrário, pergunte ao autor original ou use a string de data com valor de quando a código fonte foi lançado como (`dyyyy.mm.dd` ou `dyyyymmdd`) como a versão.

[TIP]
====

Use qualquer letra. Aqui,`d` significa data, se o código for um repositório do Git, `g` seguido pela data de commit é normalmente utilizado, `s` para snapshot também é comum.
====

[[makefile-categories]]
== Categorização

[[makefile-categories-definition]]
=== `CATEGORIES`

Quando um pacote é criado, ele é colocado em [.filename]#/usr/ports/packages/All# e links são feitos de um ou mais subdiretórios de [.filename]#/usr/ports/packages#. Os nomes desses subdiretórios são especificados pela variável `CATEGORIES`. O objetivo é facilitar a vida do usuário quando ele estiver vasculhando a pilha de pacotes no site FTP ou no CD-ROM. Por favor, dê uma olhada na <<porting-categories,lista atual de categorias>> e escolha as que são adequadas para o port.

Esta lista também determina de onde, na árvore de ports, o port será importado. Se houver mais de uma categoria aqui, os arquivos do port devem ser colocados no subdiretório com o nome da primeira categoria. Veja <<choosing-categories,abaixo>> para mais informação sobre como escolher as categorias certas.

[[porting-categories]]
=== Lista Atual de Categorias

Aqui está a lista atual de categorias de ports. As marcadas com um asterisco (`*`) são categorias _virtuais_ - aquelas que não possuem um subdiretório correspondente na árvore de ports. Elas são usadas ​​apenas como categorias secundárias e apenas para fins de pesquisa.

[NOTE]
====
Para categorias não virtuais, há uma descrição de uma linha em `COMMENT` no [.filename]#Makefile# desse subdiretório.
====

[.informaltable]
[cols="1,1,1", frame="none", options="header"]
|===
| Categoria
| Descrição
| Notas

|[.filename]#accessibility#
|Ports para ajudar usuários com deficiências.
|

|[.filename]#afterstep# `*`
|Ports para apoiar o gerenciador de janelas http://www.afterstep.org[AfterStep].
|

|[.filename]#arabic#
|Suporte ao idioma árabe".
|

|[.filename]#archivers#
|Ferramentas de arquivamento.
|

|[.filename]#astro#
|Ports astronômicos.
|

|[.filename]#audio#
|Suporte de som.
|

|[.filename]#benchmarks#
|Utilitários de benchmarking.
|

|[.filename]#biology#
|Software relacionado à biologia.
|

|[.filename]#cad#
|Ferramentas de desenho assistidas por computador.
|

|[.filename]#chinese#
|Suporte ao idioma chinês.
|

|[.filename]#comms#
|Software de comunicação.
|Principalmente software para falar com o port serial.

|[.filename]#converters#
|Conversores de código de caracteres.
|

|[.filename]#databases#
|Bancos de dados.
|

|[.filename]#deskutils#
|Coisas que costumavam estar na área de trabalho antes dos computadores serem inventados.
|

|[.filename]#devel#
|Utilitários de desenvolvimento.
|Não coloque bibliotecas aqui só porque são bibliotecas. Elas _não deveriam_ estar nesta categoria, a menos que elas realmente não pertençam a nenhum outro lugar.

|[.filename]#dns#
|Software relacionado ao DNS.
|

|[.filename]#docs# `*`
|Meta-ports para documentação do FreeBSD.
|

|[.filename]#editors#
|Editores gerais.
|Editores especializados entram na seção para essas ferramentas. Por exemplo, um editor de fórmula matemática [.filename]#math#, e tem [.filename]#editores# como uma segunda categoria.

|[.filename]#elisp# `*`
|Emacs-lisp ports.
|

|[.filename]#emulators#
|Emuladores para outros sistemas operacionais.
|Emuladores de terminal _não_ estão aqui. Os baseados em X vão para o [.filename]#x11# e baseados em texto para qualquer [.filename]#comms# ou [.filename]#misc#, dependendo da funcionalidade exata.

|[.filename]#enlightenment# `*`
|Ports relacionados com o gerenciador de janelas Enlightenment.
|

|[.filename]#finance#
|Aplicações monetárias, financeiras e relacionadas.
|

|[.filename]#french#
|Suporte ao idioma francês.
|

|[.filename]#ftp#
|Utilitários de cliente e servidor deFTP.
|Se o port fala com FTP e HTTP, coloque-o em [.filename]#ftp# com uma categoria secundária de [.filename]#www#.

|[.filename]#games#
|Jogos.
|

|[.filename]#geography# `*`
|Software relacionado à geografia.
|

|[.filename]#german#
|Suporte ao idioma alemão.
|

|[.filename]#gnome# `*`
|Ports do Projeto http://www.gnome.org[GNOME].
|

|[.filename]#gnustep# `*`
|Software relacionado ao ambiente de desktop GNUstep.
|

|[.filename]#graphics#
|Utilitários gráficos.
|

|[.filename]#hamradio# `*`
|Software para rádio amador.
|

|[.filename]#haskell# `*`
|Software relacionado à linguagem Haskell.
|

|[.filename]#hebrew#
|Suporte ao idioma hebraico.
|

|[.filename]#hungarian#
|Suporte de idioma húngaro.
|

|[.filename]#irc#
|Utilitários do Internet Relay Chat.
|

|[.filename]#japanese#
|Suporte ao idioma japonês.
|

|[.filename]#java#
|Software relacionado à linguagem Java(TM).
|A categoria [.filename]#Java# não deve ser única para um port. Salvo para ports diretamente relacionadas à linguagem Java, os mantenedores de ports também são encorajados a não usar [.filename]#Java# como a principal categoria de um port.

|[.filename]#kde# `*`
|Ports do Projeto http://www.kde.org[KDE] (genérico).
|

|[.filename]#kde-applications# `*`
|Aplicações do Projeto http://www.kde.org[KDE].
|

|[.filename]#kde-frameworks# `*`
|Bibliotecas add-on do Projeto http://www.kde.org[KDE] para programação com Qt.
|

|[.filename]#kde-plasma# `*`
|Desktop do Projeto http://www.kde.org[KDE].
|

|[.filename]#kld# `*`
|Módulos carregáveis ​​do kernel.
|

|[.filename]#korean#
|Suporte ao idioma coreano.
|

|[.filename]#lang#
|Linguagens de programação.
|

|[.filename]#linux# `*`
|Aplicações Linux e utilitários de suporte.
|

|[.filename]#lisp# `*`
|Software relacionado à linguagem Lisp.
|

|[.filename]#mail#
|Mail software.
|

|[.filename]#mate# `*`
|Ports relacionado ao ambiente de desktop MATE, um fork do GNOME 2.
|

|[.filename]#math#
|Software de computação numérica e outras utilidades para matemática.
|

|[.filename]#mbone# `*`
|Aplicações MBone.
|

|[.filename]#misc#
|Utilitários diversos
|Coisas que não pertencem em nenhum outro lugar. Se possível, tente encontrar uma categoria melhor para o port do que `misc`, como os ports tendem a ser negligenciados aqui.

|[.filename]#multimedia#
|Software multimídia.
|

|[.filename]#net#
|Software de rede diversos.
|

|[.filename]#net-im#
|Software de mensagens instantâneas.
|

|[.filename]#net-mgmt#
|Software de gerenciamento de rede.
|

|[.filename]#net-p2p#
|Aplicativos de rede peer to peer.
|

|[.filename]#net-vpn# `*`
|Aplicativos de Rede Privada Virtual.
|

|[.filename]#news#
|Software de notícias USENET.
|

|[.filename]#parallel# `*`
|Aplicativos que lidam com o paralelismo na computação.
|

|[.filename]#pear# `*`
|Ports relacionados ao framework PHP Pear.
|

|[.filename]#perl5# `*`
|Ports que exigem Perl versão 5 para rodar.
|

|[.filename]#plan9# `*`
|Vários programas de http://www.cs.bell-labs.com/plan9dist/[Plan9].
|

|[.filename]#polish#
|Suporte ao idioma polonês".
|

|[.filename]#ports-mgmt#
|Ports para gerenciar, instalar e desenvolver ports e pacotes do FreeBSD.
|

|[.filename]#portuguese#
|Suporte ao idioma Português.
|

|[.filename]#print#
|Software de Impressão.
|As ferramentas de editoração eletrônica (pré-visualizadores etc.) também pertencem aqui.

|[.filename]#python# `*`
|Software relacionado a linguagem http://www.python.org/[Python].
|

|[.filename]#ruby# `*`
|Software relacionado a linguagem http://www.ruby-lang.org/[Ruby].
|

|[.filename]#rubygems# `*`
|Ports de pacotes http://www.rubygems.org/[RubyGems].
|

|[.filename]#russian#
|Suporte de idioma russo.
|

|[.filename]#scheme# `*`
|Software relacionado à linguagem Scheme.
|

|[.filename]#science#
|Ports científicos que não se encaixam em outras categorias, como [.filename]#astro#, [.filename]#biologia# e [.filename]#matemática#.
|

|[.filename]#security#
|Utilitários de segurança.
|

|[.filename]#shells#
|Linha de comando do shell.
|

|[.filename]#spanish# `*`
|Suporte ao idioma espanhol.
|

|[.filename]#sysutils#
|Utilidades do sistema.
|

|[.filename]#tcl# `*`
|Ports que usam o Tcl para rodar.
|

|[.filename]#textproc#
|Utilitários de processamento de texto.
|Não inclui ferramentas de editoração eletrônica, que vão para [.filename]#print#.

|[.filename]#tk# `*`
|Ports que usam o Tk para rodar.
|

|[.filename]#ukrainian#
|Suporte de idioma Ucraniano.
|

|[.filename]#vietnamese#
|Suporte de idioma Vietnamita.
|

|[.filename]#wayland# `*`
|Ports para suportar o servidor de display Wayland.
|

|[.filename]#windowmaker# `*`
|Ports para suportar o gerenciador de janelas do WindowMaker.
|

|[.filename]#www#
|Software relacionado à World Wide Web.
|O suporte ao idioma HTML também pertence aqui.

|[.filename]#x11#
|O X Window System e seus amigos.
|Esta categoria é apenas para software que suporta diretamente o sistema de janelas. Não coloque aplicativos regulares do X aqui. A maioria deles é usada em outras categorias [.filename]#x11- *# (veja abaixo).

|[.filename]#x11-clocks#
|X11 relógios.
|

|[.filename]#x11-drivers#
|Drivers X11.
|

|[.filename]#x11-fm#
|Gerentes de arquivos X11.
|

|[.filename]#x11-fonts#
|Fontes X11 e utilitários de fonte.
|

|[.filename]#x11-servers#
|Servidores X11.
|

|[.filename]#x11-themes#
|X11 temas.
|

|[.filename]#x11-toolkits#
|Kits de ferramentas X11.
|

|[.filename]#x11-wm#
|Gerentes de janela do X11.
|

|[.filename]#xfce# `*`
|Ports relacionados com o ambiente de trabalho http://www.xfce.org/[Xfce].
|

|[.filename]#zope# `*`
|http://www.zope.org/[Zope] suporte.
|
|===

[[choosing-categories]]
=== Escolhendo a Categoria Correta

Como muitas das categorias se sobrepõem, escolher qual das categorias será a principal categoria do port pode ser entediante. Existem várias regras que governam essa questão. Aqui está a lista de prioridades, em ordem decrescente de precedência:

* A primeira categoria deve ser uma categoria física (veja <<porting-categories,acima>>). Isso é necessário para o empacotamento funcionar. Categorias virtuais e categorias físicas podem ser misturadas depois disso.
* As categorias específicas de idioma sempre vêm em primeiro lugar. Por exemplo, se o port instalar fontes X11 em japonês, a linha `CATEGORIES` deve ser [.filename]#japanese x11-fonts#.
* Categorias específicas são listadas antes de outras menos específicas. Por exemplo, um editor de HTML é listado como [.filename]#www editors#, e não ao contrário. Além disso, não insira [.filename]#net# quando o port pertencer a qualquer uma das categorias [.filename]#irc#, [.filename]#mail#, [.filename]#news#, [.filename]#security# ou [.filename]#www#, pois [.filename]#net# está incluída implicitamente.
* [.filename]#x11# é usado como uma categoria secundária somente quando a categoria principal é uma linguagem natural. Em particular, não coloque [.filename]#x11# na linha de categoria em aplicações X.
* Os modes Emacs são colocados na mesma categoria de ports que a aplicação suportada pelo mode, e não em [.filename]#editors#. Por exemplo, um mode Emacs para editar código fonte de alguma linguagem de programação entra em [.filename]#lang#.
* Ports que instalam módulos do kernel carregáveis ​​também têm a categoria virtual [.filename]#kld# na sua linha `CATEGORIES`. Esta é uma das coisas tratadas automaticamente adicionando `USES=kmod`.
* [.filename]#misc# não aparece com nenhuma outra categoria não virtual. Se houver `misc` com outra categoria na linha `CATEGORIES`, isso significa que `misc` pode ser seguramente excluído e o port colocado apenas no outro subdiretório.
* Se o port realmente não pertencer em nenhum outro lugar, coloque-o em [.filename]#misc#.

Se a categoria não estiver claramente definida, por favor, insira um comentário sobre isso na submissão https://bugs.freebsd.org/submit/[do port] no banco de dados de bugs, para que possamos discuti-lo antes de importá-lo. Como committer, envie uma mensagem para a http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports[lista de discussão de ports do FreeBSD], para podermos discutir isso primeiro. Com muita frequência, novos ports são importados na categoria errada, e depois são movidos imediatamente para a categoria correta.

[[proposing-categories]]
=== Propondo uma Nova Categoria

Como a Coleção de Ports vem crescendo com o tempo, várias novas categorias também são adicionadas. Novas categorias podem ser categorias _virtuais_- aquelas que não possuem um subdiretório correspondente na árvore de ports - ou _físicas_ - aquelas que possuem. Esta seção discute os problemas envolvidos na criação de uma nova categoria física. Leia atentamente antes de propor uma nova.

Nossa prática atual tem sido a de evitar a criação de uma nova categoria física, a menos que um grande número de ports logicamente pertençam a ela, ou os ports que pertenceriam a ela sejam um grupo logicamente distinto de interesse geral limitado (por exemplo, categorias relacionadas com as línguas humanas faladas), ou de preferência ambas.

A razão para isto é que tal mudança cria uma extref:{committers-guide}[quantidade grande de trabalho, ports] tanto para os committers quanto para todos os usuários que rastreiam alterações na coleção de ports. Além disso, propostas de alteração de categorias parecem naturalmente atrair controvérsias. (Talvez isso seja porque não há um consenso claro sobre quando uma categoria é "grande o suficiente", nem quando as categorias devem ser apenas para propósitos de busca (e, portanto, qual número de categorias seria um número ideal), e assim por diante.)

Aqui está o procedimento:

[.procedure]
====
. Proponha a nova categoria na http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports[lista de discussão de ports do FreeBSD]. Inclua uma justificativa detalhada para a nova categoria, incluindo por que as categorias existentes não são suficientes, e a lista de ports existentes propostos para a mudança. (Se houver novos ports pendentes no Bugzilla que caberia nessa categoria, liste-os também.) Se você for o mantenedor e/ou o apresentador, respectivamente, mencione isso, pois isso pode ajudar no caso.
. Participe da discussão.
. Se parecer que há apoio o suficiente para a ideia, registre um PR que inclua a lógica e a lista de ports existentes que precisam ser movidos. O ideal é que este PR também inclua essas alterações:

** [.filename]##Makefile##s para os novos ports, uma vez que sejam recopiados
** [.filename]#Makefile# para a nova categoria
** [.filename]#Makefile# para as categorias dos ports antigos
** [.filename]##Makefile##s para ports que dependem dos ports antigos
** (para crédito extra, inclua os outros arquivos que precisam ser alterados, conforme o procedimento no Guia do Committer.)

. Como isso afeta a infraestrutura do ports e envolve a movimentação e alteração de vários ports, pode ser necessário executar testes de regressão no cluster de build, e portanto, atribua o PR para a Equipe de Gerenciamento de Ports mailto:portmgr@FreeBSD.org[portmgr@FreeBSD.org].
. Se esse PR for aprovado, um committer precisará seguir o restante do procedimento que é extref:{committers-guide}[descrito no Guia do Committer, ports].
====

A proposta de uma nova categoria virtual é semelhante à acima, mas muito menos trabalhoso, já que nenhum port terá que ser movido. Nesse caso, os únicos patches a serem incluídos no PR serão aqueles para adicionar a nova categoria na linha `CATEGORIES` dos ports afetados.

[[proposing-reorg]]
=== Propondo Reorganizar Todas as Categorias

Ocasionalmente alguém propõe reorganizar as categorias com uma estrutura de dois níveis, ou algum outro tipo de estrutura de palavras-chave. Até o momento, nada vem de nenhuma dessas propostas porque, embora sejam muito fáceis de fazer, o esforço envolvido com qualquer readequação de toda a coleção de ports existente é assustadora, para se dizer o mínimo. Por favor, leia o histórico dessas propostas nos arquivos da lista de discussão antes de postar essa idéia. Além disso, esteja preparado para ser desafiado a oferecer um protótipo funcional.

[[makefile-distfiles]]
== Os Arquivos de Distribuição

A segunda parte do [.filename]#Makefile# descreve os arquivos que devem ser baixados para compilar o port e onde eles podem ser baixados.

[[makefile-distname]]
=== `DISTNAME`

`DISTNAME` é o nome do port, conforme chamado pelos autores do software. `DISTNAME` é derivado de `${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}`, e se não estiver definido, `DISTVERSION` é derivado de `${PORTVERSION}`, portanto altere `DISTNAME` somente se necessário. `DISTNAME` é usado apenas em dois lugares. Primeiro, na lista de arquivos de distribuição (`DISTFILES`) padrão para `${DISTNAME} ${EXTRACT_SUFX}`. Em segundo lugar, espera-se que o arquivo de distribuição seja extraído em um subdiretório denominado `WRKSRC`, cujo padrão é [.filename]#work/${DISTNAME}#.

Alguns nomes de distribuição de fornecedores que não se encaixam no `${PORTNAME}-${PORTVERSION}`-scheme podem ser tratados automaticamente configurando `DISTVERSIONPREFIX`, `DISTVERSION` e `DISTVERSIONSUFFIX`. `PORTVERSION` será derivado de `DISTVERSION` automaticamente.

[IMPORTANT]
====
Apenas um dos `PORTVERSION` e `DISTVERSION` pode ser definido de cada vez. E se `DISTVERSION` não derivar um `PORTVERSION` correto, não use `DISTVERSION`.
====

Se o esquema de versão upstream puder ser derivado em um esquema de versão compatível com o ports, defina uma variável para a versão upstream, _não_ use `DISTVERSION` como o nome da variável. Defina `PORTVERSION` para a versão computada com base na variável criada, e defina `DISTNAME` adequadamente.

Se o esquema de versão upstream não puder ser facilmente configurado para um valor compatível com o ports, defina `PORTVERSION` para um valor sensato, e defina `DISTNAME` com `PORTNAME` com a versão literal do upstream.

[[makefile-distname-ex1]]
.Derivando `PORTVERSION` Manualmente
[example]
====
BIND9 usa um esquema de versão que não é compatível com as versões de ports (tem `-` em suas versões) e não pode ser derivado usando `DISTVERSION` porque após a versão 9.9.9, será lançado "patchlevels" na forma `9.9.9-P1`. DISTVERSION iria traduzir isso para `9.9.9.p1`, que no esquema de versionamento de ports significa 9.9.9 pré-release 1, que vem antes de 9.9.9 e não depois. Assim `PORTVERSION` é derivado manualmente de uma variável `ISCVERSION` para retornar `9.9.9p1`.

A ordem na qual o framework do ports e o pkg ordenará as versões, é verificada usando o argumento `-t` do 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
< <.>
....

<.> O sinal `>` significa que o primeiro argumento passado em `-t` é maior que o segundo argumento. `9.9.9` é maior que `9.9.9.p1`.
<.> O sinal `<` significa que o primeiro argumento passado em `-t` é menor que o segundo argumento. `9.9.9` é menor que `9.9.9p1`.

No [.filename]#Makefile# do port, por exemplo package:dns/bind99[], é alcançado por:

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

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

<.> Defina a versão upstream em `ISCVERSION`, com um comentário dizendo _porque_ é necessário.
<.> Use `ISCVERSION` para obter um `PORTVERSION` compatível com o ports.
<.> Use `ISCVERSION` diretamente para obter a URL correta para baixar o arquivo de distribuição.
<.> Use `ISCVERSION` diretamente para nomear o arquivo de distribuição.
====

[[makefile-distname-ex2]]
.Derivar `DISTNAME` a partir de `PORTVERSION`
[example]
====
De tempos em tempos, o nome do arquivo de distribuição tem pouca ou nenhuma relação com a versão do software.

No package:comms/kermit[], apenas o último elemento da versão está presente no arquivo de distribuição:

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

<.> O modificador `:E` man:make[1] retorna o sufixo da variável, neste caso, `304`. O arquivo de distribuição `cku304-dev20.tar.gz` é gerado corretamente.
====

[[makefile-distname-ex3]]
.Caso Exótico 1
[example]
====
Às vezes, não há relação entre o nome do software, sua versão e o arquivo de distribuição no qual ele é distribuído.

Do package:audio/libworkman[]:

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

====

[[makefile-distname-ex4]]
.Caso Exótico 2
[example]
====
No package:comms/librs232[], o arquivo de distribuição não é versionado, portanto, <<makefile-dist_subdir,`DIST_SUBDIR`>> é necessário:

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

====

[NOTE]
====
`PKGNAMEPREFIX` e `PKGNAMESUFFIX` não afetam o `DISTNAME`. Observe também que se `WRKSRC` for igual a [.filename]#${WRKDIR}/${DISTNAME}# enquanto o arquivo fonte original é nomeado para algo diferente de `${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}`, deixe `DISTNAME` sozinho-- definir apenas `DISTFILES` é mais fácil que ambos `DISTNAME` e `WRKSRC` (e possivelmente `EXTRACT_SUFX`).
====

[[makefile-master_sites]]
=== `MASTER_SITES`

Grave a parte do diretório do FTP/HTTP-URL apontando para o tarball original em `MASTER_SITES`. Não esqueça a barra final ([.filename]#/#)!

A macro `make` irá tentar usar esta especificação para baixar o arquivo de distribuição com `FETCH` se não for possível encontrá-lo já no sistema.

Recomenda-se que vários sites sejam incluídos nesta lista, de preferência em diferentes continentes. Isso irá proteger contra problemas de rede amplos.

[IMPORTANT]
====
`MASTER_SITES` não deve estar em branco. Ele deve apontar para o site real que hospeda os arquivos de distribuição. Ele não pode apontar para web archives ou para os sites de cache dos arquivos de distribuição do FreeBSD. A única exceção a essa regra são ports que não possuem arquivos de distribuição. Por exemplo, meta-ports não possuem arquivos de distribuição, assim o `MASTER_SITES` não precisa ser definido.
====

[[makefile-master_sites-shorthand]]
==== Usando Variáveis `MASTER_SITE_*`​​

Abreviações de atalhos estão disponíveis para arquivos populares como o SourceForge (`SOURCEFORGE`), GNU (`GNU`), ou Perl CPAN (`PERL_CPAN`). `MASTER_SITES` pode usá-los diretamente:

[.programlisting]
....
MASTER_SITES=	GNU/make
....

O antigo formato expandido ainda funciona, mas todos os ports foram convertidos para o formato compacto. O formato expandido se parece com isto:

[.programlisting]
....
MASTER_SITES=		${MASTER_SITE_GNU}
MASTER_SITE_SUBDIR=	make
....

Estes valores e variáveis ​​são definidos em https://svnweb.freebsd.org/ports/head/Mk/bsd.sites.mk?view=markup[Mk/bsd.sites.mk]. Novas entradas são adicionadas com frequência, portanto, verifique a versão mais recente deste arquivo antes de enviar um port.

[TIP]
====

Para qualquer variável `MASTER_SITE_FOO` , a versão abreviada `_FOO_` pode ser utilizada. Por exemplo, use:

[.programlisting]
....
MASTER_SITES=	FOO
....

E se `MASTER_SITE_SUBDIR` for necessário, use isso:

[.programlisting]
....
MASTER_SITES=	FOO/bar
....

====

[NOTE]
====
Alguns nomes `MASTER_SITE_*` são bastante longos e, para facilitar o uso, foram definidos atalhos:

[[makefile-master_sites-shortcut]]
.Atalhos para Macros `MASTER_SITE_*`
[cols="1,1", frame="none", options="header"]
|===
| Macro
| Atalho

|`PERL_CPAN`
|`CPAN`

|`GITHUB`
|`GH`

|`GITHUB_CLOUD`
|`GHC`

|`LIBREOFFICE_DEV`
|`LODEV`

|`NETLIB`
|`NL`

|`RUBYGEMS`
|`RG`

|`SOURCEFORGE`
|`SF`
|===
====

[[makefile-master_sites-magic]]
==== Macros Mágicas de MASTER_SITES

Várias macros "mágicas" existem para sites populares com uma estrutura de diretórios previsível. Para isso, basta usar a abreviação e o sistema escolherá um subdiretório automaticamente. Para um port nomeado `Stardict`, de versão `1.2.3` e hospedado no SourceForge, adicione esta linha:

[.programlisting]
....
MASTER_SITES=	SF
....

Implica em um subdiretório chamado `/project/stardict/stardict/1.2.3`. Se o diretório estiver incorreto, ele poderá ser substituído:

[.programlisting]
....
MASTER_SITES=	SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION}
....

Isso também pode ser escrito como

[.programlisting]
....
MASTER_SITES=	SF
MASTER_SITE_SUBDIR=	stardict/WyabdcRealPeopleTTS/${PORTVERSION}
....

[[makefile-master_sites-popular]]
.Macros Mágicas de `MASTER_SITES`
[cols="1,1", frame="none", options="header"]
|===
| Macro
| Subdiretório deduzido

|`APACHE_COMMONS_BINARIES`
|`${PORTNAME:S,commons-,,}`

|`APACHE_COMMONS_SOURCE`
|`${PORTNAME:S,commons-,,}`

|`APACHE_JAKARTA`
|`${PORTNAME:S,-,/,}/source`

|`BERLIOS`
|`${PORTNAME:tl}.berlios`

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

Se o arquivo de distribuição vier de um commit ou tag específico no https://github.com[GitHub] para o qual não há arquivo lançado oficialmente, há uma maneira fácil de definir o `DISTNAME` e `MASTER_SITES` corretos automaticamente. Estas variáveis ​​estão disponíveis:
[[makefile-master_sites-github-description]]
.`USE_GITHUB` Descrição
[cols="1,1,1", options="header"]
|===
| Variável
| Descrição
| Padrão

|`GH_ACCOUNT`
|Nome da conta do usuário do GitHub que hospeda o projeto
|`${PORTNAME}`

|`GH_PROJECT`
|Nome do projeto no GitHub
|`${PORTNAME}`

|`GH_TAGNAME`
|Nome da tag para download (2.0.1, hash, ...) Usar o nome de uma branch aqui é errado. Também é possível usar o hash de um ID de commit para gerar um snapshot.
|`${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}`

|`GH_SUBDIR`
|Quando o software precisa que um arquivo de distribuição adicional seja extraído em `${WRKSRC}`, esta variável pode ser usada. Veja os exemplos em <<makefile-master_sites-github-multiple>> para maiores informações.
|(none)

|`GH_TUPLE`
|`GH_TUPLE` permite colocar `GH_ACCOUNT`, `GH_PROJECT`, `GH_TAGNAME` e `GH_SUBDIR` em uma única variável. O formato é _conta_`:`_projeto_`:`_tagname_`:`_grupo_`/`_subdiretório_. O `/`_subdiretório _ é opcional. Isso é útil quando mais de um projeto no GitHub precisa ser utilizado.
|===

[IMPORTANT]
====
Não use `GH_TUPLE` para o arquivo de distribuição padrão, já que não tem nenhum padrão.
====

[[makefile-master_sites-github-ex1]]
.Uso Simples de `USE_GITHUB`
[example]
====
Ao tentar fazer um port para a versão `1.2.7` do pkg do usuário FreeBSD no github, em https://github.com/freebsd/pkg[], O [.filename]#Makefile# acabaria ficando assim (levemente simplificado para o exemplo):

[.programlisting]
....
PORTNAME=	pkg
DISTVERSION=	1.2.7

USE_GITHUB=	yes
GH_ACCOUNT=	freebsd
....

`MASTER_SITES` será automaticamente definido como `GH GHC` e `WRKSRC` para `${WRKDIR}/pkg-1.2.7`.
====

[[makefile-master_sites-github-ex2]]
.Uso Mais Completo de `USE_GITHUB`
[example]
====
Ao tentar fazer um port para uma versão de desenvolvimento do pkg do usuário FreeBSD no github, em https://github.com/freebsd/pkg[], o [.filename]#Makefile# acaba ficando assim (levemente simplificado para o exemplo):

[.programlisting]
....
PORTNAME=	pkg-devel
DISTVERSION=	1.3.0.a.20140411

USE_GITHUB=	yes
GH_ACCOUNT=	freebsd
GH_PROJECT=	pkg
GH_TAGNAME=	6dbb17b
....

`MASTER_SITES` será automaticamente definido para `GH GHC` e `WRKSRC` para `${WRKDIR}/pkg-6dbb17b`.

[TIP]
======

`20140411` é a data do commit referenciada em `GH_TAGNAME`, não a data em que é editado o [.filename]#Makefile#, ou a data em que o commit é feito.
======

====

[[makefile-master_sites-github-ex3]]
.Uso de `USE_GITHUB` com `DISTVERSIONPREFIX`
[example]
====
De tempos em tempos, `GH_TAGNAME` é uma ligeira variação de `DISTVERSION`. Por exemplo, se a versão for `1.0.2`, e a tag `v1.0.2`. Nesses casos, é possível usar `DISTVERSIONPREFIX` ou `DISTVERSIONSUFFIX`:

[.programlisting]
....
PORTNAME=	foo
DISTVERSIONPREFIX=	v
DISTVERSION=	1.0.2

USE_GITHUB=	yes
....

`GH_TAGNAME` será automaticamente definido para `v1.0.2`, enquanto `WRKSRC` será mantido como `${WRKDIR} /foo-1.0.2`.
====

[[makefile-master_sites-github-ex4]]
.Usando `USE_GITHUB` Quando o Upstream Não Usa Versões
[example]
====
Se nunca houve uma versão upstream, não invente uma como `0.1` ou `1.0`. Crie o port com um `DISTVERSION` de `gYYYYMMDD`, onde `g` é para Git e `YYYYMMDD` representa a data em que o commit é referenciado em `GH_TAGNAME`.

[.programlisting]
....
PORTNAME=	bar
DISTVERSION=	g20140411

USE_GITHUB=	yes
GH_TAGNAME=	c472d66b
....

Isso cria um esquema de controle de versão que é incrementado com o tempo e que ainda é menor do que a versão `0` (veja <<makefile-versions-ex-pkg-version>> para mais informações do man:pkg-version[8]):

[source,shell]
....
% pkg version -t g20140411 0
<
....

Isso significa que não será necessário usar o `PORTEPOCH` caso o upstream decida lançar versões no futuro.
====

[[makefile-master_sites-github-ex5]]
.Usando `USE_GITHUB` para Acessar um Commit Entre Duas Versões
[example]
====
Se a versão atual do software usa uma tag Git, e o port precisa ser atualizado para uma versão mais recente e intermediária, sem uma tag, use man:git-describe[1] para descobrir a versão a ser utilizada:

[source,shell]
....
% git describe --tags f0038b1
v0.7.3-14-gf0038b1
....

`v0.7.3-14-gf0038b1` pode ser dividido em três partes:

`v0.7.3`::
Este é a última tag Git que aparece no histórico de commits antes do commit solicitado.

`-14`::
Isso significa que o commit solicitado, `f0038b1`, é o 14º commit após a tag `v0.7.3`.

`-gf0038b1`::
O `-g` significa "Git", e o `f0038b1` é o commit hash referenciado.

[.programlisting]
....
PORTNAME=	bar
DISTVERSIONPREFIX=  v
DISTVERSION=	0.7.3-14
DISTVERSIONSUFFIX=  -gf0038b1

USE_GITHUB=	yes
....

Isso cria um esquema de versionamento que é incrementado com o tempo (bem, em cima de commits), e não entra em conflito com a criação de uma versão `0.7.4`. (Veja <<makefile-versions-ex-pkg-version>> para detalhes do man:pkg-version[8]):

[source,shell]
....
% pkg version -t 0.7.3 0.7.3.14
<
% pkg version -t 0.7.3.14 0.7.4
<
....

[NOTE]
======
Se o commit solicitado é o mesmo que uma tag, uma descrição mais curta é mostrada por padrão. A versão mais longa é equivalente:

[source,shell]
....
% git describe --tags c66c71d
v0.7.3
% git describe --tags --long c66c71d
v0.7.3-0-gc66c71d
....

======

====

[[makefile-master_sites-github-multiple]]
==== Baixando Múltiplos Arquivos do GitHub

O framework `USE_GITHUB` também suporta a obtenção de vários arquivos de distribuição de diferentes locais no GitHub. Ele funciona de uma forma muito semelhante ao <<porting-master-sites-n>>.

Vários valores são adicionados a `GH_ACCOUNT`, `GH_PROJECT` e `GH_TAGNAME`. Cada valor diferente é atribuído a um grupo. O valor principal pode não ter nenhum grupo ou grupo `:DEFAULT`. Um valor pode ser omitido se for o mesmo que o padrão listado em <<makefile-master_sites-github-description>>.

`GH_TUPLE` também pode ser usado quando há muitos arquivos de distribuição. Isso ajuda a manter as informações de conta, projeto, tagname e grupo no mesmo lugar.

Para cada grupo, uma variável auxiliar `${WRKSRC_group}` é criada, contendo o diretório no qual o arquivo foi extraído. As variáveis `${WRKSRC_group}` ​​podem ser usadas para mover diretórios durante o `post-extract`, ou para serem adicionadas em `CONFIGURE_ARGS`, ou o que for necessário para que o software seja compilado corretamente.

[CAUTION]
====

A parte do `:group` _deve_ ser usada para _apenas um_ arquivo de distribuição. Ela é usado como uma chave única e usá-la mais de uma vez irá sobrescrever os valores anteriores.
====

[NOTE]
====
Como isso é apenas modificações de `DISTFILES` e `MASTER_SITES`, os nomes dos grupos devem obedecer às restrições de nomes de grupos descritas em <<porting-master-sites-n>>
====

Ao buscar vários arquivos do GitHub, às vezes o arquivo de distribuição padrão não é buscado no GitHub. Para desabilitar a busca da distribuição padrão, defina:

[.programlisting]
....
USE_GITHUB=	nodefault
....

[IMPORTANT]
====
Ao utilizar `USE_GITHUB=nodefault`, o [.filename]#Makefile# deve ter `DISTFILES` em seu <<porting-order-portname,bloco inicial>>. A definição deve ser:

[.programlisting]
....
DISTFILES=    ${DISTNAME}${EXTRACT_SUFX}
....

====

[[makefile-master_sites-github-multi]]
.Uso de `USE_GITHUB` com Vários Arquivos de Distribuição
[example]
====
De tempos em tempos é necessário baixar mais de um arquivo de distribuição. Por exemplo, quando o repositório git do upstream usa submódulos. Isso pode ser feito facilmente usando grupos nas variáveis `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}
....

Isso irá baixar três arquivos de distribuição do github. O padrão vem de [.filename]#foo/foo# versão `1.0.2`. O segundo, com o grupo `icons`, vem de [.filename]#bar/foo-icons# versão `1.0`. O terceiro vem de [.filename]#bar/foo-contrib# e usa o commit do Git `fa579bc`. Os arquivos de distribuição são nomeados [.filename]#foo-foo-1.0.2_GH0.tar.gz#, [.filename]#bar-foo-icons-1.0_GH0.tar.gz# e [.filename]#bar-foo-contrib-fa579bc_GH0.tar.gz#.

Todos os arquivos de distribuição são extraídos em `${WRKDIR}` em seus respectivos subdiretórios. O arquivo padrão ainda é extraído em `${WRKSRC}`, nesse caso, [.filename]#${WRKDIR}/foo-1.0.2#. Cada arquivo de distribuição adicional é extraído em `${WRKSRC_group}`. Aqui, para o grupo `icons`, chamado de `${WRKSRC_icons}`, será [.filename]#${WRKDIR}/foo-icons-1.0#. O arquivo com o grupo `contrib` é chamado de `${WRKSRC_contrib}` e contém `${WRKDIR}/foo-contrib-fa579bc`.

O sistema de compilação do software espera encontrar os ícones em um subdiretório [.filename]#ext/icons# em seus fontes, então `GH_SUBDIR` é usado. `GH_SUBDIR` garante que [.filename]#ext# exista, mas não que [.filename]#ext/icons# também exista. Então isso acontece:

[.programlisting]
....
post-extract:
      @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons
....

====

[[makefile-master_sites-github-multi2]]
.Uso de `USE_GITHUB` com Vários Arquivos de Distribuição Usando `GH_TUPLE`
[example]
====
Isto é funcionalmente equivalente a <<makefile-master_sites-github-multi>> mas usando `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}
....

Agrupamento foi usado no exemplo anterior com `bar:icons, contrib`. Algumas informações redundantes estão presentes com `GH_TUPLE` porque o uso de agrupamento não é possível.
====

[[makefile-master_sites-github-submodules]]
.Como Usar `USE_GITHUB` com Submodulos Git?
[example]
====
Ports com o GitHub como um repositório upstream às vezes usam submódulos. Veja man:git-submodule[1] para maiores informações.

O problema com submódulos é que cada um é um repositório separado. Como tal, cada um deve ser buscado separadamente.

Usando package:finances/moneymanagerex[] como exemplo, seu repositório GitHub é https://github.com/moneymanagerex/moneymanagerex[]. Tem um arquivo https://github.com/moneymanagerex/moneymanagerex/blob/master/.gitmodules[.gitmodules] na raiz. Este arquivo descreve todos os sub módulos usados neste repositório e lista os repositórios adicionais necessários. Este arquivo irá dizer quais repositórios adicionais são necessários:

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

A única informação que falta nesse arquivo é a hash ou tag de commit para usar na versão. Esta informação é encontrada após a clonagem do repositório:

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

Também pode ser encontrado no GitHub. Cada subdiretório que é um submódulo é mostrado como _diretório_ `@` _hash_, por exemplo,`mongoose @ 2140e59`.

[NOTE]
======
Embora a obtenção das informações pelo GitHub pareça mais fácil, as informações encontradas usando `git submodule status` fornecerá informações mais significativas. Por exemplo, o commit hash de `lib/wxsqlite3 fb66eb2` corresponde a `v3.4.0`. Ambos podem ser usados, mas quando uma tag estiver disponível, use-a.
======

Agora que todas as informações necessárias foram reunidas, o [.filename]#Makefile# pode ser escrito (somente as linhas relacionadas ao GitHub são mostradas):

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

Semelhante ao GitHub, se o arquivo de distribuição vier de https://gitlab.com[gitlab.com] ou se estiver hospedado com o software GitLab, essas variáveis estão disponíveis para uso e talvez precisem ser definidas.

[[makefile-master_sites-gitlab-description]]
.`USE_GITLAB` Descrição
[cols="1,1,1", options="header"]
|===
| Variável
| Descrição
| Padrão

|`GL_SITE`
|Nome do site que hospeda o projeto GitLab
|https://gitlab.com

|`GL_ACCOUNT`
|Nome da conta do usuário do GitLab hospedando o projeto
|`${PORTNAME}`

|`GL_PROJECT`
|Nome do projeto em GitLab
|`${PORTNAME}`

|`GL_COMMIT`
|O hash de commit para download. Deve ser o hash hex sha1 completo de 160 bits e 40 caracteres. Essa é uma variável obrigatória para GitLab.
|`(none)`

|`GL_SUBDIR`
|Quando o software precisa de um arquivo de distribuição adicional para ser extraído com `${WRKSRC}`, esta variável pode ser usada. Veja os exemplos em <<makefile-master_sites-gitlab-multiple>> para maiores informações.
|(none)

|`GL_TUPLE`
|`GL_TUPLE` permite colocar `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT`, `GL_COMMIT`, e `GL_SUBDIR` dentro de uma única variável. O formato é _site_`:`_conta_`:`_projeto_`:`_commit_`:`_grupo_`/`_subdiretório_. O _site_`:` e `/`_subdiretório_ são opcionais. Isso ajuda quando é necessário baixar arquivos de mais de um projeto GitLab.
|===

[[makefile-master_sites-gitlab-ex1]]
.Uso Simples de `USE_GITLAB`
[example]
====
Ao tentar fazer um port para a versão `1.14` do libsignon-glib do usuário accounts-sso do gitlab.com, em https://gitlab.com/accounts-sso/libsignon-glib[], O [.filename]#Makefile# acabaria ficando assim para buscar os arquivos de distribuição:

[.programlisting]
....
PORTNAME=	libsignon-glib
DISTVERSION=	1.14

USE_GITLAB=	yes
GL_ACCOUNT=	accounts-sso
GL_COMMIT=	e90302e342bfd27bc8c9132ab9d0ea3d8723fd03
....

Ele terá automaticamente `MASTER_SITES` definido como https://gitlab.com[gitlab.com] e `WRKSRC` para `${WRKDIR}/libsignon-glib-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03`.
====

[[makefile-master_sites-gitlab-ex2]]
.Uso Mais Completo de `USE_GITLAB`
[example]
====
Um uso mais completo do exemplo acima é se o port não tiver controle de versão e foobar do usuário foo no projeto bar em um GitLab auto hospedado em `https://gitlab.example.com`, o [.filename]#Makefile# acaba ficando assim para buscar os arquivos de distribuição:

[.programlisting]
....
PORTNAME=	foobar
DISTVERSION=	g20170906

USE_GITLAB=	yes
GL_SITE=	https://gitlab.example.com
GL_ACCOUNT=	foo
GL_PROJECT=	bar
GL_COMMIT=	9c1669ce60c3f4f5eb43df874d7314483fb3f8a6
....

Terá `MASTER_SITES` definido como `"https://gitlab.example.com"` e `WRKSRC` para `${WRKDIR}/bar-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6`.

[TIP]
======

`20170906` é a data do commit referenciada em `GL_COMMIT`, não a data em que o [.filename]#Makefile# é editado, ou a data em que o commit para a árvore de ports do FreeBSD é feito.
======

[NOTE]
======
O protocolo, porta e webroot do `GL_SITE` podem ser modificados na mesma variável.
======

====

[[makefile-master_sites-gitlab-multiple]]
==== Baixando Múltiplos Arquivos do GitLab

O framework `USE_GITLAB` também suporta a busca de vários arquivos de distribuição de diferentes locais de GitLab e sites hospedados no GitLab. Ele funciona de uma forma muito semelhante ao <<porting-master-sites-n>> e <<makefile-master_sites-gitlab-multiple>>.

Vários valores são adicionados a `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT` e `GL_COMMIT`. Cada valor diferente é atribuído a um grupo. <<makefile-master_sites-gitlab-description>>.

`GL_TUPLE` também pode ser usado quando há muitos arquivos de distribuição. Isso ajuda a manter as informações de site, conta, projeto, commit e grupo no mesmo local.

Para cada grupo, uma variável auxiliar `${WRKSRC_group}` é criada, contendo o diretório no qual o arquivo foi extraído. As variáveis `${WRKSRC_group}` ​​podem ser usadas para mover diretórios durante o `post-extract`, ou para serem adicionadas em `CONFIGURE_ARGS`, ou o que for necessário para que o software seja compilado corretamente.

[CAUTION]
====

A parte do `:group` _deve_ ser usada para _apenas um_ arquivo de distribuição. Ela é usado como uma chave única e usá-la mais de uma vez irá sobrescrever os valores anteriores.
====

[NOTE]
====
Como isso é apenas modificações de `DISTFILES` e `MASTER_SITES`, os nomes dos grupos devem obedecer às restrições de nomes de grupos descritas em <<porting-master-sites-n>>
====

Ao buscar vários arquivos usando GitLab, às vezes, o arquivo de distribuição padrão não é obtido de um GitLab. Para desativar a busca do arquivo de distribuição padrão, defina:

[.programlisting]
....
USE_GITLAB=	nodefault
....

[IMPORTANT]
====
Ao utilizar `USE_GITLAB=nodefault`, o [.filename]#Makefile# deve ter `DISTFILES` em seu <<porting-order-portname,bloco inicial>>. A definição deve ser:

[.programlisting]
....
DISTFILES=    ${DISTNAME}${EXTRACT_SUFX}
....

====

[[makefile-master_sites-gitlab-multi]]
.Uso de `USE_GITLAB` com Vários Arquivos de Distribuição
[example]
====
De tempos em tempos, é necessário buscar mais de um arquivo de distribuição. Por exemplo, quando o repositório git do upstream usa submódulos. Isso pode ser feito facilmente usando grupos nas variáveis `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}
....

Isso irá buscar dois arquivos de distribuição do gitlab.com e um de `gitlab.example.com` hospedado com GitLab. O padrão vem de [.filename]#https://gitlab.com/foo/foo# e o commit é `c189207a55da45305c884fe2b50e086fcad4724b`. O segundo, com o grupo `icons`, vem de [.filename]#https://gitlab.example.com:9434/gitlab/bar/foo-icons# e o commit é `ae7368cab1ca7ca754b38d49da064df87968ffe4`. O terceiro vem de [.filename]#https://gitlab.com/bar/foo-contrib# e o commit é `9e4dd76ad9b38f33fdb417a4c01935958d5acd2a`. Os arquivos de distribuição são nomeados [.filename]#foo-foo-c189207a55da45305c884fe2b50e086fcad4724b_GL0.tar.gz#, [.filename]#bar-foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4_GL0.tar.gz# e [.filename]#bar-foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a_GL0.tar.gz#.

Todos os arquivos de distribuição são extraídos no `${WRKDIR}` em seus respectivos subdiretórios. O arquivo padrão ainda é extraído no `${WRKSRC}`, nesse caso, [.filename]#${WRKDIR}/foo-c189207a55da45305c884fe2b50e086fcad4724b-c189207a55da45305c884fe2b50e086fcad4724b#. Cada arquivo de distribuição adicional é extraído em `${WRKSRC_group}`. Aqui, para o grupo `icons`, é chamado `${WRKSRC_icons}` e contém [.filename]#${WRKDIR}/foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4-ae7368cab1ca7ca754b38d49da064df87968ffe4#. O arquivo com o grupo `contrib` é chamado `${WRKSRC_contrib}` e contém `${WRKDIR}/foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a`.

O sistema de compilação do software espera encontrar os ícones em um subdiretório [.filename]#ext/icons# em seus fontes, então `GL_SUBDIR` é usado.`GL_SUBDIR` garante que [.filename]#ext# existe, mas não que [.filename]#ext/icons# também exista. Então isso acontece:

[.programlisting]
....
post-extract:
        @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons
....

====

[[makefile-master_sites-gitlab-multi2]]
.Uso de `USE_GITLAB` com Vários Arquivos de Distribuição Usando `GL_TUPLE`
[example]
====
Isto é funcionalmente equivalente a <<makefile-master_sites-gitlab-multi>> mas usando `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}
....

Agrupamento foi usado no exemplo anterior com `bar:icons,contrib`. Algumas informações redundantes estão presentes com `GL_TUPLE` porque o uso de agrupamento não é possível.
====

[[makefile-extract_sufx]]
=== `EXTRACT_SUFX`

Se houver um arquivo de distribuição e ele usar um sufixo diferente para indicar o mecanismo de compactação, defina `EXTRACT_SUFX`.

Por exemplo, se o arquivo de distribuição foi nomeado [.filename]#foo.tar.gzip# em vez do mais comum [.filename]#foo.tar.gz#, escreva:

[.programlisting]
....
DISTNAME=	foo
EXTRACT_SUFX=	.tar.gzip
....

O `USES=tar[:xxx]`, `USES=lha` ou `USES=zip` define automaticamente `EXTRACT_SUFX` com as extensões de arquivo mais comuns, conforme necessário, consulte crossref:uses[uses, Usando Macros `USES`] para mais detalhes. Se nenhum destes estiver definido, o `EXTRACT_SUFX` padrão é `.tar.gz`.

[NOTE]
====
Como `EXTRACT_SUFX` é usado apenas em `DISTFILES`, apenas defina um deles..
====

[[makefile-distfiles-definition]]
=== `DISTFILES`

Às vezes os nomes dos arquivos a serem baixados não têm semelhança com o nome do port. Por exemplo, pode ser chamado [.filename]#source.tar.gz# ou similar. Em outros casos, o código-fonte do aplicativo pode estar em vários arquivos diferentes, e todos eles devem ser baixados.

Se este for o caso, defina `DISTFILES` para ser uma lista separada por espaços de todos os arquivos que devem ser baixados.

[.programlisting]
....
DISTFILES=	source1.tar.gz source2.tar.gz
....

Se não for definido explicitamente, o `DISTFILES` padrão é `${DISTNAME}${EXTRACT_SUFX}`.

[[makefile-extract_only]]
=== `EXTRACT_ONLY`

Se apenas alguns dos `DISTFILES` devem ser extraídos-- por exemplo, um deles é o código-fonte, enquanto outro é um documento não compactado - liste os nomes dos arquivos que devem ser extraídos em `EXTRACT_ONLY`.

[.programlisting]
....
DISTFILES=	source.tar.gz manual.html
EXTRACT_ONLY=	source.tar.gz
....

Quando nenhum dos `DISTFILES` precisam ser descompactados, deixe vazio o `EXTRACT_ONLY`.

[.programlisting]
....
EXTRACT_ONLY=
....

[[porting-patchfiles]]
=== `PATCHFILES`

Se o port requer alguns patches adicionais que estão disponíveis por FTP ou HTTP, defina `PATCHFILES` para os nomes dos arquivos e `PATCH_SITES` para a URL do diretório que os contém (o formato é o mesmo do `MASTER_SITES`).

Se o patch não for relativo ao inicio da árvore do código fonte (isto é, `WRKSRC`) porque contém alguns pathnames extras, defina `PATCH_DIST_STRIP` adequadamente. Por exemplo, se todos os pathnames no patch tiverem um `foozolix-1.0 /` extra na frente dos nomes dos arquivos, então defina `PATCH_DIST_STRIP=-p1`.

Não se preocupe se os patches estiverem compactados; eles serão descompactados automaticamente se os nomes dos arquivos terminarem com [.filename]#.Z#, [.filename]#.gz#, [.filename]#.bz2# ou [.filename]#.xz#.

Se o patch for distribuído com alguns outros arquivos, como documentação, em um arquivo compactado, o uso de `PATCHFILES` não será possível. Se for esse o caso, adicione o nome e a localização do arquivo do patch em `DISTFILES` e `MASTER_SITES`. Então, use `EXTRA_PATCHES` para apontar para esses arquivos e o [.filename]#bsd.port.mk# irá aplicá-los automaticamente. Em particular, _não_ copie os arquivos de patch em [.filename]#${PATCHDIR}#. Esse diretório pode não ter permissão de escrita.

[TIP]
====

Se houver vários patches e eles precisarem de valores mistos para o parâmetro strip, ele poderá ser adicionado ao lado do nome do patch em `PATCHFILES`, por exemplo:

[.programlisting]
....
PATCHFILES=	patch1 patch2:-p1
....

Isto não entra em conflito com <<porting-master-sites-n, o recurso de agrupamento de sites principais>>, adicionando um grupo também funciona:

[.programlisting]
....
PATCHFILES=	patch2:-p1:source2
....

====

[NOTE]
====
O arquivo será extraído junto com o arquivo de código fonte, então não há necessidade de explicitamente extraí-lo se ele for um arquivo compactado normal. Tome cuidado extra para não sobrescrever algo que já existe nesse diretório caso faça a extração manualmente. Também não se esqueça de adicionar um comando para remover o patch copiado no target `pre-clean`.
====

[[porting-master-sites-n]]
=== Múltiplos Arquivos de Distribuição ou Patches de Vários Locais

(Considere isto como um "tópico avançado"; a princípio, aqueles que são novos neste documento podem desejar pular esta seção).

Esta seção contém informações sobre o mecanismo de busca conhecido como `MASTER_SITES:n` e `MASTER_SITES_NN`. Vamos nos referir a este mecanismo como `MASTER_SITES:n`.

Um pouco de background primeiro. O OpenBSD tem um ótimo recurso dentro do `DISTFILES` e `PATCHFILES` que permite que arquivos e pacthes sejam pós fixados com identificadores `:n`. Aqui, `n` pode ser qualquer palavra que contenha `[0-9a-zA-Z_]` e signifique uma designação de grupo. Por exemplo:

[.programlisting]
....
DISTFILES=	alpha:0 beta:1
....

No OpenBSD, arquivo de distribuição [.filename]#alpha# será associado com a variável `MASTER_SITES0` em vez da nossa comum `MASTER_SITES` e [.filename]#beta# com `MASTER_SITES1`.

Esta é uma característica muito interessante que pode diminuir a busca sem fim pelo site de download correto.

Apenas imagine 2 arquivos em `DISTFILES` e 20 sites em `MASTER_SITES`, os sites são extremamente lentos e [.filename]#beta# é hospedado em todas as entradas do `MASTER_SITES` e [.filename]#alfa# só pode ser encontrado no 20º site. Seria um desperdício checar todos eles se o mantenedor soubesse isso de antemão, não seria? Não é um bom começo para aquele lindo fim de semana!

Agora que você já tem uma ideia, imagine mais `DISTFILES` e mais `MASTER_SITES`. Certamente nosso "distfiles survey meister" irá ser apreciado pelo alívio nas conexões de rede que isso trará.

Nas próximas seções, as informações seguirão a implementação do FreeBSD desta idéia. Nós melhoramos um pouco o conceito do OpenBSD.

[IMPORTANT]
====
Os nomes dos grupos não podem ter traços neles (`-`), na verdade, eles não podem ter nenhum caractere fora do range `[a-zA-Z0-9_]`. Isso porque, enquantoman:make[1] está ok com nomes de variáveis ​​contendo traços, man:sh[1]não.
====

[[porting-master-sites-n-simplified]]
==== Informação Simplificada

Esta seção explica como preparar rapidamente a busca de vários arquivos de distribuição e patches de diferentes sites e subdiretórios. Descrevemos aqui um caso de uso de `MASTER_SITES:n`. Isso será suficiente para a maioria dos cenários. Informações mais detalhadas estão disponíveis em <<ports-master-sites-n-detailed>>.

Alguns aplicativos consistem em vários arquivos de distribuição que devem ser baixados de vários sites diferentes. Por exemplo, Ghostscript consiste no núcleo do programa e, em seguida, um grande número de arquivos de driver que são usados dependendo da impressora do usuário. Alguns desses arquivos de driver são fornecidos com o núcleo, mas muitos outros devem ser baixados de uma variedade de sites diferentes.

Para suportar isso, cada entrada no `DISTFILES` pode ser seguida por dois pontos e um "nome de grupo". Cada site listado em `MASTER_SITES` é então seguido por dois pontos, e o grupo que indica quais arquivos de distribuição são baixados deste site.

Por exemplo, considere um aplicativo com a divisão do código fonte em duas partes, [.filename]#source1.tar.gz# e [.filename]#source2.tar.gz#, que deve ser baixado de dois sites diferentes. O [.filename]#Makefile# do port incluiria linhas como <<ports-master-sites-n-example-simple-use-one-file-per-site>>.

[[ports-master-sites-n-example-simple-use-one-file-per-site]]
.Uso Simplificado de `MASTER_SITES:n` com Um Arquivo Por Site
[example]
====
[.programlisting]
....
MASTER_SITES=	ftp://ftp1.example.com/:source1 \
		http://www.example.com/:source2
DISTFILES=	source1.tar.gz:source1 \
		source2.tar.gz:source2
....

====

Vários arquivos de distribuição podem ter o mesmo grupo. Continuando o exemplo anterior, suponha que houvesse um terceiro distfile, [.filename]#source3.tar.gz#, que é baixado do `ftp.example2.com`. O [.filename]#Makefile# seria então escrito como <<ports-master-sites-n-example-simple-use-more-than-one-file-per-site>>.

[[ports-master-sites-n-example-simple-use-more-than-one-file-per-site]]
.Uso Simplificado de `MASTER_SITES:n` com Mais de Um Arquivo Por Site
[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]]
==== Informação Detalhada

Ok, então o exemplo anterior não refletiu as necessidades do novo port? Nesta seção vamos explicar em detalhes como o mecanismo de busca avançado `MASTER_SITES:n` funciona e como ele pode ser usado.

. Elementos podem ser pós-fixados com `:__n__` onde _n_ é `[^:,]+`, isso é, _n_ poderia conceitualmente ser qualquer string alfanumérica, mas vamos limitá-lo a `[a-zA-Z_][0-9a-zA-Z_]+` por enquanto.
+ 
Além disso, a verificação de strings é case sensitive, ou seja, `n` é diferente de `N`.
+ 
No entanto, essas palavras não podem ser usadas para finalidades de pós-fixação, pois elas produzem um significado especial: `default`, `all` e `ALL` (estes são usados ​​internamente no item <<porting-master-sites-n-what-changes-in-port-targets,ii>>). Além disso, `DEFAULT` é uma palavra de propósito especial (verifique o item <<porting-master-sites-n-DEFAULT-group,3>>).
. Elementos pós-fixados com `:n` pertence ao grupo `n`, `:m` pertence ao grupo `m` e assim por diante.
+
[[porting-master-sites-n-DEFAULT-group]]
. Elementos que não estão pós-fixados são desagrupados, todos eles pertencem ao grupo especial `DEFAULT`. Quaisquer elementos pós-fixados com `DEFAULT` estão apenas sendo redundantes, a menos que um elemento pertença a ambos `DEFAULT` e outros grupos ao mesmo tempo (verifique o item <<porting-master-sites-n-comma-operator,5>>).
+ 
Esses exemplos são equivalentes, mas o primeiro é o preferido:
+
[.programlisting]
....
MASTER_SITES=	alpha
....
+
[.programlisting]
....
MASTER_SITES=	alpha:DEFAULT
....
+
. Grupos não são exclusivos, um elemento pode pertencer a vários grupos diferentes ao mesmo tempo e um grupo pode ter vários elementos diferentes ou nenhum.
+
[[porting-master-sites-n-comma-operator]]
. Quando um elemento pertence a vários grupos ao mesmo tempo, use uma vírgula (`,`).
+ 
Em vez de repetir isso várias vezes, cada vez com uma pós-fixação diferente, podemos listar vários grupos de uma vez em uma única pós-fixação. Por exemplo, `:m,n,o` marca um elemento que pertence ao grupo `m`, `n` e `o`.
+ 
Todos esses exemplos são equivalentes, mas o último é o preferido:
+
[.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
....
+
. Todos os sites dentro de um determinado grupo são ordernados de acordo com `MASTER_SORT_AWK`. Todos os grupos dentro de `MASTER_SITES` e `PATCH_SITES` são ordenados também.
+
[[porting-master-sites-n-group-semantics]]
. A semântica de grupo pode ser usada em qualquer uma das variáveis `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR`, `PATCH_SITE_SUBDIR`, `DISTFILES` e `PATCHFILES` de acordo com esta sintaxe:
.. Todos elementos `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR` e `PATCH_SITE_SUBDIR` devem ser terminados com o caractere barra `/`. Se algum elemento pertencer a algum grupo, o grupo de pós-fixação `:__n__` deve vir logo após o terminador `/`. O mecanismo `MASTER_SITES:n` depende da existência do terminador `/` para evitar confundir elementos onde um `:n` é uma parte válida do elemento com ocorrências em que `:n` denota grupo `n`. Para fins de compatibilidade, uma vez que o terminador `/` não for necessário antes em ambos elementos `MASTER_SITE_SUBDIR` e `PATCH_SITE_SUBDIR`, se o caractere precedente imediato da pós-fixação não for `/` então `:n` será considerada uma parte válida do elemento em vez de uma pós-fixação de grupo, mesmo que um elemento `n` seja pós-fixado. Veja ambos <<ports-master-sites-n-example-detailed-use-master-site-subdir>> e <<ports-master-sites-n-example-detailed-use-complete-example-master-sites>>.
+
[[ports-master-sites-n-example-detailed-use-master-site-subdir]]
.Uso Detalhado de `MASTER_SITES:n` no `MASTER_SITE_SUBDIR`
[example]
====
[.programlisting]
....
MASTER_SITE_SUBDIR=	old:n new/:NEW
....

*** Diretórios dentro do grupo `DEFAULT` -> old:n
*** Diretórios dentro do grupo `NEW` -> new

====
+
[[ports-master-sites-n-example-detailed-use-complete-example-master-sites]]
.Uso Detalhado de `MASTER_SITES:n` com Vírgula, Vários Arquivos, Vários Sites e Vários Subdiretórios
[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
....

O exemplo anterior resulta em uma busca detalhada. Os sites são listados na ordem exata em que serão usados.

*** [.filename]#arquivo1# será obtido a partir de

**** `MASTER_SITE_OVERRIDE`
**** http://site1/directory-trial:1/
**** http://site1/directory-one/
**** http://site1/directory/
**** http://site2/
**** http://site7/
**** `MASTER_SITE_BACKUP`

*** [.filename]#arquivo2# será baixado exatamente como o [.filename]#arquivo1# já que ambos pertencem ao mesmo grupo

**** `MASTER_SITE_OVERRIDE`
**** http://site1/directory-trial:1/
**** http://site1/directory-one/
**** http://site1/directory/
**** http://site2/
**** http://site7/
**** `MASTER_SITE_BACKUP`

*** [.filename]#arquivo3# será obtido a partir de

**** `MASTER_SITE_OVERRIDE`
**** http://site3/
**** `MASTER_SITE_BACKUP`

*** [.filename]#arquivo4# será obtido a partir de

**** `MASTER_SITE_OVERRIDE`
**** http://site4/
**** http://site5/
**** http://site6/
**** http://site7/
**** http://site8/directory-one/
**** `MASTER_SITE_BACKUP`

*** [.filename]#arquivo5# será obtido a partir de

**** `MASTER_SITE_OVERRIDE`
**** `MASTER_SITE_BACKUP`

*** [.filename]#file6# será obtido a partir de

**** `MASTER_SITE_OVERRIDE`
**** http://site8/
**** `MASTER_SITE_BACKUP`

====

. Como posso agrupar uma das macros especiais de [.filename]#bsd.sites.mk#, por exemplo, SourceForge (`SF`)?
+ 
Isso foi simplificado o máximo possível. Veja <<ports-master-sites-n-example-detailed-use-master-site-sourceforge>>.
+
[[ports-master-sites-n-example-detailed-use-master-site-sourceforge]]
.Uso Detalhado de `MASTER_SITES:n` com SourceForge (`SF`)
[example]
====
[.programlisting]
....
MASTER_SITES=	http://site1/SF/something/1.0:sourceforge,TEST
DISTFILES=	something.tar.gz:sourceforge
....

[.filename]#something.tar.gz# será obtido por todos os sites do SourceForge.
====
. Como eu uso isso com `PATCH*`?
+ 
Todos os exemplos foram feitos com `MASTER*` mas eles funcionam exatamente da mesma forma com `PATCH*` como pode ser visto em <<ports-master-sites-n-example-detailed-use-patch-sites>>.
+
[[ports-master-sites-n-example-detailed-use-patch-sites]]
.Uso Simplificado de `MASTER_SITES:n` com `PATCH_SITES`
[example]
====
[.programlisting]
....
PATCH_SITES=	http://site1/ http://site2/:test
PATCHFILES=	patch1:test
....

====

[[port-master-sites-n-what-changed]]
==== O que Muda para os Ports? O que Não Funciona?

[lowerroman]
. Todos os ports atuais permanecem os mesmos. A feature `MASTER_SITES:n` só é ativada se houver elementos pós-fixados com `:__n__` como elementos de acordo com as regras de sintaxe acima, especialmente como mostrado no item <<porting-master-sites-n-group-semantics,7>>.

[[porting-master-sites-n-what-changes-in-port-targets]]
. Os targets de port permanecem os mesmos: `checksum`, `makesum`, `patch`, `configure`, `build`, etc. Com as exceções óbvias de `do-fetch`, `fetch-list`, `master-sites` e `patch-sites`.

** `do-fetch`: implementa o novo agrupamento pós-fixado `DISTFILES` e `PATCHFILES` com seus elementos de grupo correspondentes dentro de ambos `MASTER_SITES` e `PATCH_SITES` que usam elementos de grupo correspondentes dentro de ambos `MASTER_SITE_SUBDIR` e `PATCH_SITE_SUBDIR`. Verifique <<ports-master-sites-n-example-detailed-use-complete-example-master-sites>>.
** `fetch-list`: funciona como o antigo `fetch-list`, com a exceção de que faz agrupamentos exatamente como o `do-fetch`.
** `master-sites` e `patch-sites`: (incompatível com versões mais antigas) somente retorna os elementos do grupo `DEFAULT`; na verdade, eles executam os targets `master-sites-default` e `patch-sites-default` respectivamente.
+ 
Além disso, usar o target `master-sites-all` ou `patch-sites-all` é o preferido para verificar diretamente `MASTER_SITES` ou `PATCH_SITES`. Além disso, não é garantido que a checagem direta funcione em versões futuras. Veja <<porting-master-sites-n-new-port-targets-master-sites-all, B>> para obter mais informações sobre esses novos tagets de port.

. Novos Targets de Port
.. Existem targets `master-sites-_n_` e `patch-sites-_n_` que listarão os elementos do respectivo grupo _n_ dentro de `MASTER_SITES` e `PATCH_SITES` respectivamente. Por exemplo, ambos `master-sites-DEFAULT` e `patch-sites-DEFAULT` retornarão os elementos do grupo `DEFAULT`, `master-sites-test` e `patch-sites-test` do grupo `test`.

[[porting-master-sites-n-new-port-targets-master-sites-all]]
.. Há novos targets `master-sites-all` e `patch-sites-all` que fazem o trabalho dos antigos `master-sites` e `patch-sites`. Eles retornam os elementos de todos os grupos como se todos pertencessem ao mesmo grupo, com a ressalva de que lista tantos `MASTER_SITE_BACKUP` e `MASTER_SITE_OVERRIDE` como existem grupos definidos dentro de qualquer `DISTFILES` ou `PATCHFILES`; respectivamente para `master-sites-all` e `patch-sites-all`.

[[makefile-dist_subdir]]
=== `DIST_SUBDIR`

Não deixe o [.filename]#/usr/ports/distfiles# bagunçado. Se um port exigir que muitos arquivos sejam baixados, ou que contenha um arquivo que tenha um nome que possa entrar em conflito com outros ports (por exemplo, [.filename]#Makefile#), defina `DIST_SUBDIR` com o nome do port (`${PORTNAME}` ou `${PKGNAMEPREFIX}${PORTNAME}`). Isso vai mudar o `DISTDIR` do padrão [.filename]#/usr/ports/distfiles# para [.filename]#/usr/ports/distfiles/${DIST_SUBDIR}#,e assim, será colocado tudo o que é necessário para o port nesse subdiretório.

Ele também examinará o subdiretório com o mesmo nome no site principal de backup em http://distcache.FreeBSD.org[http://distcache.FreeBSD.org] (Configurar o `DISTDIR` explicitamente no [.filename]#Makefile# não fará isso funcionar, então por favor use `DIST_SUBDIR`.)

[NOTE]
====
Isso não afeta o `MASTER_SITES` definido no [.filename]#Makefile#.
====

[[makefile-maintainer]]
== `MAINTAINER`

Defina seu endereço de email aqui. Por favor. _:-)_

Apenas um único endereço sem a parte de comentário é permitido como um valor para `MAINTAINER`. O formato usado é `user@hostname.domain`. Por favor, não inclua nenhum texto descritivo, como um nome nesta entrada. Isso confunde a infraestrutura do Ports e a maioria das ferramentas que a usam.

O mantenedor é responsável por manter o port atualizado e garantir que elo funcione corretamente. Para obter uma descrição detalhada das responsabilidades de um mantenedor de port, consulte extref:{contributing}[O desafio para os mantenedores de port, maintain-port].

[NOTE]
====
Um mantenedor se voluntaria para manter um port em bom estado de funcionamento. Os mantenedores têm a responsabilidade primária por seus ports, mas não possuem propriedade exclusiva. Os ports existem para o benefício da comunidade e, na realidade, pertencem à comunidade. O que isso significa é que outras pessoas além do mantenedor, também podem fazer alterações em um port. Grandes mudanças na Coleção de Ports podem exigir mudanças em muitos ports. A Equipe de Gerenciamento do Ports do FreeBSD ou membros de outras equipes podem modificar ports para corrigir problemas de dependência ou outros problemas, como um bump de versão para uma atualização de biblioteca compartilhada.

Alguns tipos de correções tem "aprovação implícita" da Equipe de Gerenciamento do Ports mailto:portmgr@FreeBSD.org[portmgr@FreeBSD.org], permitindo que qualquer committer conserte essas categorias de problemas em qualquer port. Essas correções não precisam da aprovação do mantenedor.

Aprovação implícita para a maioria dos ports se aplicam para correções como mudanças de infraestrutura, trivialidades e correções _testadas_ de compilação e execução. A lista atual está disponibilizada em extref:{committers-guide}[Seção Ports do Guia dos Committers, ports-qa-misc-blanket-approval].
====

Outras alterações no port serão enviadas ao mantenedor para revisão e aprovação antes de se fazer o commit. Se o mantenedor não responder a uma solicitação de atualização após duas semanas (excluindo os principais feriados), isso será considerado como timeout do mantenedor, e a atualização poderá ser feita sem a aprovação explícita do mesmo. Se o mantenedor não responder dentro de três meses, ou se houver três timeouts consecutivos, então o mantenedor é considerado ausente, e todas os seus ports podem ser atribuídos de volta para à comunidade. Exceções para isso são quaisquer ports mantidos pela Equipe de Gerenciamento de Ports mailto:portmgr@FreeBSD.org[portmgr@FreeBSD.org] ou pela Equipe de Oficias de Segurança mailto:security-officer@FreeBSD.org[security-officer@FreeBSD.org]. Nenhum commit não autorizado pode ser feito em ports mantidos por esses grupos.

Reservamo-nos o direito de modificar as submissões do mantenedor para melhor adequar as políticas e os estilos existentes da Coleção de Ports sem aprovação explicita do remetente ou do mantenedor. Além disso, grandes alterações de infraestrutura podem resultar na modificação de um port sem o consentimento do mantenedor. Estes tipos de alterações nunca irão afetar a funcionalidade do port.

A Equipe de Gerenciamento de Ports mailto:portmgr@FreeBSD.org[portmgr@FreeBSD.org] reserva o direito de revogar ou substituir a propriedade de mantenedor de qualquer pessoa por qualquer motivo, e a Equipe de Oficiais de Segurança mailto:security-officer@FreeBSD.org[security-officer@FreeBSD.org] reserva o direito de revogar ou substituir a propriedade de mantenedor por razões de segurança.

[[makefile-comment]]
== `COMMENT`

O comentário é uma descrição de uma linha de um port mostrada por `pkg info`. Por favor, siga estas regras ao compor:

. A string COMMENT deve ter 70 caracteres ou menos.
. _Não_ inclua o nome do pacote ou o número da versão do software.
. O comentário deve começar com uma letra maiúscula e terminar sem um ponto final.
. Não comece com um artigo indefinido (isto é, A ou Um).
. Capitalize nomes como Apache, JavaScript ou Perl.
. Use uma vírgula serial para listas de palavras: "verde, vermelho, e azul."
. Verifique erros de ortografia.

Aqui está um exemplo:

[.programlisting]
....
COMMENT=	Cat chasing a mouse all over the screen
....

A variável COMMENT vem depois da variável MAINTAINER no [.filename]#Makefile#.

[[licenses]]
== Licenças

Cada port deve documentar a licença sob a qual está disponível. Se não for uma licença aprovada pelo OSI, também deve documentar quaisquer restrições à redistribuição.

[[licenses-license]]
=== `LICENSE`

Um nome abreviado para a licença ou licenças se mais de uma licença for aplicada.

Se for uma das licenças listadas no <<licenses-license-list>>, apenas as variáveis `LICENSE_FILE` e `LICENSE_DISTFILES` podem ser definidas.

Se esta for uma licença que não tenha sido definida na infraestrutura de ports (veja <<licenses-license-list>>), `LICENSE_PERMS` e `LICENSE_NAME` devem ser definidos, juntamente com `LICENSE_FILE` ou `LICENSE_TEXT`. `LICENSE_DISTFILES` e `LICENSE_GROUPS` também podem ser definidos, mas não é necessário.

As licenças pré-definidas são mostradas em <<licenses-license-list>>. A lista atual está sempre disponível em [.filename]#Mk/bsd.licenses.db.mk#.

[[licenses-license-ex1]]
.Uso Mais Simples, Licenças Predefinidas
[example]
====
Quando o [.filename]#README# de algum software diz "This software is under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version." mas não fornece o arquivo de licença, use isto:

[.programlisting]
....
LICENSE=	LGPL21+
....

Quando o software fornece o arquivo de licença, use isto:

[.programlisting]
....
LICENSE=	LGPL21+
LICENSE_FILE=	${WRKSRC}/COPYING
....

====

Para as licenças predefinidas, as permissões padrão são `dist-mirror dist-sell pkg-mirror pkg-sell auto-accept`.

[[licenses-license-list]]
.Lista de Licenças Predefinidas
[cols="1,1,1,1", frame="none", options="header"]
|===
| Nome Curto
| Nome
| Grupo
| Permissões

|`AGPLv3`
|GNU Affero General Public License version 3
|`FSF GPL OSI`
|(padrão)

|`AGPLv3+`
|GNU Affero General Public License version 3 (ou maior)
|`FSF GPL OSI`
|(padrão)

|`APACHE10`
|Apache License 1.0
|`FSF`
|(padrão)

|`APACHE11`
|Apache License 1.1
|`FSF OSI`
|(padrão)

|`APACHE20`
|Apache License 2.0
|`FSF OSI`
|(padrão)

|`ART10`
|Artistic License version 1.0
|`OSI`
|(padrão)

|`ART20`
|Artistic License version 2.0
|`FSF GPL OSI`
|(padrão)

|`ARTPERL10`
|Artistic License (perl) version 1.0
|`OSI`
|(padrão)

|`BSD`
|BSD license Generic Version (deprecated)
|`FSF  OSI COPYFREE`
|(padrão)

|`BSD2CLAUSE`
|BSD 2-clause "Simplified" License
|`FSF OSI COPYFREE`
|(padrão)

|`BSD3CLAUSE`
|BSD 3-clause "New" or "Revised" License
|`FSF OSI COPYFREE`
|(padrão)

|`BSD4CLAUSE`
|BSD 4-clause "Original" or "Old" License
|`FSF`
|(padrão)

|`BSL`
|Boost Software License
|`FSF OSI COPYFREE`
|(padrão)

|`CC-BY-1.0`
|Creative Commons Attribution 1.0
|
|(padrão)

|`CC-BY-2.0`
|Creative Commons Attribution 2.0
|
|(padrão)

|`CC-BY-2.5`
|Creative Commons Attribution 2.5
|
|(padrão)

|`CC-BY-3.0`
|Creative Commons Attribution 3.0
|
|(padrão)

|`CC-BY-4.0`
|Creative Commons Attribution 4.0
|
|(padrão)

|`CC-BY-NC-1.0`
|Creative Commons Attribution Non Commercial 1.0
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-2.0`
|Creative Commons Attribution Non Commercial 2.0
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-2.5`
|Creative Commons Attribution Non Commercial 2.5
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-3.0`
|Creative Commons Attribution Non Commercial 3.0
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-4.0`
|Creative Commons Attribution Non Commercial 4.0
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-ND-1.0`
|Creative Commons Attribution Non Commercial No Derivatives 1.0
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-ND-2.0`
|Creative Commons Attribution Non Commercial No Derivatives 2.0
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-ND-2.5`
|Creative Commons Attribution Non Commercial No Derivatives 2.5
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-ND-3.0`
|Creative Commons Attribution Non Commercial No Derivatives 3.0
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-ND-4.0`
|Creative Commons Attribution Non Commercial No Derivatives 4.0
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-SA-1.0`
|Creative Commons Attribution Non Commercial Share Alike 1.0
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-SA-2.0`
|Creative Commons Attribution Non Commercial Share Alike 2.0
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-SA-2.5`
|Creative Commons Attribution Non Commercial Share Alike 2.5
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-SA-3.0`
|Creative Commons Attribution Non Commercial Share Alike 3.0
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-NC-SA-4.0`
|Creative Commons Attribution Non Commercial Share Alike 4.0
|
|`dist-mirror pkg-mirror auto-accept`

|`CC-BY-ND-1.0`
|Creative Commons Attribution No Derivatives 1.0
|
|(padrão)

|`CC-BY-ND-2.0`
|Creative Commons Attribution No Derivatives 2.0
|
|(padrão)

|`CC-BY-ND-2.5`
|Creative Commons Attribution No Derivatives 2.5
|
|(padrão)

|`CC-BY-ND-3.0`
|Creative Commons Attribution No Derivatives 3.0
|
|(padrão)

|`CC-BY-ND-4.0`
|Creative Commons Attribution No Derivatives 4.0
|
|(padrão)

|`CC-BY-SA-1.0`
|Creative Commons Attribution Share Alike 1.0
|
|(padrão)

|`CC-BY-SA-2.0`
|Creative Commons Attribution Compartilhar Alike 2.0
|
|(padrão)

|`CC-BY-SA-2.5`
|Creative Commons Attribution Share Alike 2.5
|
|(padrão)

|`CC-BY-SA-3.0`
|Creative Commons Attribution Share Alike 3.0
|
|(padrão)

|`CC-BY-SA-4.0`
|Creative Commons Attribution Share Alike 4.0
|
|(padrão)

|`CC0-1.0`
|Creative Commons Zero v1.0 Universal
|`FSF GPL COPYFREE`
|(padrão)

|`CDDL`
|Common Development and Distribution License
|`FSF OSI`
|(padrão)

|`CPAL-1.0`
|Common Public Attribution License
|`FSF OSI`
|(padrão)

|`ClArtistic`
|Clarified Artistic License
|`FSF GPL OSI`
|(padrão)

|`EPL`
|Eclipse Public License
|`FSF OSI`
|(padrão)

|`GFDL`
|GNU Free Documentation License
|`FSF`
|(padrão)

|`GMGPL`
|GNAT Modified General Public License
|`FSF GPL OSI`
|(padrão)

|`GPLv1`
|GNU General Public License version 1
|`FSF GPL OSI`
|(padrão)

|`GPLv1+`
|GNU General Public License version 1 (or later)
|`FSF GPL OSI`
|(padrão)

|`GPLv2`
|GNU General Public License version 2
|`FSF GPL OSI`
|(padrão)

|`GPLv2+`
|GNU General Public License version 2 (or later)
|`FSF GPL OSI`
|(padrão)

|`GPLv3`
|GNU General Public License version 3
|`FSF GPL OSI`
|(padrão)

|`GPLv3+`
|GNU General Public License version 3 (or later)
|`FSF GPL OSI`
|(padrão)

|`GPLv3RLE`
|GNU GPL version 3 Runtime Library Exception
|`FSF GPL OSI`
|(padrão)

|`GPLv3RLE+`
|GNU GPL version 3 Runtime Library Exception (or later)
|`FSF GPL OSI`
|(padrão)

|`ISCL`
|Internet Systems Consortium License
|`FSF GPL OSI COPYFREE`
|(padrão)

|`LGPL20`
|GNU Library General Public License version 2.0
|`FSF GPL OSI`
|(padrão)

|`LGPL20+`
|GNU Library General Public License version 2.0 (or later)
|`FSF GPL OSI`
|(padrão)

|`LGPL21`
|GNU Lesser General Public License version 2.1
|`FSF GPL OSI`
|(padrão)

|`LGPL21+`
|GNU Lesser General Public License version 2.1 (or later)
|`FSF GPL OSI`
|(padrão)

|`LGPL3`
|GNU Lesser General Public License version 3
|`FSF GPL OSI`
|(padrão)

|`LGPL3+`
|GNU Lesser General Public License version 3 (or later)
|`FSF GPL OSI`
|(padrão)

|`LPPL10`
|LaTeX Project Public License version 1.0
|`FSF OSI`
|`dist-mirror dist-sell`

|`LPPL11`
|LaTeX Project Public License version 1.1
|`FSF OSI`
|`dist-mirror dist-sell`

|`LPPL12`
|LaTeX Project Public License version 1.2
|`FSF OSI`
|`dist-mirror dist-sell`

|`LPPL13`
|LaTeX Project Public License version 1.3
|`FSF OSI`
|`dist-mirror dist-sell`

|`LPPL13a`
|LaTeX Project Public License version 1.3a
|`FSF OSI`
|`dist-mirror dist-sell`

|`LPPL13b`
|LaTeX Project Public License version 1.3b
|`FSF OSI`
|`dist-mirror dist-sell`

|`LPPL13c`
|LaTeX Project Public License version 1.3c
|`FSF OSI`
|`dist-mirror dist-sell`

|`MIT`
|MIT license / X11 license
|`COPYFREE FSF GPL OSI`
|(padrão)

|`MPL10`
|Mozilla Public License version 1.0
|`FSF OSI`
|(padrão)

|`MPL11`
|Mozilla Public License version 1.1
|`FSF OSI`
|(padrão)

|`MPL20`
|Mozilla Public License version 2.0
|`FSF OSI`
|(padrão)

|`NCSA`
|University of Illinois/NCSA Open Source License
|`COPYFREE FSF GPL OSI`
|(padrão)

|`NONE`
|No license specified
|
|`none`

|`OFL10`
|SIL Open Font License version 1.0 (http://scripts.sil.org/OFL)
|`FONTS`
|(padrão)

|`OFL11`
|SIL Open Font License version 1.1 (http://scripts.sil.org/OFL)
|`FONTS`
|(padrão)

|`OWL`
|Open Works License (owl.apotheon.org)
|`COPYFREE`
|(padrão)

|`OpenSSL`
|Licença OpenSSL
|`FSF`
|(padrão)

|`PD`
|Public Domain
|`GPL COPYFREE`
|(padrão)

|`PHP202`
|PHP License version 2.02
|`FSF OSI`
|(padrão)

|`PHP30`
|PHP License version 3.0
|`FSF OSI`
|(padrão)

|`PHP301`
|PHP License versão 3.01
|`FSF OSI`
|(padrão)

|`PSFL`
|Python Software Foundation License
|`FSF GPL OSI`
|(padrão)

|`PostgreSQL`
|PostgreSQL License
|`FSF GPL OSI COPYFREE`
|(padrão)

|`RUBY`
|Ruby License
|`FSF`
|(padrão)

|`UNLICENSE`
|The Unlicense
|`COPYFREE FSF GPL`
|(padrão)

|`WTFPL`
|Do What the Fuck You Want To Public License version 2
|`GPL FSF COPYFREE`
|(padrão)

|`WTFPL1`
|Do What the Fuck You Want To Public License version 1
|`GPL FSF COPYFREE`
|(padrão)

|`ZLIB`
|zlib License
|`GPL FSF OSI`
|(padrão)

|`ZPL21`
|Zope Public License version 2.1
|`GPL OSI`
|(padrão)
|===

[[licenses-license_perms]]
=== `LICENSE_PERMS` e `LICENSE_PERMS_NAME`

Permissões. Use `none` se vazio.

.Lista de Permissões de Licença
[[licenses-license_perms-dist-mirror]]
`dist-mirror`::
A redistribuição dos arquivos de distribuição é permitida. Os arquivos de distribuição serão adicionados ao FreeBSD CDN `MASTER_SITE_BACKUP`.
[[licenses-license_perms-no-dist-mirror]]
`no-dist-mirror`::
A redistribuição dos arquivos de distribuição é proibida. Isso é equivalente a <<porting-restrictions-restricted,`RESTRICT`>>. Os arquivos de distribuição _não_ serão adicionados ao FreeBSD CDN `MASTER_SITE_BACKUP`.
[[licenses-license_perms-dist-sell]]
`dist-sell`::
A venda de arquivos de distribuição é permitida. Os arquivos de distribuição estarão presentes nas imagens do instalador.
[[licenses-license_perms-no-dist-sell]]
`no-dist-sell`::
A venda de arquivos de distribuição é proibida. Isso é equivalente a <<porting-restrictions-no_cdrom,`NO_CDROM`>>.
[[licenses-license_perms-pkg-mirror]]
`pkg-mirror`::
É permitida a redistribuição gratuita do pacote. O pacote será distribuído na CDN de pacotes do FreeBSD https://pkg.freebsd.org/[https://pkg.freebsd.org/].
[[licenses-license_perms-no-pkg-mirror]]
`no-pkg-mirror`::
É proibida a redistribuição gratuita do pacote. Equivalente à definir <<porting-restrictions-no_package,`NO_PACKAGE`>>. O pacote _não_ será distribuído a partir da CDN de pacotes do FreeBSD https://pkg.freebsd.org/[https://pkg.freebsd.org/].
[[licenses-license_perms-pkg-sell]]
`pkg-sell`::
A venda do pacote é permitida. O pacote estará presente nas imagens do instalador.
[[licenses-license_perms-no-pkg-sell]]
`no-pkg-sell`::
A venda de pacotes é proibida. Isso é equivalente a definir <<porting-restrictions-no_cdrom,`NO_CDROM`>>. O pacote _não_ estará presente nas imagens do instalador.
[[licenses-license_perms-auto-accept]]
`auto-accept`::
A licença é aceita por padrão. Os prompts para aceitar uma licença não são exibidos a menos que o usuário tenha definido `LICENSES_ASK`. Use isto, a menos que a licença indique que o usuário deve aceitar os termos da licença.
[[licenses-license_perms-no-auto-accept]]
`no-auto-accept`::
A licença não é aceita por padrão. O usuário sempre será solicitado a confirmar a aceitação desta licença. Isso deve ser usado se a licença declarar que o usuário deve aceitar seus termos.

Quando ambos `_permission_` e `no-_permission_` estiverem presentes o `no-_permission_` vai cancelar a `_permission_`.

Quando `_permission_` não estiver presente, é considerado uma `no-_permission_`.

[WARNING]
====

Algumas permissões que estiverem faltando, impedirão que um port (e todos os ports dependendo dele) sejam utilizados pelos usuários do pacote:

Um port sem a permissão `auto-accept` nunca será compilado e todos os ports dependendo dele serão ignorados.

Um port sem a permissão `pkg-mirror` será removido, assim como todos os ports que dependam dele, isso depois da compilação e então eles nunca serão distribuídos.
====

[[licenses-license_perms-ex1]]
.Licença Não Padrão
[example]
====
Leia os termos da licença e traduza-os usando as permissões disponíveis.

[.programlisting]
....
LICENSE=        UNKNOWN
LICENSE_NAME=   unknown
LICENSE_TEXT=   Esse programa NÃO é de domínio publico.\
                pode ser distribuído livremente para propósitos não comerciais apenas,\
                e NÃO HÁ GARANTIA PARA ESSE PROGRAMA.
LICENSE_PERMS=  dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept
....

====

[[licenses-license_perms-ex2]]
.Licenças Padrão e Não Padrão
[example]
====
Leia os termos da licença e expresse-os usando as permissões disponíveis. Em caso de dúvida, peça orientação na http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports[lista de discussão de ports do FreeBSD].

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

Quando as permissões das licenças GPLv2 e UNKNOWN são misturadas, o port termina com `dist-mirror dist-sell pkg-mirror pkg-sell auto-accept dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept`. O `no-_permissions_` cancela as _permissions_. A lista resultante de permissões é _dist-mirror pkg-mirror auto-accept_. Os arquivos de distribuição e os pacotes não estarão disponíveis nas imagens do instalador.
====

[[licenses-license_groups]]
=== `LICENSE_GROUPS` e `LICENSE_GROUPS_NAME`

Grupos que a licença pertence.

.Lista de Grupos de Licenças Predefinidas
[[licenses-license_groups-FSF]]
`FSF`::
Aprovada pela Free Software Foundation, veja http://www.fsf.org/licensing[FSF Licensing & Compliance Team].

[[licenses-license_groups-GPL]]
`GPL`::
Compatível com GPL

[[licenses-license_groups-OSI]]
`OSI`::
Aprovado pelo OSI, veja a pagina Open Source Initiative http://opensource.org/licenses[Open Source Licenses].

[[licenses-license_groups-COPYFREE]]
`COPYFREE`::
Segue a Copyfree Standard Definition, consulte a pagina http://copyfree.org/standard/licenses[Copyfree Licenses].

[[licenses-license_groups-FONTS]]
`FONTS`::
Licenças de fonte

[[licenses-license_name]]
=== `LICENSE_NAME` e `LICENSE_NAME_NAME`

Nome completo da licença.

[[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` e `LICENSE_FILE_NOME`

Caminho completo para o arquivo que contém o texto da licença, geralmente [.filename]#${WRKSRC}/some/file#. Se o arquivo não estiver no distfile e seu conteúdo for muito longo para ser colocado em <<licenses-license_text,`LICENSE_TEXT`>>, insira o texto em um novo arquivo em [.filename]#${FILESDIR}#.

[[licenses-license_file-ex1]]
.`LICENSE_FILE`
[example]
====
[.programlisting]
....
LICENSE=	GPLv3+
LICENSE_FILE=	${WRKSRC}/COPYING
....

====

[[licenses-license_text]]
=== `LICENSE_TEXT` e `LICENSE_TEXT_NAME`

Texto para usar como uma licença. Útil quando a licença não está nos arquivos de distribuição e seu texto é curto.

[[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` e `LICENSE_DISTFILES_NAME`

Os arquivos de distribuição aos quais as licenças se aplicam. O padrão é para todos os arquivos de distribuição.

[[licenses-license_distfiles-ex1]]
.`LICENSE_DISTFILES`
[example]
====
Usado quando os arquivos de distribuição não possuem a mesma licença. Por exemplo, um possui uma licença de código e outro possui alguns trabalhos de arte que não podem ser redistribuídos:

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

Defina como `multi` se todas as licenças se aplicarem. Defina como `dual` se qualquer uma das licenças se aplica. O padrão é definido para `single`.

[[licenses-license_comb-ex1]]
.Licenças Duplas
[example]
====
Quando um port diz "This software may be distributed under the GNU General Public License or the Artistic License">, isso significa que qualquer licença pode ser usada. Use isto:

[.programlisting]
....
LICENSE=	ART10 GPLv1
LICENSE_COMB=   dual
....

Se os arquivos de licença forem fornecidos, use assim:

[.programlisting]
....
LICENSE=	ART10 GPLv1
LICENSE_COMB=   dual
LICENSE_FILE_ART10=     ${WRKSRC}/Artistic
LICENSE_FILE_GPLv1=     ${WRKSRC}/Copying
....

====

[[licenses-license_comb-ex2]]
.Múltiplas Licenças
[example]
====
Quando parte de um port tem uma licença, e outra parte tem uma licença diferente, use `multi`:

[.programlisting]
....
LICENSE=	GPLv2 LGPL21+
LICENSE_COMB=	multi
....

====

[[makefile-portscout]]
== `PORTSCOUT`

Portscout é um utilitário de verificação de distfile automatizado para a Coleção de Ports do FreeBSD, descrito em detalhes em crossref:keeping-up[distfile-survey,Portscout: o Scanner de Distfile de Ports do FreeBSD].

`PORTSCOUT` define condições especiais dentro das quais o scanner distfile do Portscout é restrito.

Situações em que o `PORTSCOUT` é configurado:

* Quando distfiles precisam ser ignorados, seja para versões específicas, ou para pequenas revisões específicas. Por exemplo, para excluir a versão _8.2_ das verificações de versão de distfile porque é conhecido por estar quebrado, adicione:
+
[.programlisting]
....
PORTSCOUT=	ignore:8.2
....

* Quando versões específicas ou revisões maiores e menores específicas de um distfile devem ser verificadas. Por exemplo, se somente a versão _0.6.4_ deve ser monitorado porque versões mais recentes têm problemas de compatibilidade com o FreeBSD, adicione:
+
[.programlisting]
....
PORTSCOUT=	limit:^0\.6\.4
....

* Quando os URLs que listam as versões disponíveis diferem dos URLs de download. Por exemplo, para limitar as verificações de versão do arquivo distfile à página de download para o port package:databases/pgtune[], adicione:
+
[.programlisting]
....
PORTSCOUT=	site:http://pgfoundry.org/frs/?group_id=1000416
....

[[makefile-depend]]
== Dependências

Muitos ports dependem de outros ports. Esta é uma característica muito conveniente da maioria dos sistemas operacionais Unix-like, incluindo FreeBSD. Vários ports podem compartilhar uma dependência comum, ao invés de agrupar essa dependência com cada port ou pacote que precisa dela. Há sete variáveis ​​que podem ser usadas para garantir que todos os bits necessários estejam na máquina do usuário. Existem também algumas variáveis ​​de dependência pré-suportadas para casos comuns, além de algumas outras para controlar o comportamento das dependências.

[IMPORTANT]
====
Quando o software possui dependências extras que fornecem recursos extras, as dependências básicas listadas em `*_DEPENDS` devem incluir as dependências extras que beneficiariam a maioria dos usuários. As dependências básicas nunca devem ser um conjunto de dependências "mínima". O objetivo não é incluir todas as dependências possíveis. Inclua apenas aquelas que beneficiarão a maioria das pessoas.
====

[[makefile-lib_depends]]
=== `LIB_DEPENDS`

Esta variável especifica as bibliotecas compartilhadas das quais este port depende. É uma lista de tuplas _lib:dir_ onde _lib_ é o nome da biblioteca compartilhada, _dir_ é o diretório no qual encontrá-lo, caso não esteja disponível. Por exemplo,

[.programlisting]
....
LIB_DEPENDS=   libjpeg.so:graphics/jpeg
....

irá verificar se há uma biblioteca jpeg compartilhada com qualquer versão no subdiretório [.filename]#graphics/jpeg# da árvore de ports para compilar e instalar se não for encontrado.

A dependência é verificada duas vezes, uma vez dentro do target `build` e depois dentro do target `install`. Além disso, o nome da dependência é colocado no pacote para que o `pkg-install` (veja man:pkg-install[8]) a instale automaticamente se a mesma não estiver no sistema do usuário.

[[makefile-run_depends]]
=== `RUN_DEPENDS`

Esta variável especifica arquivos executáveis ou arquivos para os quais este port depende durante o tempo de execução. É uma lista de tuplas path:dir:[``target``] onde _path_ é o nome do executável ou arquivo,_dir_ é o diretório no qual encontrá-lo, caso não esteja disponível, e o _target_ é o target para chamar nesse diretório. E se o _path_ começar com uma barra (`/`), ele será tratado como um arquivo e sua existência é testada com `test -e`; caso contrário, é assumido como um executável e `which -s` é usado para determinar se o programa existe no caminho de pesquisa.

Por exemplo,

[.programlisting]
....
RUN_DEPENDS=	${LOCALBASE}/news/bin/innd:news/inn \
		xmlcatmgr:textproc/xmlcatmgr
....

irá verificar se o arquivo ou diretório [.filename]#/usr/local/news/bin/innd# existe, e compilar e instalá-lo a partir do subdiretório [.filename]#news/inn# da árvore de ports, caso não seja encontrado. Ele também verá se um executável chamado `xmlcatmgr` está no caminho de pesquisa em [.filename]#textproc/xmlcatmgr# para compilar e instalar se não for encontrado.

[NOTE]
====
Nesse caso, `innd` é na verdade um executável; se um executável estiver em um local que não deve estar no caminho de pesquisa, use o nome do caminho completo.
====

[NOTE]
====
A pesquisa oficial `PATH` usado no cluster de construção de ports é

[.programlisting]
....
/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
....

====

A dependência é verificada a partir do target `install`. Além disso, o nome da dependência é colocado no pacote para que o `pkg-install` (veja man:pkg-install[8]) a instale automaticamente se a mesma não estiver no sistema do usuário. A parte _target_ pode ser omitida se for igual a `DEPENDS_TARGET`.

Uma situação bastante comum é quando `RUN_DEPENDS` é literalmente o mesmo que `BUILD_DEPENDS`, especialmente se o software portado é escrito em uma linguagem de script ou se requer o mesmo ambiente de compilação e tempo de execução. Neste caso, é tentador e intuitivo atribuir diretamente um ao outro:

[.programlisting]
....
RUN_DEPENDS=	${BUILD_DEPENDS}
....

No entanto, essa atribuição pode poluir as dependências de tempo de execução com entradas não definidas no `BUILD_DEPENDS` original do port. Isso acontece por causa de uma avaliação preguiçosa de atribuição de variáveis do man:make[1]. Considere um [.filename]#Makefile# com `USES_*`, que são processados ​​por [.filename]#ports/Mk/bsd.*.mk# para aumentar as dependências iniciais de compilação. Por exemplo, `USES=gmake` adiciona package:devel/gmake[] para `BUILD_DEPENDS`. Para evitar que essas dependências adicionais poluam `RUN_DEPENDS`, crie outra variável com o conteúdo atual de `BUILD_DEPENDS` e atribua-a para ambos `BUILD_DEPENDS` e `RUN_DEPENDS`:

[.programlisting]
....
MY_DEPENDS=	some:devel/some \
		other:lang/other
BUILD_DEPENDS=	${MY_DEPENDS}
RUN_DEPENDS=	${MY_DEPENDS}
....

[IMPORTANT]
====
_Não_ use `:=` para atribuir `BUILD_DEPENDS` para `RUN_DEPENDS` ou vice-versa. Todas as variáveis ​​são expandidas imediatamente, o que é exatamente a coisa errada a fazer e quase sempre um fracasso.
====

[[makefile-build_depends]]
=== `BUILD_DEPENDS`

Esta variável especifica executáveis ​​ou arquivos que este port requer para ser compilado. Como `RUN_DEPENDS`, ela é uma lista de tuplas path:dir:[``target``]. Por exemplo,

[.programlisting]
....
BUILD_DEPENDS=	unzip:archivers/unzip
....

irá procurar por um executável chamado `unzip`, e ir para o subdiretório [.filename]#archivers/unzip# da árvore de ports para compilar e instalar se não for encontrado.

[NOTE]
====
"build" aqui significa tudo, desde a extração até a compilação. A dependência é verificada a partir do target `extract`. A parte do _target_ pode ser omitida se for igual a `DEPENDS_TARGET`
====

[[makefile-fetch_depends]]
=== `FETCH_DEPENDS`

Esta variável especifica executáveis ​​ou arquivos que este port requer para fazer os downloads. Como os dois anteriores, é uma lista de tuplas path:dir:[``target``]. Por exemplo,

[.programlisting]
....
FETCH_DEPENDS=	ncftp2:net/ncftp2
....

irá procurar por um executável chamado `ncftp2` e ir para o subdiretório [.filename]#net/ncftp2# da árvore de ports para compilar e instalar se não for encontrado.

A dependência é verificada a partir do target `fetch`. A parte _target_ pode ser omitida se for igual a `DEPENDS_TARGET`.

[[makefile-extract_depends]]
=== `EXTRACT_DEPENDS`

Esta variável especifica executáveis ​​ou arquivos que este port requer para extração. Como no anterior, é uma lista de tuplas path:dir:[``target``]. Por exemplo,

[.programlisting]
....
EXTRACT_DEPENDS=	unzip:archivers/unzip
....

irá procurar por um executável chamado `unzip`, e ir para o subdiretório [.filename]#archivers/unzip# da árvore de ports para compilar e instalar se não for encontrado.

A dependência é verificada a partir do target `extract`. A parte _target_ pode ser omitida se for igual a `DEPENDS_TARGET`.

[NOTE]
====
Use esta variável somente se a extração ainda não funcionar (o padrão usa `tar`) e não funciona com `USES=tar`, `USES=lha` ou `USES=zip` descrito em crossref:uses[uses,Usando Macros `USES`].
====

[[makefile-patch_depends]]
=== `PATCH_DEPENDS`

Esta variável especifica executáveis ​​ou arquivos que este port requer para aplicar patches. Como no anterior, é uma lista de path:dir:[``target``]. Por exemplo,

[.programlisting]
....
PATCH_DEPENDS=	${NONEXISTENT}:java/jfc:extract
....

vai descer para o subdiretório [.filename]#java/jfc# da árvore de ports para extraí-lo.

A dependência é verificada a partir do target `patch`. A parte _target_ pode ser omitida se for igual a `DEPENDS_TARGET`.

[[makefile-uses]]
=== `USES`

Parâmetros podem ser adicionados para definir diferentes recursos e dependências usados ​​pelo port. Eles são especificados adicionando esta linha ao [.filename]#Makefile#:

[.programlisting]
....
USES= feature[:arguments]
....

Para a lista completa de valores, por favor veja o crossref:uses[uses,Usando Macros `USES`].

[WARNING]
====

`USES` não pode ser atribuído após a inclusão de [.filename]#bsd.port.pre.mk#.
====

[[makefile-use-vars]]
== 0 `USE_*`

Diversas variáveis ​​existem para definir dependências comuns compartilhadas por muitos ports. O uso é opcional, mas ajuda a reduzir a verbosidade dos [.filename]##Makefile##s de port . Cada um deles é denominado como `USES_*`. Essas variáveis ​​podem ser usadas apenas no [.filename]#Makefile# do port e [.filename]#ports/Mk/bsd.*.mk#. Elas não são destinadas a opções configuráveis ​​pelo usuário - use `PORT_OPTIONS` para esse propósito.

[NOTE]
====
É _sempre_ incorreto definir qualquer `USE_*` dentro de [.filename]#/etc/make.conf#. Por exemplo, definindo

[.programlisting]
....
USE_GCC=X.Y
....

(onde XY é o número da versão) adicionaria uma dependência do gccXY para cada port, incluindo `lang/gccXY` em si!
====

[[makefile-use-vars-table]]
.`USE_*`
[cols="1,1", frame="none", options="header"]
|===
| Variável
| Significa

|`USE_GCC`
a|

O port requer GCC (gcc ou {gcc-plus-plus}) para compilar. Alguns ports precisam de qualquer versão do GCC, algumas exigem versões modernas e recentes. Normalmente, é configurado para `qualquer` (neste caso, o GCC da base seria usado em versões do FreeBSD que ainda o possuem, ou o port `lang/gcc` seria instalado quando o compilador C/C++ padrão for o Clang); ou `yes` (significa usar sempre GCC estável e moderno do port `lang/gcc`). A versão exata também pode ser especificada, com um valor como `4.7`. A versão mínima exigida pode ser especificada como `4.6+`. O GCC do sistema base é usado quando satisfaz a versão solicitada, caso contrário, um compilador apropriado é compilado a partir do port, e `CC` e `CXX` são ajustados em conformidade.

[NOTE]
====
`USE_GCC` irá registrar uma dependência de tempo de compilação e uma de tempo de execução.
====

|===

Variáveis ​​relacionadas ao gmake e [.filename]#configure# são descritos em crossref:special[building, Mecanismos de Compilação], enquanto autoconf, automake  e libtool são descritos em crossref:special[using-autotools, Usando o GNU Autotools]. Variáveis relacionadas ao Perl ​são descritas em crossref:special[using-perl, Usando Perl]. Variáveis ​​X11 são listadas em crossref:special[using-x11, Usando o X11]. crossref:special[using-gnome, Usando o GNOME] lida com o GNOME e crossref:special[using-kde, Usando o KDE] com variáveis ​​relacionadas ao KDE. crossref:special[using-java, Usando Java] documenta variáveis ​​Java, enquanto crossref:special[using-php, Aplicações Web, Apache e PHP] contém informações sobre Apache, PHP e módulos PEAR. Python  é discutido em crossref:special[using-python, Usando Python], e Ruby em crossref:special[using-ruby, Usando Ruby]. crossref:special[using-sdl, Usando SDL] fornece variáveis ​​usadas para aplicações SDL e, finalmente, crossref:special[using-xfce, Usando o Xfce] contém informações sobre o Xfce.

[[makefile-version-dependency]]
=== Versão Mínima de uma Dependência

Uma versão mínima de uma dependência pode ser especificada em qualquer `*_DEPENDS`, exceto `LIB_DEPENDS`, usando esta sintaxe:

[.programlisting]
....
p5-Spiffy>=0.26:devel/p5-Spiffy
....

O primeiro campo contém um nome de pacote dependente, que deve corresponder à entrada no banco de dados de pacotes, um sinal de comparação e uma versão do pacote. A dependência é satisfeita se o p5-Spiffy-0.26 ou mais recente estiver instalado na máquina.

[[makefile-note-on-dependencies]]
=== Notas sobre Dependências

Como mencionado acima, o target padrão para chamar quando uma dependência é necessária é o `DEPENDS_TARGET`. Seu padrão é o `install`. Esta é uma variável de usuário; nunca é definido em um [.filename]#Makefile# de port. Se o port precisar de uma maneira especial de lidar com uma dependência, use a parte `:target` de `*_DEPENDS` em vez de redefinir `DEPENDS_TARGET`.

Quando rodar `make clean`, as dependências de port também são limpas automaticamente. Se isso não for desejável, defina `NOCLEANDEPENDS` no ambiente. Isto pode ser particularmente desejável se o port tiver algo que demore muito tempo para recompilar em sua lista de dependências, como o KDE, o GNOME ou o Mozilla.

Para depender de outro port incondicionalmente, use a variável `${NONEXISTENT}` no primeiro campo do `BUILD_DEPENDS` ou `RUN_DEPENDS`. Use isto somente quando o código fonte do outro port for necessário. Tempo de compilação pode ser economizado especificando o target também. Por exemplo

[.programlisting]
....
BUILD_DEPENDS=	${NONEXISTENT}:graphics/jpeg:extract
....

sempre descerá para o port `jpeg` e extrai-lo.

[[makefile-circular-dependencies]]
=== Dependências Circulares são Fatais

[IMPORTANT]
====
Não insira nenhuma dependência circular na árvore de ports!
====

A tecnologia de compilação de ports não tolera dependências circulares. Se uma for inserida, alguém, em algum lugar do mundo, terá sua instalação do FreeBSD quebrada quase que imediatamente, e muitos outros rapidamente terão o mesmo problema. Estes erros podem ser realmente difíceis de serem detectados. Em caso de dúvida, antes de fazer qualquer alteração, certifique-se de executar: `cd /usr/ports; make index`. Esse processo pode ser muito lento em máquinas mais antigas, mas pode evitar dor de cabeça para um grande número de pessoas, incluindo você.

[[makefile-automatic-dependencies]]
=== Problemas Causados ​​por Dependências Automáticas

Dependências devem ser declaradas explicitamente ou usando o <<makefile-options,framework OPTIONS>>. Usar outros métodos, como a detecção automática, dificulta a indexação, o que causa problemas para o gerenciamento de ports e pacotes.

[[makefile-automatic-dependencies-bad]]
.Declaração Errada de uma Dependência Opcional
[example]
====
[.programlisting]
....
.include <bsd.port.pre.mk>

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

====

O problema em tentar adicionar dependências automaticamente é que os arquivos e configurações fora de um port individual podem ser alterados a qualquer momento. Por exemplo: um índice é construído, depois um lote de ports é instalado. Mas um dos ports instala o arquivo testado. O índice então fica incorreto, porque um port instalado inesperadamente tem uma nova dependência. O índice ainda pode estar errado mesmo após a recriação, se outros ports também determinarem a necessidade de dependências com base na existência de outros arquivos.

[[makefile-automatic-dependencies-good]]
.Declaração Correta de uma Dependência Opcional
[example]
====
[.programlisting]
....
OPTIONS_DEFINE=	BAR
BAR_DESC=	Calling cellphones via bar

BAR_LIB_DEPENDS=	libbar.so:foo/bar
....

====

Testar variáveis ​​de opções é o método correto. Ele não causará inconsistências no índice de um lote de ports, desde que as opções tenham sido definidas antes da construção do índice. Scripts simples podem ser usados ​​para automatizar a compilação, instalação e atualização desses ports e seus pacotes.

[[makefile-masterdir]]
== Ports Slaves e `MASTERDIR`

Se o port precisar criar versões ligeiramente diferentes de pacotes fazendo com que uma variável (por exemplo, resolução ou tamanho de papel) assuma valores diferentes, crie um subdiretório por pacote para facilitar aos usuários a visualização do que fazer, mas tente compartilhar o máximo possível de arquivos entre os ports. Normalmente, usando variáveis ​​inteligentemente, apenas um [.filename]#Makefile# bem curto será necessário em todos, exceto em um dos diretórios. No [.filename]#Makefile# solitário, use `MASTERDIR` para especificar o diretório onde o restante dos arquivos estão. Além disso, use uma variável como parte de <<porting-pkgname,`PKGNAMESUFFIX`>> para que os pacotes tenham nomes diferentes.

Isso será melhor demonstrado por um exemplo. Isso é parte de [.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[] também tem todos os patches, arquivos de pacotes, etc. Rodando `make` nele, será assumido o valor padrão para a resolução (300) e o port será compilado normalmente.

Quanto às outras resoluções, este é o [.filename]#print/pkfonts360/Makefile#_completo_:

[.programlisting]
....
RESOLUTION=	360
MASTERDIR=	${.CURDIR}/../pkfonts300

.include	"${MASTERDIR}/Makefile"
....

([.filename]#print/pkfonts118/Makefile#, [.filename]#print/pkfonts600/Makefile#, e todos os outros são semelhantes). A definição de `MASTERDIR` diz ao [.filename]#bsd.port.mk# que o conjunto regular de subdiretórios como `FILESDIR` e `SCRIPTDIR` podem ser encontrados em [.filename]#pkfonts300#. A linha `RESOLUTION=360` irá substituir a linha `RESOLUTION=300` em [.filename]#pkfonts300/Makefile# e o port será compilado com a resolução definida para 360.

[[makefile-manpages]]
== Páginas de Manual

Se o port instala a sua árvore de manuais em outro lugar diferente de `PREFIX`, use `MANDIRS` para especificar esses diretórios. Note que os arquivos correspondentes às páginas de manual devem ser colocados no [.filename]#pkg-plist# junto com o resto dos arquivos. O propósito do `MANDIRS` é ativar a compactação automática de páginas de manual, portanto, os nomes dos arquivos são sufixados com [.filename]#.gz#.

[[makefile-info]]
== Arquivos de Informação

Se o pacote precisar instalar arquivos de informações GNU, liste-os na variável `INFO` (sem o sufixo `.info`), uma entrada por documento. Presume-se que esses arquivos estejam instalados em [.filename]#PREFIX/INFO_PATH#. Mude `INFO_PATH` se o pacote usa um local diferente. Contudo, isto não é recomendado. Essas entradas contêm apenas o caminho relativo para [.filename]#PREFIX/INFO_PATH#. Por exemplo, package:lang/gcc34[] instala arquivos de informações em [.filename]#PREFIX/INFO_PATH/gcc34# e `INFO` será algo assim:

[.programlisting]
....
INFO=	gcc34/cpp gcc34/cppinternals gcc34/g77 ...
....

O código apropriado de instalação/desinstalação será automaticamente adicionado ao arquivo [.filename]#pkg-plist# temporário antes do registro do pacote.

[[makefile-options]]
== Opções do Makefile

Muitas aplicações podem ser compiladas com configurações opcionais ou diferentes. Exemplos podem ser a escolha de linguagem natural (humana), GUI versus linha de comando ou qual tipo de banco de dados será suportado. Os usuários podem precisar de uma configuração diferente do padrão, portanto o sistema de ports fornece ganchos em que o autor do port pode usar para controlar qual variante será compilada. Suportar essas opções corretamente fará com que os usuários fiquem felizes, e efetivamente forneça dois ou mais ports pelo preço de um.

[[makefile-options-options]]
=== `OPTIONS`

[[makefile-options-background]]
==== Background

`OPTIONS_*` fornece ao usuário que está instalando o port uma caixa de diálogo mostrando as opções disponíveis e, em seguida, salva essas opções em [.filename]#${PORT_DBDIR}/${OPTIONS_NAME}/options#. Na próxima vez que o port for compilado, as opções serão reutilizadas. O padrão de `PORT_DBDIR` é [.filename]#/var/db/ports#. `OPTIONS_NAME` é a origem do port com um underline como o separador de espaço, por exemplo, package:dns/bind99[] será `dns_bind99`.

Quando o usuário executa `make config` (ou executa `make build` pela primeira vez), o framework verifica [.filename]#${PORT_DBDIR}/${OPTIONS_NAME}/options#. Se esse arquivo não existir, os valores de `OPTIONS_*` são usados ​​e uma caixa de diálogo é exibida onde as opções podem ser ativadas ou desativadas. Então as [.filename]#options# são salvas e as variáveis ​​configuradas são utilizadas ao compilar o port.

Se uma nova versão do port adicionar novas `OPTIONS`, a caixa de diálogo será apresentada ao usuário, já preenchido com os valores salvos das antigas `OPTIONS`.

`make showconfig` mostra a configuração salva. Use `make rmconfig` para remover a configuração salva.

[[makefile-options-syntax]]
==== Sintaxe

`OPTIONS_DEFINE` contém uma lista de `OPTIONS` para serem utilizadas. Elas são independentes umas das outras e não são agrupadas:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1 OPT2
....

Uma vez definido, as `OPTIONS` são descritas (opcionalmente, mas fortemente recomendado):

[.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# possui descrições para muitas `OPTIONS` comuns. Geralmente são úteis, mas podem ser substituas se a descrição for insuficiente para o port.

[TIP]
====

Ao descrever as opções, visualize-as da perspectiva do usuário: "Qual funcionalidade ela muda?" e "Por que eu iria querer habilitar ela?" Não repita apenas o nome. Por exemplo, descrever a opção `NLS` como "incluir suporte NLS" não ajuda o usuário, que já pode ver o nome da opção, mas pode não saber o que isso significa. Descrevendo-a como "Suporte a idiomas nativos por meio de utilitários gettext" é muito mais útil.
====

[IMPORTANT]
====
Os nomes das opções são sempre em letras maiúsculas. Não podem estar misturadas ou apenas em minúsculo.
====

`OPTIONS` podem ser agrupadas como opções radio, onde apenas uma escolha de cada grupo é permitida:

[.programlisting]
....
OPTIONS_SINGLE=		SG1
OPTIONS_SINGLE_SG1=	OPT3 OPT4
....

[WARNING]
====

_Deve_ estar sempre selecionada uma de cada `OPTIONS_SINGLE` para as opções serem válidas. Uma opção de cada grupo _deve_ ser adicionada a `OPTIONS_DEFAULT`.
====

`OPTIONS` podem ser agrupadas como opções radio, onde nenhuma ou apenas uma escolha de cada grupo é permitida:

[.programlisting]
....
OPTIONS_RADIO=		RG1
OPTIONS_RADIO_RG1=	OPT7 OPT8
....

`OPTIONS` também pode ser agrupadas como listas de "múltipla-escolha", onde _pelo menos uma_ opção deve estar habilitada:

[.programlisting]
....
OPTIONS_MULTI=		MG1
OPTIONS_MULTI_MG1=	OPT5 OPT6
....

`OPTIONS` também pode ser agrupadas como listas de "múltipla-escolha", onde nenhuma ou qualquer opção pode ser ativada:

[.programlisting]
....
OPTIONS_GROUP=		GG1
OPTIONS_GROUP_GG1=	OPT9 OPT10
....

`OPTIONS` são desativadas por padrão, a menos que estejam listadas em `OPTIONS_DEFAULT`:

[.programlisting]
....
OPTIONS_DEFAULT=	OPT1 OPT3 OPT6
....

Definições de `OPTIONS` devem aparecer antes da inclusão de [.filename]#bsd.port.options.mk#. Valores de `PORT_OPTIONS` só podem ser testados após a inclusão de [.filename]#bsd.port.options.mk#. Inclusão de [.filename]#bsd.port.pre.mk# pode ser usado também, e ainda é amplamente usado em ports escritos antes da introdução de [.filename]#bsd.port.options.mk#. Mas esteja ciente de que algumas variáveis não funcionarão como esperado após a inclusão de [.filename]#bsd.port.pre.mk#, tipicamente algumas flags `USE_*`.

[[ports-options-simple-use]]
.Uso Simples de `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 <bsd.port.mk>
....

====

[[ports-options-check-unset]]
.Verificar `OPTIONS` Desmacadas
[example]
====
[.programlisting]
....
.if ! ${PORT_OPTIONS:MEXAMPLES}
CONFIGURE_ARGS+=--without-examples
.endif
....

O formato acima não é recomendado. O método preferido é usar um configure knob para realmente ativar e desativar o recurso coincidindo com a opção:

[.programlisting]
....
# Will add --with-examples / --without-examples
EXAMPLES_CONFIGURE_WITH=	examples
....

====

[[ports-options-practical-use]]
.Uso Prático de `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 <bsd.port.mk>
....

====

[[makefile-options-default]]
==== Opções Padrão

Essas opções estão sempre ativadas por padrão.

* `DOCS` -- build and install documentation.
* `NLS` -- Native Language Support.
* `EXAMPLES` -- build and install examples.
* `IPV6` -- IPv6 protocol support.

[NOTE]
====
Não há necessidade de adicioná-las em `OPTIONS_DEFAULT`. Para ativá-las e mostra-las na caixa de diálogo de seleção de opções, elas devem ser adicionadas em `OPTIONS_DEFINE`.
====

[[makefile-options-auto-activation]]
=== Feature de Ativação Automática

Ao usar um script configure GNU, fique de olho em quais recursos opcionais são ativados por detecção automática. Desative explicitamente os recursos opcionais que não são necessários, adicionando `--without-xxx` ou `--disable-xxx` em `CONFIGURE_ARGS`.

[[makefile-options-auto-activation-bad]]
.Manipulação Incorreta de uma Opção
[example]
====
[.programlisting]
....
.if ${PORT_OPTIONS:MFOO}
LIB_DEPENDS+=		libfoo.so:devel/foo
CONFIGURE_ARGS+=	--enable-foo
.endif
....

====

No exemplo acima, imagine que uma biblioteca libfoo está instalada no sistema. O usuário não quer que este aplicativo use libfoo, então ele desabilitou a opção na caixa de diálogo do `make config`. Mas o script configure do aplicativo detecta a biblioteca presente no sistema e inclui seu suporte no executável resultante. Agora, quando o usuário decide remover libfoo do sistema, o sistema de ports não protesta (nenhuma dependência de libfoo foi registrada), e então o aplicativo quebra.

[[makefile-options-auto-activation-good]]
.Manuseio Correto de uma Opção
[example]
====
[.programlisting]
....
FOO_LIB_DEPENDS=		libfoo.so:devel/foo
# Will add --enable-foo / --disable-foo
FOO_CONFIGURE_ENABLE=	foo
....

====

[NOTE]
====
Sob algumas circunstâncias, a sintaxe condicional abreviada pode causar problemas com construções complexas. Os erros são geralmente `Malformed conditional`, e uma sintaxe alternativa pode ser usada.

[.programlisting]
....
.if !empty(VARIABLE:MVALUE)
....

como uma alternativa para

[.programlisting]
....
.if ${VARIABLE:MVALUE}
....

====

[[options-helpers]]
=== Assistentes de Opções

Existem algumas macros para ajudar a simplificar valores condicionais que diferem com base nas opções definidas. Para facilitar o acesso, é fornecida uma lista abrangente:

`PLIST_SUB`, `SUB_LIST`::
Para geração automática de `%%_OPT_%%` e `%%NO_OPT%%`, veja <<options_sub>>.
+
Para uso mais complexo, veja <<options-variables>>.

`CONFIGURE_ARGS`::
Para `--enable-_x_` e `--disable-_x_`, veja <<options-configure_enable>>.
+
Para `--with-_x_` e `--without-_x_`, veja <<options-configure_with>>.
+
Para todos os outros casos, veja <<options-configure_on>>.

`CMAKE_ARGS`::
Para argumentos que são booleanos (`on`, `off`, `true`, `false`, `0`, `1`) veja <<options-cmake_bool>>.
+
Para todos os outros casos, veja <<options-cmake_on>>.

`MESON_ARGS`::
Para argumentos que precisam de `true` ou `false`, veja <<options-meson_true>>.
+
Para argumentos que precisam de `yes` ou `no`, use <<options-meson_yes>>.
+
Para argumentos que precisam de `true` ou `false`, veja <<options-meson_enabled>>.
+
Para todos os outros casos, use <<options-meson_on>>.

`QMAKE_ARGS`::
Veja <<options-qmake_on>>.

`USE_*`::
Veja <<options-use>>.

`*_DEPENDS`::
Veja <<options-dependencies>>.

_*_ (Qualquer variável)::
As variáveis ​​mais usadas possuem assistentes diretos, veja <<options-variables>>.
+
Para qualquer variável sem um assistente específico, veja <<options-vars>>.

Dependências de opções::
Quando uma opção precisa de outra opção para funcionar, veja <<options-implies>>.

Conflitos de opções::
Quando uma opção não funciona se outra também estiver ativada, consulte <<options-prevents>>.

Targets para Build::
Quando uma opção precisa de algum processamento extra, veja <<options-targets>>.

[[options_sub]]
==== `OPTIONS_SUB`

Se `OPTIONS_SUB` está definido com `yes` então cada uma das opções adicionadas a `OPTIONS_DEFINE` será adicionada em `PLIST_SUB` e `SUB_LIST`, por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1
OPTIONS_SUB=	yes
....

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

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

[NOTE]
====
O valor de `OPTIONS_SUB` é ignorado. Definindo-o com qualquer valor irá adicionar entradas `PLIST_SUB` e `SUB_LIST` para _todas_ as opções.
====

[[options-use]]
==== `OPT_USE` e `OPT_USE_OFF`

Quando a opção _OPT_ é selecionada, para cada par `_key=value_` em `OPT_USE`, _value_ é anexado ao `USE_KEY` correspondente. E se _value_ tiver espaços, substitua-os por vírgulas e eles serão alterados de volta para espaços durante o processamento. `OPT_USE_OFF` funciona da mesma maneira, quando `OPT` _não for_ selecionada. Por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1
OPT1_USES=	xorg
OPT1_USE=	mysql=yes xorg=x11,xextproto,xext,xrandr
OPT1_USE_OFF=	openssl=yes
....

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

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

[[options-configure-helpers]]
==== Assistentes `CONFIGURE_ARGS`

[[options-configure_enable]]
===== `OPT_CONFIGURE_ENABLE`

Quando a opção _OPT_ é selecionada, para cada _valor_ em `OPT_CONFIGURE_ENABLE`, `--enable-_valor_` será anexado a `CONFIGURE_ARGS`. Quando a opção OPT _não for_ selecionada, `--disable-_valor_` será anexado a `CONFIGURE_ARGS`. Um argumento opcional pode ser especificado com um símbolo `=`. Este argumento é apenas anexado na entrada de opção do script configure `--enable-_valor_`. Por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1 OPT2
OPT1_CONFIGURE_ENABLE=	test1 test2
OPT2_CONFIGURE_ENABLE=	test2=exhaustive
....

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
CONFIGURE_ARGS+=	--enable-test1 --enable-test2
.else
CONFIGURE_ARGS+=	--disable-test1 --disable-test2
.endif

.if ${PORT_OPTIONS:MOPT2}
CONFIGURE_ARGS+=	--enable-test2=exhaustive
.else
CONFIGURE_ARGS+=	--disable-test2
.endif
....

[[options-configure_with]]
===== `OPT_CONFIGURE_WITH`

Quando a opção _OPT_ é selecionada, para cada _valor_ em `OPT_CONFIGURE_WITH`, `--with-_valor_` será anexado a `CONFIGURE_ARGS`. Quando a opção OPT_não for_ selecionada, `--without-_valor_` será anexado a `CONFIGURE_ARGS`. Um argumento opcional pode ser especificado com um símbolo `=`. Este argumento é apenas anexado na entrada de opção do script configure `--with-_valor_`. Por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1 OPT2
OPT1_CONFIGURE_WITH=	test1
OPT2_CONFIGURE_WITH=	test2=exhaustive
....

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1 OPT2

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
CONFIGURE_ARGS+=	--with-test1
.else
CONFIGURE_ARGS+=	--without-test1
.endif

.if ${PORT_OPTIONS:MOPT2}
CONFIGURE_ARGS+=	--with-test2=exhaustive
.else
CONFIGURE_ARGS+=	--without-test2
.endif
....

[[options-configure_on]]
===== `OPT_CONFIGURE_ON` e `OPT_CONFIGURE_OFF`

Quando a opção _OPT_ é selecionada, o valor de `OPT_CONFIGURE_ON`, se definido, é anexado a `CONFIGURE_ARGS`. `OPT_CONFIGURE_OFF` funciona da mesma maneira, quando `OPT` _não for_ selecionada. Por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1
OPT1_CONFIGURE_ON=	--add-test
OPT1_CONFIGURE_OFF=	--no-test
....

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

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

[TIP]
====

Na maioria das vezes, os assistentes em <<options-configure_enable>> e <<options-configure_with>> fornecem uma funcionalidade mais curta e abrangente.
====

[[options-cmake-helpers]]
==== Assistentes `CMAKE_ARGS`

[[options-cmake_on]]
===== `OPT_CMAKE_ON` e `OPT_CMAKE_OFF`

Quando a opção _OPT_ é selecionada, o valor de `OPT_CMAKE_ON`, se definido, é anexado a `CMAKE_ARGS`. `OPT_CMAKE_OFF` funciona da mesma maneira, mas quando `OPT` _não for_ selecionada. Por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1
OPT1_CMAKE_ON=	-DTEST:BOOL=true -DDEBUG:BOOL=true
OPT1_CMAKE_OFF=	-DOPTIMIZE:BOOL=true
....

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

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

[TIP]
====

Veja <<options-cmake_bool>> para um assistente mais curto quando o valor for booleano.
====

[[options-cmake_bool]]
===== `OPT_CMAKE_BOOL` e `OPT_CMAKE_BOOL_OFF`

Quando a opção _OPT_ é selecionada, para cada _valor_ em `OPT_CMAKE_BOOL`, `-Dvalor:BOOL=true` será anexado a `CMAKE_ARGS`. Quando a opção OPT_não for_ selecionada, `-Dvalor:BOOL=false` será anexado a `CONFIGURE_ARGS`. O `OPT_CMAKE_BOOL_OFF` é o oposto, `-Dvalor:BOOL=false` será anexado a `CMAKE_ARGS` quando a opção é selecionada, e a entrada `-Dvalor:BOOL=true` quando a opção _não for_ selecionada. Por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1
OPT1_CMAKE_BOOL=	TEST DEBUG
OPT1_CMAKE_BOOL_OFF=	OPTIMIZE
....

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

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

[[options-meson-helpers]]
==== Assistentes `MESON_ARGS`

[[options-meson_on]]
===== `OPT_MESON_ON` e `OPT_MESON_OFF`

Quando a opção _OPT_ é selecionada, o valor de `OPT_MESON_ON`, se definido, é anexado a `MESON_ARGS`. `OPT_MESON_OFF` funciona da mesma maneira, quando `OPT` _não for_ selecionada. Por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1
OPT1_MESON_ON=	-Dopt=1
OPT1_MESON_OFF=	-Dopt=2
....

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

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

[[options-meson_true]]
===== `OPT_MESON_TRUE` e `OPT_MESON_FALSE`

Quando a opção _OPT_ é selecionada, para cada _valor_ em `OPT_MESON_TRUE`, `-Dvalor=true` será anexado a `MESON_ARGS`. Quando a opção OPT_não for_ selecionada, `-Dvalor=false` será anexado a `MESON_ARGS`. O `OPT_MESON_FALSE` é o oposto, a entrada `-Dvalor=false` será anexado a `MESON_ARGS` quando a opção for selecionada e a entrada `-Dvalor=true` quando a opção _não for_ selecionada. Por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1
OPT1_MESON_TRUE=	test debug
OPT1_MESON_FALSE=	optimize
....

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

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

[[options-meson_yes]]
===== `OPT_MESON_YES` e `OPT_MESON_NO`

Quando a opção _OPT_ é selecionada, para cada _entrada_ dentro da variável `OPT_MESON_YES` a entrada `-D__=yes` é anexada a variável `MESON_ARGS`. Quando a opção OPT _não é_ selecionada, então a entrada `-D=no` é anexada a variável `MESON_ARGS`. O `OPT_MESON_NO` é o oposto, a entrada `-D=no` é anexada a variável `MESON_ARGS` quando a opção é selecionada e a entrada `-D=yes` quando a opção _não é_ selecionada. Por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1
OPT1_MESON_YES=	test debug
OPT1_MESON_NO=	optimize
....

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

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

[[options-meson_enabled]]
===== `OPT_MESON_ENABLED` e `OPT_MESON_DISABLED`

Quando a opção _OPT_ é selecionada, para cada _valor_ em `OPT_MESON_ENABLED`, `-Dvalor=enabled` será anexado a `MESON_ARGS`. Quando a opção OPT_não for_ selecionada, `-Dvalor=disabled` será anexado a `MESON_ARGS`. O `OPT_MESON_DISABLED` é o oposto, a entrada `-Dvalor=disabled` será anexado a `MESON_ARGS` quando a opção for selecionada e a entrada `-Dvalor=enabled` quando a opção _não for_ selecionada. Por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1
OPT1_MESON_ENABLED=	test
OPT1_MESON_DISABLED=	debug
....

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
MESON_ARGS+=	-Dtest=enabled -Ddebug=disabled
.else
MESON_ARGS+=	-Dtest=disabled -Ddebug=enabled
.endif
....

[[options-qmake_on]]
==== `OPT_QMAKE_ON` e `OPT_QMAKE_OFF`

Quando a opção _OPT_ é selecionada, o valor de `OPT_QMAKE_ON`, se definido, é anexado a `QMAKE_ARGS`. `OPT_QMAKE_OFF` funciona da mesma maneira, quando `OPT` _não for_ selecionada. Por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1
OPT1_QMAKE_ON=	-DTEST:BOOL=true
OPT1_QMAKE_OFF=	-DPRODUCTION:BOOL=true
....

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

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

[[options-implies]]
==== `OPT_IMPLIES`

Fornece uma maneira de adicionar dependências entre as opções.

Quando _OPT_ for selecionada, todas as opções listadas nesta variável também serão selecionadas. Usando o <<options-configure_enable,`OPT_CONFIGURE_ENABLE`>> descrito anteriormente para demonstrar:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1 OPT2
OPT1_IMPLIES=	OPT2

OPT1_CONFIGURE_ENABLE=	opt1
OPT2_CONFIGURE_ENABLE=	opt2
....

É equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1 OPT2

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
CONFIGURE_ARGS+=	--enable-opt1
.else
CONFIGURE_ARGS+=	--disable-opt1
.endif

.if ${PORT_OPTIONS:MOPT2} || ${PORT_OPTIONS:MOPT1}
CONFIGURE_ARGS+=	--enable-opt2
.else
CONFIGURE_ARGS+=	--disable-opt2
.endif
....

[[options-implies-ex1]]
.Uso Simples de `OPT_IMPLIES`
[example]
====
Este port tem uma opção `X11` e uma opção `GNOME` que precisa da opção `X11` selecionada para poder compilar.

[.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` e `OPT_PREVENTS_MSG`

Fornece uma maneira de adicionar conflitos entre as opções.

Quando _OPT_ for selecionada, todas as opções listadas em `OPT_PREVENTS` devem estar desmarcadas. Se `OPT_PREVENTS_MSG` estiver definido e um conflito for acionado, seu conteúdo será exibido explicando o por que do conflito. Por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1 OPT2
OPT1_PREVENTS=	OPT2
OPT1_PREVENTS_MSG=	OPT1 and OPT2 enable conflicting options
....

É aproximadamente equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1 OPT2

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT2} && ${PORT_OPTIONS:MOPT1}
BROKEN=	Option OPT1 conflicts with OPT2 (select only one)
.endif
....

A única diferença é que o primeiro irá apresentar um erro depois de executar `make config`, sugerindo alterar as opções selecionadas.

[[options-prevents-ex1]]
.Uso Simples de `OPT_PREVENTS`
[example]
====
Este port tem as opções `X509` e `SCTP`. Ambas as opções adicionam patches, mas os patches entram em conflito uns com os outros, então eles não podem ser selecionados ao mesmo tempo.

[.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` e `OPT_VARS_OFF`

Fornece uma maneira genérica de definir e acrescentar valores em variáveis.

[WARNING]
====

Antes de usar `OPT_VARS` e `OPT_VARS_OFF`, veja se já não existe um assistente mais específico disponível em <<options-variables>>.
====

Quando a opção _OPT_ está selecionada e `OPT_VARS` definido, os pares `_chave_=_valor_` e `_chave_+=_valor_` são avaliados a partir da variável `OPT_VARS`. Um `=` sobrescreve o valor existente da `CHAVE`, um `+=` acrescenta o valor a chave. `OPT_VARS_OFF` funciona da mesma maneira, quando a opção `OPT` _não for_ selecionada.

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

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1 OPT2

MAKE_ARGS=	ALSO_BUILD="${ALSO_BUILD}" BIN3_BUILD="${BIN3_BUILD}"

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
ALSO_BUILD+=	bin1
.endif

.if ${PORT_OPTIONS:MOPT2}
ALSO_BUILD+=	bin2
.endif

.if ${PORT_OPTIONS:MOPT2}
BIN3_BUILD=	yes
.else
BIN3_BUILD=	no
.endif
....

[IMPORTANT]
====
Valores contendo espaços em branco devem ser colocados entre aspas:

[.programlisting]
....
OPT_VARS=	foo="bar baz"
....

Isso se deve ao jeito que a variável de expansão man:make[1] lida com espaço em branco. Quando a opção `OPT_VARS=foo=bar baz` é expandida, a variável acaba contendo duas strings, `foo=bar` e `baz`. Mas quem está submetendo o código provavelmente pretendia que houvesse apenas uma string, `foo=bar baz`. Inserir o valor entre aspas impede que o espaço em branco seja usado como um delimitador.

Além disso, _não_ adicione espaços extras após o símbolo `_var_=` e antes do valor, pois assim também seria dividido o valor em duas strings. _Isso não irá funcionar_:

[.programlisting]
....
OPT_VARS=	foo=	bar
....

====

[[options-dependencies]]
==== Dependências, `OPT_DEPTYPE_` e `OPT_DEPTYPE_OFF`

Para qualquer um desses tipos de dependência:

* `PKG_DEPENDS`
* `EXTRACT_DEPENDS`
* `PATCH_DEPENDS`
* `FETCH_DEPENDS`
* `BUILD_DEPENDS`
* `LIB_DEPENDS`
* `RUN_DEPENDS`

Quando opção _OPT_ é selecionada, o valor de `OPT_DEPTYPE`, se definido, é anexado a `_DEPTYPE_`. `OPT_DEPTYPE_OFF` funciona da mesma forma, quando `OPT` _não for_ selecionada. Por exemplo:

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

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
LIB_DEPENDS+=	liba.so:devel/a
.else
LIB_DEPENDS+=	libb.so:devel/b
.endif
....

[[options-variables]]
==== Substituição de Variáveis ​​Genéricas, `OPT_VARIABLE_` e `OPT_VARIABLE_OFF`

Para qualquer uma destas variáveis:

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

Quando a opção _OPT_ é selecionada, o valor da variável `OPT_ABOVEVARIABLE`, se definido, é anexado a `_ABOVEVARIABLE_`. `OPT_ABOVEVARIABLE_OFF` funciona da mesma maneira, quando `OPT` _não for_ selecionada. Por exemplo:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1
OPT1_USES=	gmake
OPT1_CFLAGS_OFF=	-DTEST
....

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

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

[NOTE]
====
Algumas variáveis ​​não estão nesta lista, em particular `PKGNAMEPREFIX` e `PKGNAMESUFFIX`. Isso é intencional. Um port _não deve_ mudar seu nome quando alguma de suas opções forem alteradas.
====

[WARNING]
====

Algumas dessas variáveis, pelo menos `ALL_TARGET`, `DISTFILES` e `INSTALL_TARGET`, tem seus valores padrão definidos _depois_ das opções serem processadas.

Com estas linhas no [.filename]#Makefile#:

[.programlisting]
....
ALL_TARGET=	all

DOCS_ALL_TARGET=	doc
....

Se a opção `DOCS` estiver ativada, `ALL_TARGET` terá o valor `all doc`; se a opção estiver desativada, ela terá o valor `all`.

Com apenas a linha do assistente de opções no [.filename]#Makefile#:

[.programlisting]
....
DOCS_ALL_TARGET=	doc
....

Se a opção `DOCS` estiver ativada, `ALL_TARGET` terá o valor `doc`; se a opção estiver desativada, ela terá o valor `all`.
====

[[options-targets]]
==== Targets Adicionais de Compilação, `_target_-_OPT_-on` e `_target_-_OPT_-off`

Estes targets de [.filename]#Makefile# podem aceitar targets extras de compilação:

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

Quando a opção _OPT_ é selecionada, o target `_TARGET_-_OPT_-on`, se definido, é executado após `_TARGET_`. `_TARGET_-_OPT_-off` funciona da mesma maneira, quando `OPT` _não for_ selecionada. Por exemplo:

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

é equivalente a:

[.programlisting]
....
OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

post-patch:
.if ${PORT_OPTIONS:MOPT1}
	@${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${EXAMPLESDIR}/|' ${WRKSRC}/Makefile
.else
	@${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${PREFIX}/bin/|' ${WRKSRC}/Makefile
.endif
....

[[makefile-wrkdir]]
== Especificando o Diretório de Trabalho

Cada port é extraído em um diretório de trabalho, que deve ter permissão de escrita. O sistema de ports tem por padrão os `DISTFILES` descompactado em um diretório chamado `${DISTNAME}`. Em outras palavras, se o [.filename]#Makefile# tem:

[.programlisting]
....
PORTNAME=	foo
DISTVERSION=	1.0
....

então os arquivos de distribuição do port contêm um diretório de nível superior, [.filename]#foo-1.0#, e o resto dos arquivos estão localizados nesse diretório.

Diversas variáveis ​​podem ser substituídas se não for esse o caso.

[[makefile-wrksrc]]
=== `WRKSRC`

A variável lista o nome do diretório que é criado quando os distfiles do aplicativo são extraídos. Se o exemplo anterior for extraído em um diretório chamado [.filename]#foo# (e não [.filename]#foo-1.0#) escreva:

[.programlisting]
....
WRKSRC=	${WRKDIR}/foo
....

ou possivelmente

[.programlisting]
....
WRKSRC=	${WRKDIR}/${PORTNAME}
....

[[makefile-wrksrc_subdir]]
=== `WRKSRC_SUBDIR`

Se o código fonte necessário para o port estiver em um subdiretório do arquivo de distribuição extraído, defina `WRKSRC_SUBDIR` para esse diretório.

[.programlisting]
....
WRKSRC_SUBDIR=	src
....

[[makefile-no_wrksubdir]]
=== `NO_WRKSUBDIR`

Se o port não extrair para nenhum subdiretório, então configure `NO_WRKSUBDIR` para indicar isso.

[.programlisting]
....
NO_WRKSUBDIR=	yes
....

[NOTE]
====
Porque `WRKDIR` é o único diretório que deve ter permissão de escrita durante a compilação e é usado para armazenar muitos arquivos que registram o status da compilação, a extração do port será forçada para um subdiretório.
====

[[conflicts]]
== Manipulando Conflitos

Existem três variáveis ​​diferentes para registrar um conflito entre pacotes e ports: `CONFLICTS`, `CONFLICTS_INSTALL` e `CONFLICTS_BUILD`.

[NOTE]
====
As variáveis ​​de conflito definem automaticamente a variável `IGNORE`, que é mais amplamente documentada em crossref:porting-dads[dads-noinstall,Marcando um Port não Instalável com a variável `BROKEN` `FORBIDDEN` ou `IGNORE`].
====

Ao remover um dos vários ports conflitados, é aconselhável reter `CONFLICTS` nos outros ports por alguns meses para atender usuários que apenas fazem atualizações de vez em quando.

[[conclicts-conflicts_install]]
`CONFLICTS_INSTALL`::
Se o pacote não puder coexistir com outros pacotes (devido a conflitos de arquivos, incompatibilidades de tempo de execução, etc.). A checagem `CONFLICTS_INSTALL` é feita após o estágio de compilação e antes do estágio de instalação.
[[conclicts-conflicts_build]]
`CONFLICTS_BUILD`::
Se o port não puder ser compilado quando outros ports específicos já estiverem instalados. Conflitos de compilação não serão registrados no pacote final.
[[conclicts-conflicts]]
`CONFLICTS`::
Se o port não puder ser compilado quando um certo port estiver instalado e o pacote final não puder coexistir com o outro pacote. A checagem `CONFLICTS` é feita antes do estágio de compilação e antes do estágio de instalação.

O conteúdo mais comum de uma dessas variáveis ​​é o pacote base de outro port. O pacote base é o nome do pacote sem a versão, ele pode ser obtido executando `make -V PKGBASE`.

[[conflicts-ex1]]
.Uso básico de `CONFLICTS_*`
[example]
====
package:dns/bind99[] não pode ser instalado se package:dns/bind910[] está presente porque eles instalam os mesmos arquivos. Primeiro, reúna o pacote base para usar:

[source,shell]
....
% make -C dns/bind99 -V PKGBASE
bind99
% make -C dns/bind910 -V PKGBASE
bind910
....

Então adicione ao [.filename]#Makefile# do package:dns/bind99[]:

[.programlisting]
....
CONFLICTS_INSTALL=	bind910
....

E adicione ao [.filename]#Makefile# do package:dns/bind910[]:

[.programlisting]
....
CONFLICTS_INSTALL=	bind99
....

====

Às vezes, apenas uma versão de outro port é incompatível, neste caso, use o nome completo do pacote, com a versão, e use shell globs, como `*` e `?` para garantir que todas as versões possíveis sejam correspondidas.

[[conflicts-ex2]]
.Usando `CONFLICTS_*` Com Globs.
[example]
====
Nas versões 2.0 até 2.4.1_2, package:deskutils/gnotime[] instalava uma versão integrada de package:databases/qof[].

Para refletir este passado, o [.filename]#Makefile# do package:database/qof[] contém:

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

As primeira entrada corresponde as versões `2.0` até `2.3`, a segunda corresponde todas as revisões de `2.4.0`, a terceira corresponde a versão exata `2.4.1`, e a última corresponde a primeira e segunda revisão da versão `2.4.1`.

package:deskutils/gnotime[] não possui nenhuma linha de conflitos porque sua versão atual não conflita com mais nada.
====

[[install]]
== Instalando Arquivos

[IMPORTANT]
====
O estágio `install` é muito importante para o usuário final porque ele adiciona arquivos ao sistema. Todos os comandos adicionais de estágios `*-install` dos [.filename]#Makefile#'s de port devem ser mostrados na tela. _Não_ silencie esses comandos com `@` ou `.SILENT`.
====

[[install-macros]]
=== Macros `INSTALL_*`

Use as macros fornecidas em [.filename]#bsd.port.mk# para garantir a propriedade correta dos arquivos nos targets `*-install` do port. Defina a propriedade diretamente em [.filename]#pkg-plist# com as entradas correspondentes, como `@(_owner_,_group_,)`, `@owner _owner_`, e `@group _group_`. Esses operadores funcionam até serem substituídos, ou até o final do [.filename]#pkg-plist#, lembre-se de redefini-los depois que eles não forem mais necessários. O valor de propriedade padrão é `root:wheel`. Veja crossref:plist[plist-keywords-base,Keywords Básicas] para maiores informações.

* `INSTALL_PROGRAM` é um comando para instalar executáveis ​​binários.
* `INSTALL_SCRIPT` é um comando para instalar scripts executáveis.
* `INSTALL_LIB` é um comando para instalar bibliotecas compartilhadas (mas não bibliotecas estáticas).
* `INSTALL_KLD` é um comando para instalar módulos carregáveis ​​do kernel. Algumas arquiteturas não gostam de ter os módulos otimizados (stripped), então use este comando em vez de `INSTALL_PROGRAM`.
* `INSTALL_DATA` é um comando para instalar dados compartilháveis, incluindo bibliotecas estáticas.
* `INSTALL_MAN` é um comando para instalar manpages e outras documentações (ele não realiza nenhuma compactação).

Estas variáveis ​​parametrizam o comando man:install[1] com as flags apropriadas para cada situação.

[IMPORTANT]
====
Não use `INSTALL_LIB` para instalar bibliotecas estáticas, porque otimiza-las (strip) torna-as sem utilidade. Use `INSTALL_DATA` neste caso.
====

[[install-strip]]
=== Otimizando (Stripping) Binários e Bibliotecas Compartilhadas

Os binários instalados devem ser otimizados (stripped). Não otimize (strip) os binários manualmente, a menos que seja absolutamente necessário. A macro `INSTALL_PROGRAM` instala e otimiza (strip) o binário ao mesmo tempo. A macro `INSTALL_LIB` faz o mesmo com as bibliotecas compartilhadas.

Quando um arquivo deve ser otimizado (stripped), mas as macros `INSTALL_PROGRAM` e `INSTALL_LIB` não são desejadas, `${STRIP_CMD}` otimiza (strips) o programa ou a biblioteca compartilhada. Isso geralmente é feito no target `post-install`. Por exemplo:

[.programlisting]
....
post-install:
	${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/xdl
....

Quando vários arquivos precisam ser otimizados (stripped):

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

Use man:file[1] em um arquivo para determinar se ele foi otimizado (stripped). Binários são relatados por man:file[1] como `stripped` ou `not stripped`. Além disso,man:strip[1] irá detectar programas que já foram otimizados (stripped) e retornar o comando sem erros.

[IMPORTANT]
====
Quando `WITH_DEBUG` estiver definido, os arquivos elf _não devem_ ser otimizados (stripped).

As variáveis ​​(`STRIP_CMD`, `INSTALL_PROGRAM`, `INSTALL_LIB`, ...) e crossref:uses[uses,`USES`] fornecidas pelo framework lidam com isso automaticamente.

Alguns softwares, adicionam `-s` em seus `LDFLAGS`, neste caso, ou remova o `-s` se `WITH_DEBUG` estiver definido, ou remova o incondicionalmente e use `STRIP_CMD` em `post-install`.
====

[[install-copytree]]
=== Instalando uma Árvore Inteira de Arquivos

Às vezes, um grande número de arquivos devem ser instalados preservando sua organização hierárquica. Por exemplo, copiando de uma árvore de diretórios inteira do `WRKSRC` para um diretório de destino sob `PREFIX`. Observe que `PREFIX`, `EXEMPLESDIR`, `DATADIR` e outras variáveis ​​de caminho sempre devem ser precedidas por `STAGEDIR` para respeitar o staging (ver crossref:special[staging,Staging]).

Existem duas macros para essa situação. A vantagem de usar essas macros em vez de `cp` é que elas garantem a propriedade e permissão adequada dos arquivos nos arquivos de destino. A primeira macro, `COPYTREE_BIN`, irá definir todos os arquivos instalados como sendo executáveis, sendo assim, adequado para instalações em [.filename]#PREFIX/bin#. A segunda macro,`COPYTREE_SHARE`, não define permissões de execução nos arquivos e, portanto, é adequado para instalar arquivos sob o destino [.filename]#PREFIX/share#.

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

Este exemplo irá instalar o conteúdo do diretório [.filename]#exemples# do distfile do fornecedor para o local de exemplos apropriado do port.

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

E este exemplo irá instalar os dados dos meses de verão no subdiretório [.filename]#summer# de um [.filename]#DATADIR#.

Argumentos `find` adicionais podem ser passados através do terceiro argumento para `COPYTREE_*`. Por exemplo, para instalar todos os arquivos do primeiro exemplo, exceto Makefiles, é possível usar esses comandos.

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

Essas macros não adicionam os arquivos instalados em [.filename]#pkg-plist#. Eles devem ser adicionados manualmente. Para documentação opcional (`PORTDOCS`, veja <<install-documentation>>) e exemplos (`PORTEXAMPLES`), os prefixos `%%PORTDOCS%%` ou `%%PORTEXAMPLES%%` devem ser prefixados no [.filename]#pkg-plist#.

[[install-documentation]]
=== Instalar Documentação Adicional

Se o software tiver alguma documentação diferente do manual padrão e páginas de informações úteis para o usuário, instale-os em `DOCSDIR`. Isso pode ser feito como no item anterior, no target `post-install`.

Crie um novo diretório para o port. O nome do diretório é `DOCSDIR`. Isso geralmente é igual a `PORTNAME`. No entanto, se o usuário desejar que versões diferentes do port sejam instaladas ao mesmo tempo, `PKGNAME` pode ser usado.

Já que apenas os arquivos listados no [.filename]#pkg-plist# são instalados, é seguro sempre instalar documentações no `STAGEDIR` (veja crossref:special[staging,Staging]). Por isso, blocos `.if` são necessários apenas quando os arquivos forem grandes o suficiente para causarem sobrecarga significativa de I/O.

[.programlisting]
....
post-install:
	${MKDIR} ${STAGEDIR}${DOCSDIR}
	${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${STAGEDIR}${DOCSDIR}
....

Por outro lado, se houver uma opção DOCS no port, instale a documentação em um taget `post-install-DOCS-on`. Esses targets são descritos em <<options-targets>>.

Aqui estão algumas variáveis úteis e como elas são expandidas por padrão quando usadas no [.filename]#Makefile#:

* `DATADIR` é expandido para [.filename]#PREFIX/shared/PORTNAME#.
* `DATADIR_REL` é expandido para [.filename]#share/PORTNAME#.
* `DOCSDIR` é expandido para [.filename]#PREFIX/shared/doc/PORTNAME#.
* `DOCSDIR_REL` é expandido para [.filename]#share/doc/PORTNAME#.
* `EXEMPLESDIR` é expandido para [.filename]#PREFIX/shared/examples/PORTNAME#.
* `EXAMPLESDIR_REL` é expandido para [.filename]#share/examples/PORTNAME#.

[NOTE]
====
A opção `DOCS` controla apenas a documentação adicional instalada em `DOCSDIR`. Não se aplica a páginas de manual e páginas de informações padrão. Arquivos instalados em `EXEMPLESDIR` são controlados pela opção `EXEMPLES`.
====

Essas variáveis são exportadas para `PLIST_SUB`. Quando possível, seus valores aparecerão como nomes de caminho relativos ao [.filename]#PREFIX#. Isso é, por padrão [.filename]#share/doc/PORTNAME# será substituído por `%%DOCSDIR%%` na lista de empacotamento e assim por diante. (Saiba mais sobre substituições [.filename]#pkg-plist#<<plist-sub,aqui>>.)

Todos os arquivos e diretórios de documentação instalados condicionalmente são incluídos no [.filename]#pkg-plist# com o prefixo `%%PORTDOCS%%`, por exemplo:

[.programlisting]
....
%%PORTDOCS%%%%DOCSDIR%%/AUTHORS
%%PORTDOCS%%%%DOCSDIR%%/CONTACT
....

Como uma alternativa para listar os arquivos de documentação em [.filename]#pkg-plist#, um port pode definir a variável `PORTDOCS` com uma lista de nomes de arquivo e padrões shell glob para adicionar à lista de empacotamento final. Os nomes serão relativos a `DOCSDIR`. Portanto, um port que utiliza `PORTDOCS` e usa um local não padrão para sua documentação, deve definir `DOCSDIR` adequadamente. Se um diretório estiver listado em `PORTDOCS` ou ser correspondido por um padrão glob dessa variável, toda a sub árvore de arquivos e diretórios contidos serão registrados na lista final de empacotamento. Se a opção `DOCS` estiver desmarcada, os arquivos e diretórios listados em `PORTDOCS` não serão instalados ou adicionados à lista de empacotamento do port. A instalação da documentação em `PORTDOCS` como mostrado acima fica a cargo do port. Um exemplo típico de utilização `PORTDOCS`:

[.programlisting]
....
PORTDOCS=	README.* ChangeLog docs/*
....

[NOTE]
====
O equivalente de `PORTDOCS` para arquivos instalados em `DATADIR` e `EXEMPLESDIR` são `PORTDATA` e `PORTEXAMPLES`, respectivamente.

O conteúdo de [.filename]#pkg-message# é exibido na instalação. Veja <<porting-message,a seção sobre o uso do [.filename]#pkg-message#>> para mais detalhes. [.filename]#pkg-message# não precisa ser adicionado ao [.filename]#pkg-plist#.
====

[[install-subdirs]]
=== Subdiretórios Sob `PREFIX`

Tente deixar o port colocar os arquivos nos subdiretórios corretos de `PREFIX`. Alguns ports juntam tudo e colocam os arquivos em um subdiretório com o nome do port, o que é incorreto. Além disso, muitos ports colocam todos arquivos, exceto binários, arquivos header e páginas de manual, em um subdiretório de [.filename]#lib#, o que não funciona bem com o paradigma BSD. Muitos dos arquivos devem ser movidos para um desses diretórios: [.filename]#etc#(setup/arquivos de configuração), [.filename]#libexec# (executáveis ​​iniciados internamente), [.filename]#sbin# (executáveis ​​para super-usuários/gerentes), [.filename]#info# (documentação para o navegador de informações) ou [.filename]#share# (arquivos independentes de arquitetura). Veja man:hier[7] para detalhes; as regras que regem [.filename]#/usr# praticamente se aplicam a [.filename]#/usr/local# também. A exceção são os ports que lidam com "notícias" USENET. Eles podem usar [.filename]#PREFIX/news# como um destino para seus arquivos.

[[binary-alias]]
== Use `BINARY_ALIAS` para Renomear Comandos Em Vez de Aplicar Patch na Compilação

Quando `BINARY_ALIAS` é definido, ele criará links simbólicos dos comandos fornecidos, em um diretório que será prefixado para o `PATH`.

Use-o para substituir comandos codificados na fase de compilação sem ter aplicar nenhum patch nos arquivos de compilação.

[[binary-alias-ex1]]
.Usando `BINARY_ALIAS` para Deixar `gsed` Disponível como `sed`
[example]
====
Alguns ports esperam que o `sed` se comporte como o GNU sed e utilizam recursos que o man:sed[1] não possui. GNU sed está disponível em package:textproc/gsed[] no FreeBSD.

Use `BINARY_ALIAS` para substituir `sed` com `gsed` durante a compilação:

[.programlisting]
....
BUILD_DEPENDS=	gsed:textproc/gsed
...
BINARY_ALIAS=	sed=gsed
....

====

[[binary-alias-ex2]]
.Usando `BINARY_ALIAS` Para Fornecer Aliases para Comandos `python3` Codificado
[example]
====
Um port que possui uma referência codificada para `python3` em seus scripts de compilação precisará ter ele disponível no `PATH` em tempo de compilação. Use `BINARY_ALIAS` para criar um alias que aponte para o binário certo do Python 3:

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

Veja crossref:special[using-python,Usando Python] para mais informações sobre `USES=python`.
====

[NOTE]
====
Aliases binários são criados após as dependências fornecidas via `BUILD_DEPENDS` e `LIB_DEPENDS` serem processadas e antes do target `configure`. Isso leva a várias limitações. Por exemplo, os programas instalados via `TEST_DEPENDS` não podem ser usados para criar um alias binário, pois as dependências de teste especificadas desta forma são processadas após a criação dos aliases binários.
====