# Capítulo 5. Configurando o Makefile

Esta tradução pode estar desatualizada. Para ajudar com as traduções, acesse a ferramenta de traduções do FreeBSD.

Configurar o Makefile é bastante simples e, novamente, sugerimos examinar os exemplos existentes antes de começar. Além disso, há um 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 Makefile:

## 5.1. O Código Fonte Original

Ele está em `DISTDIR` como um tarball `gzip` e é chamado de algo como 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.

### 5.1.1. Nomeando

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

### 5.1.2. `PORTNAME`

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

| 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 `PKGNAMEPREFIX` ou `PKGNAMESUFFIX`.

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

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

| Ao atualizar um port, é possível usar o pkg-version(8)`-t` para verificar se a nova versão é maior ou menor do que antes. Veja Usando pkg-version(8) para comparar versões..

Exemplo 1. Usando pkg-version(8) para comparar versões.

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

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

1 | `1.2` é menor que `1.3`.
2 | `1.2` e `1.2` são iguais, pois têm a mesma versão.
3 | `1.2` e `1.2.0` são iguais, pois valor vazio é igual a zero.
4 | `1.2` é maior que `1.2.p1` por causa do `.p1`, pense em "pre-release 1".
5 | `1.2.a1` é menor que `1.2.b1`, pense em "alfa" e "beta" e `a` é menor que `b`.
6 | `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`.

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

Tabela 1. Exemplos de `DISTVERSION` e de Derivações `PORTVERSION`
DISTVERSION | PORTVERSION
--- | ---
0.7.1d | 0.7.1.d
10Alpha3 | 10.a3
3Beta7-pre2 | 3.b7.p2
8:f_17 | 8f.17

Exemplo 2. Usando `DISTVERSION`

Quando a versão contém apenas números separados por pontos, traços ou sublinhados, use `DISTVERSION`.

    PORTNAME=   nekoto
    DISTVERSION=	1.2-4

Isso irá gerar um `PORTVERSION 1.2.4`.

Exemplo 3. Usando `DISTVERSION` Quando a Versão Começa com uma Letra ou um Prefixo

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

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

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

    PORTNAME=   nekoto
    DISTVERSION=	1.2-4
    DISTVERSIONSUFFIX=  _RELEASE

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

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

Exemplo 4. Usando `DISTVERSION` Quando a Versão Contém Letras Significando "alpha", "beta" ou "pre-release"

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

    PORTNAME=   nekoto
    DISTVERSION=	1.2-pre4

    PORTNAME=   nekoto
    DISTVERSION=	1.2p4

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

    % pkg version -t 1.2.p4 1.2
    <

Exemplo 5. Não use `DISTVERSION` Quando a Versão Contém Letras que Significam "Nível de Patch"

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

    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.pkg-version(8) irá constatar isso:

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

1 | `1.2` é maior que `1.2.p4`, o que é errado nesse caso.
2 | `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 `DISTNAME`.

### 5.1.4. `PORTREVISION` e `PORTEPOCH`

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

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

#### 5.1.4.2. `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).

| Os resultados das comparações de números de versão nem sempre são óbvios. `pkg version` (veja pkg-version(8)) pode ser usado para testar a comparação de duas sequências de números de versão. Por exemplo:
    % 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 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.

#### 5.1.4.3. Exemplo de Uso `PORTREVISION` e `PORTEPOCH`

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

    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.

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

    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:

    PORTNAME=	gtkmumble
    DISTVERSION=	0.3
    PORTEPOCH=	1

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

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

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

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

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

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 textproc/libxml2 ou 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 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`.

-compiled.specifics

  Se o port pode ser construído com diferentes 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`.

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

| 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 `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 Makefile:

Tabela 2. Exemplos de Nomes de Pacotes
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.

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

## 5.2. Categorização

### 5.2.1. `CATEGORIES`

Quando um pacote é criado, ele é colocado em /usr/ports/packages/All e links são feitos de um ou mais subdiretórios de /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 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 abaixo para mais informação sobre como escolher as categorias certas.

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

| Para categorias não virtuais, há uma descrição de uma linha em `COMMENT` no Makefile desse subdiretório.

Categoria | Descrição | Notas
--- | --- | ---
accessibility | Ports para ajudar usuários com deficiências. |
afterstep `*` | Ports para apoiar o gerenciador de janelas AfterStep. |
arabic | Suporte ao idioma árabe". |
archivers | Ferramentas de arquivamento. |
astro | Ports astronômicos. |
audio | Suporte de som. |
benchmarks | Utilitários de benchmarking. |
biology | Software relacionado à biologia. |
cad | Ferramentas de desenho assistidas por computador. |
chinese | Suporte ao idioma chinês. |
comms | Software de comunicação. | Principalmente software para falar com o port serial.
converters | Conversores de código de caracteres. |
databases | Bancos de dados. |
deskutils | Coisas que costumavam estar na área de trabalho antes dos computadores serem inventados. |
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.
dns | Software relacionado ao DNS. |
docs `*` | Meta-ports para documentação do FreeBSD. |
editors | Editores gerais. | Editores especializados entram na seção para essas ferramentas. Por exemplo, um editor de fórmula matemática math, e tem editores como uma segunda categoria.
elisp `*` | Emacs-lisp ports. |
emulators | Emuladores para outros sistemas operacionais. | Emuladores de terminal não estão aqui. Os baseados em X vão para o x11 e baseados em texto para qualquer comms ou misc, dependendo da funcionalidade exata.
enlightenment `*` | Ports relacionados com o gerenciador de janelas Enlightenment. |
finance | Aplicações monetárias, financeiras e relacionadas. |
french | Suporte ao idioma francês. |
ftp | Utilitários de cliente e servidor deFTP. | Se o port fala com FTP e HTTP, coloque-o em ftp com uma categoria secundária de www.
games | Jogos. |
geography `*` | Software relacionado à geografia. |
german | Suporte ao idioma alemão. |
gnome `*` | Ports do Projeto GNOME. |
gnustep `*` | Software relacionado ao ambiente de desktop GNUstep. |
graphics | Utilitários gráficos. |
hamradio `*` | Software para rádio amador. |
haskell `*` | Software relacionado à linguagem Haskell. |
hebrew | Suporte ao idioma hebraico. |
hungarian | Suporte de idioma húngaro. |
irc | Utilitários do Internet Relay Chat. |
japanese | Suporte ao idioma japonês. |
java | Software relacionado à linguagem Java™. | A categoria 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 Java como a principal categoria de um port.
kde `*` | Ports do Projeto KDE (genérico). |
kde-applications `*` | Aplicações do Projeto KDE. |
kde-frameworks `*` | Bibliotecas add-on do Projeto KDE para programação com Qt. |
kde-plasma `*` | Desktop do Projeto KDE. |
kld `*` | Módulos carregáveis ​​do kernel. |
korean | Suporte ao idioma coreano. |
lang | Linguagens de programação. |
linux `*` | Aplicações Linux e utilitários de suporte. |
lisp `*` | Software relacionado à linguagem Lisp. |
mail | Mail software. |
mate `*` | Ports relacionado ao ambiente de desktop MATE, um fork do GNOME 2. |
math | Software de computação numérica e outras utilidades para matemática. |
mbone `*` | Aplicações MBone. |
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.
multimedia | Software multimídia. |
net | Software de rede diversos. |
net-im | Software de mensagens instantâneas. |
net-mgmt | Software de gerenciamento de rede. |
net-p2p | Aplicativos de rede peer to peer. |
net-vpn `*` | Aplicativos de Rede Privada Virtual. |
news | Software de notícias USENET. |
parallel `*` | Aplicativos que lidam com o paralelismo na computação. |
pear `*` | Ports relacionados ao framework PHP Pear. |
perl5 `*` | Ports que exigem Perl versão 5 para rodar. |
plan9 `*` | Vários programas de Plan9. |
polish | Suporte ao idioma polonês". |
ports-mgmt | Ports para gerenciar, instalar e desenvolver ports e pacotes do FreeBSD. |
portuguese | Suporte ao idioma Português. |
print | Software de Impressão. | As ferramentas de editoração eletrônica (pré-visualizadores etc.) também pertencem aqui.
python `*` | Software relacionado a linguagem Python. |
ruby `*` | Software relacionado a linguagem Ruby. |
rubygems `*` | Ports de pacotes RubyGems. |
russian | Suporte de idioma russo. |
scheme `*` | Software relacionado à linguagem Scheme. |
science | Ports científicos que não se encaixam em outras categorias, como astro, biologia e matemática. |
security | Utilitários de segurança. |
shells | Linha de comando do shell. |
spanish `*` | Suporte ao idioma espanhol. |
sysutils | Utilidades do sistema. |
tcl `*` | Ports que usam o Tcl para rodar. |
textproc | Utilitários de processamento de texto. | Não inclui ferramentas de editoração eletrônica, que vão para print.
tk `*` | Ports que usam o Tk para rodar. |
ukrainian | Suporte de idioma Ucraniano. |
vietnamese | Suporte de idioma Vietnamita. |
wayland `*` | Ports para suportar o servidor de display Wayland. |
windowmaker `*` | Ports para suportar o gerenciador de janelas do WindowMaker. |
www | Software relacionado à World Wide Web. | O suporte ao idioma HTML também pertence aqui.
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 x11- * (veja abaixo).
x11-clocks | X11 relógios. |
x11-drivers | Drivers X11. |
x11-fm | Gerentes de arquivos X11. |
x11-fonts | Fontes X11 e utilitários de fonte. |
x11-servers | Servidores X11. |
x11-themes | X11 temas. |
x11-toolkits | Kits de ferramentas X11. |
x11-wm | Gerentes de janela do X11. |
xfce `*` | Ports relacionados com o ambiente de trabalho Xfce. |
zope `*` | Zope suporte. |

### 5.2.3. 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 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 japanese x11-fonts.

- Categorias específicas são listadas antes de outras menos específicas. Por exemplo, um editor de HTML é listado como www editors, e não ao contrário. Além disso, não insira net quando o port pertencer a qualquer uma das categorias irc, mail, news, security ou www, pois net está incluída implicitamente.

- x11 é usado como uma categoria secundária somente quando a categoria principal é uma linguagem natural. Em particular, não coloque 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 editors. Por exemplo, um mode Emacs para editar código fonte de alguma linguagem de programação entra em lang.

- Ports que instalam módulos do kernel carregáveis ​​também têm a categoria virtual kld na sua linha `CATEGORIES`. Esta é uma das coisas tratadas automaticamente adicionando `USES=kmod`.

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

Se a categoria não estiver claramente definida, por favor, insira um comentário sobre isso na submissão do port no banco de dados de bugs, para que possamos discuti-lo antes de importá-lo. Como committer, envie uma mensagem para a 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.

### 5.2.4. 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 quantidade grande de trabalho 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:

1. Proponha a nova categoria na 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.

2. Participe da discussão.

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

   - Makefiles para os novos ports, uma vez que sejam recopiados

   - Makefile para a nova categoria

   - Makefile para as categorias dos ports antigos

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

4. 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 portmgr@FreeBSD.org.

5. Se esse PR for aprovado, um committer precisará seguir o restante do procedimento que é descrito no Guia do Committer.

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.

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

## 5.3. Os Arquivos de Distribuição

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

### 5.3.1. `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 é 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.

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

Exemplo 6. Derivando `PORTVERSION` Manualmente

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 pkg-version(8):

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

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

No Makefile do port, por exemplo dns/bind99, é alcançado por:

    PORTNAME=	bind
    PORTVERSION=	${ISCVERSION:S/-P/P/:S/b/.b/:S/a/.a/:S/rc/.rc/} (1)
    CATEGORIES=	dns net
    MASTER_SITES=	ISC/bind9/${ISCVERSION} (2)
    PKGNAMESUFFIX=	99
    DISTNAME=	${PORTNAME}-${ISCVERSION} (3)

    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 (4)

1 | Defina a versão upstream em `ISCVERSION`, com um comentário dizendo porque é necessário.
2 | Use `ISCVERSION` para obter um `PORTVERSION` compatível com o ports.
3 | Use `ISCVERSION` diretamente para obter a URL correta para baixar o arquivo de distribuição.
4 | Use `ISCVERSION` diretamente para nomear o arquivo de distribuição.

Exemplo 7. Derivar `DISTNAME` a partir de `PORTVERSION`

De tempos em tempos, o nome do arquivo de distribuição tem pouca ou nenhuma relação com a versão do software.

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

    PORTNAME=	kermit
    PORTVERSION=	9.0.304
    CATEGORIES=	comms ftp net
    MASTER_SITES=	ftp://ftp.kermitproject.org/kermit/test/tar/
    DISTNAME=	cku${PORTVERSION:E}-dev20 (1)

1 | O modificador `:E` make(1) retorna o sufixo da variável, neste caso, `304`. O arquivo de distribuição `cku304-dev20.tar.gz` é gerado corretamente.

Exemplo 8. Caso Exótico 1

À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 audio/libworkman:

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

Exemplo 9. Caso Exótico 2

No comms/librs232, o arquivo de distribuição não é versionado, portanto, `DIST_SUBDIR` é necessário:

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

| `PKGNAMEPREFIX` e `PKGNAMESUFFIX` não afetam o `DISTNAME`. Observe também que se `WRKSRC` for igual a ${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`).

### 5.3.2. `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 (/)!

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.

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

#### 5.3.2.1. 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:

    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:

    MASTER_SITES=		${MASTER_SITE_GNU}
    MASTER_SITE_SUBDIR=	make

Estes valores e variáveis ​​são definidos em 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.

| Para qualquer variável `MASTER_SITE_FOO` , a versão abreviada `FOO` pode ser utilizada. Por exemplo, use:
    MASTER_SITES=	FOO
E se `MASTER_SITE_SUBDIR` for necessário, use isso:
    MASTER_SITES=	FOO/bar

| Alguns nomes `MASTER_SITE_*` são bastante longos e, para facilitar o uso, foram definidos atalhos:
Tabela 3. Atalhos para Macros `MASTER_SITE_*`
Macro | Atalho
--- | ---
`PERL_CPAN` | `CPAN`
`GITHUB` | `GH`
`GITHUB_CLOUD` | `GHC`
`LIBREOFFICE_DEV` | `LODEV`
`NETLIB` | `NL`
`RUBYGEMS` | `RG`
`SOURCEFORGE` | `SF`

#### 5.3.2.2. 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:

    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:

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

Isso também pode ser escrito como

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

Tabela 4. Macros Mágicas de `MASTER_SITES`
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]).*/\1/}`
`GNU` | `${PORTNAME}`
`GNUPG` | `${PORTNAME}`
`GNU_ALPHA` | `${PORTNAME}`
`HORDE` | `${PORTNAME}`
`LODEV` | `${PORTNAME}`
`MATE` | `${PORTVERSION:C/^(\.[0-9]).*/\1/}`
`MOZDEV` | `${PORTNAME:tl}`
`NL` | `${PORTNAME}`
`QT` | `archive/qt/${PORTVERSION:R}`
`SAMBA` | `${PORTNAME}`
`SAVANNAH` | `${PORTNAME:tl}`
`SF` | `${PORTNAME:tl}/${PORTNAME:tl}/${PORTVERSION}`

### 5.3.3. `USE_GITHUB`

Se o arquivo de distribuição vier de um commit ou tag específico no 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:

Tabela 5. `USE_GITHUB` Descrição
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 Baixando Múltiplos Arquivos do GitHub 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. |

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

Exemplo 10. Uso Simples de `USE_GITHUB`

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 Makefile acabaria ficando assim (levemente simplificado para o exemplo):

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

Exemplo 11. Uso Mais Completo de `USE_GITHUB`

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 Makefile acaba ficando assim (levemente simplificado para o exemplo):

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

| `20140411` é a data do commit referenciada em `GH_TAGNAME`, não a data em que é editado o Makefile, ou a data em que o commit é feito.

Exemplo 12. Uso de `USE_GITHUB` com `DISTVERSIONPREFIX`

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

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

Exemplo 13. Usando `USE_GITHUB` Quando o Upstream Não Usa Versões

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

    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 Usando pkg-version(8) para comparar versões. para mais informações do pkg-version(8)):

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

Exemplo 14. Usando `USE_GITHUB` para Acessar um Commit Entre Duas Versões

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 git-describe(1) para descobrir a versão a ser utilizada:

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

    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 Usando pkg-version(8) para comparar versões. para detalhes do pkg-version(8)):

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

| Se o commit solicitado é o mesmo que uma tag, uma descrição mais curta é mostrada por padrão. A versão mais longa é equivalente:
    % git describe --tags c66c71d
    v0.7.3
    % git describe --tags --long c66c71d
    v0.7.3-0-gc66c71d

#### 5.3.3.1. 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 Múltiplos Arquivos de Distribuição ou Patches de Vários Locais.

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 `USE_GITHUB` Descrição.

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

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

| 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 Múltiplos Arquivos de Distribuição ou Patches de Vários Locais

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:

    USE_GITHUB=	nodefault

| Ao utilizar `USE_GITHUB=nodefault`, o Makefile deve ter `DISTFILES` em seu bloco inicial. A definição deve ser:
    DISTFILES=    ${DISTNAME}${EXTRACT_SUFX}

Exemplo 15. Uso de `USE_GITHUB` com Vários Arquivos de Distribuição

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_*`:

    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 foo/foo versão `1.0.2`. O segundo, com o grupo `icons`, vem de bar/foo-icons versão `1.0`. O terceiro vem de bar/foo-contrib e usa o commit do Git `fa579bc`. Os arquivos de distribuição são nomeados foo-foo-1.0.2_GH0.tar.gz, bar-foo-icons-1.0_GH0.tar.gz e 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, ${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á ${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 ext/icons em seus fontes, então `GH_SUBDIR` é usado. `GH_SUBDIR` garante que ext exista, mas não que ext/icons também exista. Então isso acontece:

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

Exemplo 16. Uso de `USE_GITHUB` com Vários Arquivos de Distribuição Usando `GH_TUPLE`

Isto é funcionalmente equivalente a Uso de `USE_GITHUB` com Vários Arquivos de Distribuição mas usando `GH_TUPLE`:

    PORTNAME=	foo
    DISTVERSION=	1.0.2

    USE_GITHUB=	yes
    GH_TUPLE=	bar:foo-icons:1.0:icons/ext/icons \
    		bar:foo-contrib:fa579bc:contrib

    CONFIGURE_ARGS=	--with-contrib=${WRKSRC_contrib}

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.

Exemplo 17. Como Usar `USE_GITHUB` com Submodulos Git?

Ports com o GitHub como um repositório upstream às vezes usam submódulos. Veja 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 finances/moneymanagerex como exemplo, seu repositório GitHub é https://github.com/moneymanagerex/moneymanagerex. Tem um arquivo .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:

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

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

| 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 Makefile pode ser escrito (somente as linhas relacionadas ao GitHub são mostradas):

    PORTNAME=	moneymanagerex
    DISTVERSIONPREFIX=	v
    DISTVERSION=	1.3.0

    USE_GITHUB=	yes
    GH_TUPLE=	utelle:wxsqlite3:v3.4.0:wxsqlite3/lib/wxsqlite3 \
    		moneymanagerex:LuaGlue:c51d11a:lua_glue/3rd/LuaGlue \
    		moneymanagerex:html-template:cd434ee:html_template/3rd/cgitemplate \
    		cesanta:mongoose:2140e59:mongoose/3rd/mongoose \
    		[...]

### 5.3.4. `USE_GITLAB`

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

Tabela 6. `USE_GITLAB` Descrição
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 Baixando Múltiplos Arquivos do GitLab 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. |

Exemplo 18. Uso Simples de `USE_GITLAB`

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 Makefile acabaria ficando assim para buscar os arquivos de distribuição:

    PORTNAME=	libsignon-glib
    DISTVERSION=	1.14

    USE_GITLAB=	yes
    GL_ACCOUNT=	accounts-sso
    GL_COMMIT=	e90302e342bfd27bc8c9132ab9d0ea3d8723fd03

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

Exemplo 19. Uso Mais Completo de `USE_GITLAB`

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 Makefile acaba ficando assim para buscar os arquivos de distribuição:

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

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

| O protocolo, porta e webroot do `GL_SITE` podem ser modificados na mesma variável.

#### 5.3.4.1. 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 Múltiplos Arquivos de Distribuição ou Patches de Vários Locais e Baixando Múltiplos Arquivos do GitLab.

Vários valores são adicionados a `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT` e `GL_COMMIT`. Cada valor diferente é atribuído a um grupo. `USE_GITLAB` Descrição.

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

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

| 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 Múltiplos Arquivos de Distribuição ou Patches de Vários Locais

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:

    USE_GITLAB=	nodefault

| Ao utilizar `USE_GITLAB=nodefault`, o Makefile deve ter `DISTFILES` em seu bloco inicial. A definição deve ser:
    DISTFILES=    ${DISTNAME}${EXTRACT_SUFX}

Exemplo 20. Uso de `USE_GITLAB` com Vários Arquivos de Distribuição

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_*`:

    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 https://gitlab.com/foo/foo e o commit é `c189207a55da45305c884fe2b50e086fcad4724b`. O segundo, com o grupo `icons`, vem de https://gitlab.example.com:9434/gitlab/bar/foo-icons e o commit é `ae7368cab1ca7ca754b38d49da064df87968ffe4`. O terceiro vem de https://gitlab.com/bar/foo-contrib e o commit é `9e4dd76ad9b38f33fdb417a4c01935958d5acd2a`. Os arquivos de distribuição são nomeados foo-foo-c189207a55da45305c884fe2b50e086fcad4724b_GL0.tar.gz, bar-foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4_GL0.tar.gz e 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, ${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 ${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 ext/icons em seus fontes, então `GL_SUBDIR` é usado.`GL_SUBDIR` garante que ext existe, mas não que ext/icons também exista. Então isso acontece:

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

Exemplo 21. Uso de `USE_GITLAB` com Vários Arquivos de Distribuição Usando `GL_TUPLE`

Isto é funcionalmente equivalente a Uso de `USE_GITLAB` com Vários Arquivos de Distribuição mas usando `GL_TUPLE`:

    PORTNAME=	foo
    DISTVERSION=	1.0.2

    USE_GITLAB=	yes
    GL_COMMIT=	c189207a55da45305c884fe2b50e086fcad4724b
    GL_TUPLE=	https://gitlab.example.com:9434/gitlab:bar:foo-icons:ae7368cab1ca7ca754b38d49da064df87968ffe4:icons/ext/icons \
    		bar:foo-contrib:9e4dd76ad9b38f33fdb417a4c01935958d5acd2a:contrib

    CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib}

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.

### 5.3.5. `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 foo.tar.gzip em vez do mais comum foo.tar.gz, escreva:

    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 Usando Macros `USES` para mais detalhes. Se nenhum destes estiver definido, o `EXTRACT_SUFX` padrão é `.tar.gz`.

| Como `EXTRACT_SUFX` é usado apenas em `DISTFILES`, apenas defina um deles..

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

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

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

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

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

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

    EXTRACT_ONLY=

### 5.3.8. `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 .Z, .gz, .bz2 ou .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 bsd.port.mk irá aplicá-los automaticamente. Em particular, não copie os arquivos de patch em ${PATCHDIR}. Esse diretório pode não ter permissão de escrita.

| 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:
    PATCHFILES=	patch1 patch2:-p1
Isto não entra em conflito com o recurso de agrupamento de sites principais, adicionando um grupo também funciona:
    PATCHFILES=	patch2:-p1:source2

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

### 5.3.9. 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:

    DISTFILES=	alpha:0 beta:1

No OpenBSD, arquivo de distribuição alpha será associado com a variável `MASTER_SITES0` em vez da nossa comum `MASTER_SITES` e 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 beta é hospedado em todas as entradas do `MASTER_SITES` e 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.

| 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, enquantomake(1) está ok com nomes de variáveis ​​contendo traços, sh(1)não.

#### 5.3.9.1. 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 Informação Detalhada.

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, source1.tar.gz e source2.tar.gz, que deve ser baixado de dois sites diferentes. O Makefile do port incluiria linhas como Uso Simplificado de `MASTER_SITES:n` com Um Arquivo Por Site.

Exemplo 22. Uso Simplificado de `MASTER_SITES:n` com Um Arquivo Por Site

    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, source3.tar.gz, que é baixado do `ftp.example2.com`. O Makefile seria então escrito como Uso Simplificado de `MASTER_SITES:n` com Mais de Um Arquivo Por Site.

Exemplo 23. Uso Simplificado de `MASTER_SITES:n` com Mais de Um Arquivo Por Site

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

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

1. 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 ii). Além disso, `DEFAULT` é uma palavra de propósito especial (verifique o item 3).

2. Elementos pós-fixados com `:n` pertence ao grupo `n`, `:m` pertence ao grupo `m` e assim por diante.

3. 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 5).

   Esses exemplos são equivalentes, mas o primeiro é o preferido:

       MASTER_SITES=	alpha

       MASTER_SITES=	alpha:DEFAULT

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

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

       MASTER_SITES=	alpha alpha:SOME_SITE

       MASTER_SITES=	alpha:DEFAULT alpha:SOME_SITE

       MASTER_SITES=	alpha:SOME_SITE,DEFAULT

       MASTER_SITES=	alpha:DEFAULT,SOME_SITE

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

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

   1. 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 Uso Detalhado de `MASTER_SITES:n` no `MASTER_SITE_SUBDIR` e Uso Detalhado de `MASTER_SITES:n` com Vírgula, Vários Arquivos, Vários Sites e Vários Subdiretórios.

      Exemplo 24. Uso Detalhado de `MASTER_SITES:n` no `MASTER_SITE_SUBDIR`

          MASTER_SITE_SUBDIR=	old:n new/:NEW

      - Diretórios dentro do grupo `DEFAULT` → old:n

      - Diretórios dentro do grupo `NEW` → new

      Exemplo 25. Uso Detalhado de `MASTER_SITES:n` com Vírgula, Vários Arquivos, Vários Sites e Vários Subdiretórios

          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.

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

      - arquivo2 será baixado exatamente como o 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`

      - arquivo3 será obtido a partir de

        - `MASTER_SITE_OVERRIDE`

        - http://site3/

        - `MASTER_SITE_BACKUP`

      - arquivo4 será obtido a partir de

        - `MASTER_SITE_OVERRIDE`

        - http://site4/

        - http://site5/

        - http://site6/

        - http://site7/

        - http://site8/directory-one/

        - `MASTER_SITE_BACKUP`

      - arquivo5 será obtido a partir de

        - `MASTER_SITE_OVERRIDE`

        - `MASTER_SITE_BACKUP`

      - file6 será obtido a partir de

        - `MASTER_SITE_OVERRIDE`

        - http://site8/

        - `MASTER_SITE_BACKUP`

8. Como posso agrupar uma das macros especiais de bsd.sites.mk, por exemplo, SourceForge (`SF`)?

   Isso foi simplificado o máximo possível. Veja Uso Detalhado de `MASTER_SITES:n` com SourceForge (`SF`).

   Exemplo 26. Uso Detalhado de `MASTER_SITES:n` com SourceForge (`SF`)

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

   something.tar.gz será obtido por todos os sites do SourceForge.

9. 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 Uso Simplificado de `MASTER_SITES:n` com `PATCH_SITES`.

   Exemplo 27. Uso Simplificado de `MASTER_SITES:n` com `PATCH_SITES`

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

#### 5.3.9.3. O que Muda para os Ports? O que Não Funciona?

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

1. 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 Uso Detalhado de `MASTER_SITES:n` com Vírgula, Vários Arquivos, Vários Sites e Vários Subdiretórios.

   - `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 B para obter mais informações sobre esses novos tagets de port.

2. Novos Targets de Port

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

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

### 5.3.10. `DIST_SUBDIR`

Não deixe o /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, Makefile), defina `DIST_SUBDIR` com o nome do port (`${PORTNAME}` ou `${PKGNAMEPREFIX}${PORTNAME}`). Isso vai mudar o `DISTDIR` do padrão /usr/ports/distfiles para /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 (Configurar o `DISTDIR` explicitamente no Makefile não fará isso funcionar, então por favor use `DIST_SUBDIR`.)

| Isso não afeta o `MASTER_SITES` definido no Makefile.

## 5.4. `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 O desafio para os mantenedores de port.

| 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 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 Seção Ports do Guia dos Committers.

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 portmgr@FreeBSD.org ou pela Equipe de Oficias de Segurança 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 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 security-officer@FreeBSD.org reserva o direito de revogar ou substituir a propriedade de mantenedor por razões de segurança.

## 5.5. `COMMENT`

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

1. A string COMMENT deve ter 70 caracteres ou menos.

2. Não inclua o nome do pacote ou o número da versão do software.

3. O comentário deve começar com uma letra maiúscula e terminar sem um ponto final.

4. Não comece com um artigo indefinido (isto é, A ou Um).

5. Capitalize nomes como Apache, JavaScript ou Perl.

6. Use uma vírgula serial para listas de palavras: "verde, vermelho, e azul."

7. Verifique erros de ortografia.

Aqui está um exemplo:

    COMMENT=	Cat chasing a mouse all over the screen

A variável COMMENT vem depois da variável MAINTAINER no Makefile.

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

### 5.6.1. `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 Lista de Licenças Predefinidas, 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 Lista de Licenças Predefinidas), `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 Lista de Licenças Predefinidas. A lista atual está sempre disponível em Mk/bsd.licenses.db.mk.

Exemplo 28. Uso Mais Simples, Licenças Predefinidas

Quando o 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:

    LICENSE=	LGPL21+

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

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

Tabela 7. Lista de Licenças Predefinidas
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)

### 5.6.2. `LICENSE_PERMS` e `LICENSE_PERMS_NAME`

Permissões. Use `none` se vazio.

Lista de Permissões de Licença

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

`no-dist-mirror`

  A redistribuição dos arquivos de distribuição é proibida. Isso é equivalente a `RESTRICT`. Os arquivos de distribuição não serão adicionados ao FreeBSD CDN `MASTER_SITE_BACKUP`.

`dist-sell`

  A venda de arquivos de distribuição é permitida. Os arquivos de distribuição estarão presentes nas imagens do instalador.

`no-dist-sell`

  A venda de arquivos de distribuição é proibida. Isso é equivalente a `NO_CDROM`.

`pkg-mirror`

  É permitida a redistribuição gratuita do pacote. O pacote será distribuído na CDN de pacotes do FreeBSD https://pkg.freebsd.org/.

`no-pkg-mirror`

  É proibida a redistribuição gratuita do pacote. Equivalente à definir `NO_PACKAGE`. O pacote não será distribuído a partir da CDN de pacotes do FreeBSD https://pkg.freebsd.org/.

`pkg-sell`

  A venda do pacote é permitida. O pacote estará presente nas imagens do instalador.

`no-pkg-sell`

  A venda de pacotes é proibida. Isso é equivalente a definir `NO_CDROM`. O pacote não estará presente nas imagens do instalador.

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

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

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

Exemplo 29. Licença Não Padrão

Leia os termos da licença e traduza-os usando as permissões disponíveis.

    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

Exemplo 30. Licenças Padrão e Não Padrão

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 lista de discussão de ports do FreeBSD.

    LICENSE=        WARSOW GPLv2
    LICENSE_COMB=   multi
    LICENSE_NAME_WARSOW=    Warsow Content License
    LICENSE_FILE_WARSOW=    ${WRKSRC}/docs/license.txt
    LICENSE_PERMS_WARSOW=   dist-mirror pkg-mirror auto-accept

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.

### 5.6.3. `LICENSE_GROUPS` e `LICENSE_GROUPS_NAME`

Grupos que a licença pertence.

Lista de Grupos de Licenças Predefinidas

`FSF`

  Aprovada pela Free Software Foundation, veja FSF Licensing & Compliance Team.

`GPL`

  Compatível com GPL

`OSI`

  Aprovado pelo OSI, veja a pagina Open Source Initiative Open Source Licenses.

`COPYFREE`

  Segue a Copyfree Standard Definition, consulte a pagina Copyfree Licenses.

`FONTS`

  Licenças de fonte

### 5.6.4. `LICENSE_NAME` e `LICENSE_NAME_NAME`

Nome completo da licença.

Exemplo 31. `LICENSE_NAME`

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

### 5.6.5. `LICENSE_FILE` e `LICENSE_FILE_NOME`

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

Exemplo 32. `LICENSE_FILE`

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

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

Exemplo 33. `LICENSE_TEXT`

    LICENSE=        UNKNOWN
    LICENSE_NAME=   unknown
    LICENSE_TEXT=   This program is NOT in public domain.\
                    It can be freely distributed for non-commercial purposes only,\
                    and THERE IS NO WARRANTY FOR THIS PROGRAM.
    LICENSE_PERMS=  dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept

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

Exemplo 34. `LICENSE_DISTFILES`

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:

    MASTER_SITES=   SF/some-game
    DISTFILES=      ${DISTNAME}${EXTRACT_SUFX} artwork.zip

    LICENSE=        BSD3CLAUSE ARTWORK
    LICENSE_COMB=   dual
    LICENSE_NAME_ARTWORK=      The game artwork license
    LICENSE_TEXT_ARTWORK=      The README says that the files cannot be redistributed
    LICENSE_PERMS_ARTWORK=     pkg-mirror pkg-sell auto-accept
    LICENSE_DISTFILES_BSD3CLAUSE=   ${DISTNAME}${EXTRACT_SUFX}
    LICENSE_DISTFILES_ARTWORK= artwork.zip

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

Exemplo 35. Licenças Duplas

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:

    LICENSE=	ART10 GPLv1
    LICENSE_COMB=   dual

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

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

Exemplo 36. Múltiplas Licenças

Quando parte de um port tem uma licença, e outra parte tem uma licença diferente, use `multi`:

    LICENSE=	GPLv2 LGPL21+
    LICENSE_COMB=	multi

## 5.7. `PORTSCOUT`

Portscout é um utilitário de verificação de distfile automatizado para a Coleção de Ports do FreeBSD, descrito em detalhes em 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:

      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:

      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 databases/pgtune, adicione:

      PORTSCOUT=	site:http://pgfoundry.org/frs/?group_id=1000416

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

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

### 5.8.1. `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,

    LIB_DEPENDS=   libjpeg.so:graphics/jpeg

irá verificar se há uma biblioteca jpeg compartilhada com qualquer versão no subdiretório 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 pkg-install(8)) a instale automaticamente se a mesma não estiver no sistema do usuário.

### 5.8.2. `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,

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

irá verificar se o arquivo ou diretório /usr/local/news/bin/innd existe, e compilar e instalá-lo a partir do subdiretório 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 textproc/xmlcatmgr para compilar e instalar se não for encontrado.

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

| A pesquisa oficial `PATH` usado no cluster de construção de ports é
    /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 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:

    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 make(1). Considere um Makefile com `USES_*`, que são processados ​​por ports/Mk/bsd.*.mk para aumentar as dependências iniciais de compilação. Por exemplo, `USES=gmake` adiciona 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`:

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

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

### 5.8.3. `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,

    BUILD_DEPENDS=	unzip:archivers/unzip

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

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

### 5.8.4. `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,

    FETCH_DEPENDS=	ncftp2:net/ncftp2

irá procurar por um executável chamado `ncftp2` e ir para o subdiretório 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`.

### 5.8.5. `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,

    EXTRACT_DEPENDS=	unzip:archivers/unzip

irá procurar por um executável chamado `unzip`, e ir para o subdiretório 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`.

| 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 Usando Macros `USES`.

### 5.8.6. `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,

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

vai descer para o subdiretório 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`.

### 5.8.7. `USES`

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

    USES= feature[:arguments]

Para a lista completa de valores, por favor veja o Usando Macros `USES`.

| `USES` não pode ser atribuído após a inclusão de bsd.port.pre.mk.

## 5.9. 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 Makefiles de port . Cada um deles é denominado como `USES_*`. Essas variáveis ​​podem ser usadas apenas no Makefile do port e 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.

| É sempre incorreto definir qualquer `USE_*` dentro de /etc/make.conf. Por exemplo, definindo
    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!

Tabela 8. `USE_*`
Variável | Significa
--- | ---
`USE_GCC` | 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.
| `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 configure são descritos em Mecanismos de Compilação, enquanto autoconf, automake e libtool são descritos em Usando o GNU Autotools. Variáveis relacionadas ao Perl ​são descritas em Usando Perl. Variáveis ​​X11 são listadas em Usando o X11. Usando o GNOME lida com o GNOME e Usando o KDE com variáveis ​​relacionadas ao KDE. Usando Java documenta variáveis ​​Java, enquanto Aplicações Web contém informações sobre Apache, PHP e módulos PEAR. Python é discutido em Usando Python, e Ruby em Usando Ruby. Usando SDL fornece variáveis ​​usadas para aplicações SDL e, finalmente, Usando o Xfce contém informações sobre o Xfce.

### 5.9.1. 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:

    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.

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

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

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

### 5.9.3. Dependências Circulares são Fatais

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

### 5.9.4. Problemas Causados ​​por Dependências Automáticas

Dependências devem ser declaradas explicitamente ou usando o 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.

Exemplo 37. Declaração Errada de uma Dependência Opcional

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

Exemplo 38. Declaração Correta de uma Dependência Opcional

    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.

## 5.10. 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 Makefile bem curto será necessário em todos, exceto em um dos diretórios. No 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 `PKGNAMESUFFIX` para que os pacotes tenham nomes diferentes.

Isso será melhor demonstrado por um exemplo. Isso é parte de print/pkfonts300/Makefile;

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

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

    .if !defined(RESOLUTION)
    RESOLUTION=	300
    .else
    .if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \
    	${RESOLUTION} != 300 && ${RESOLUTION} != 360 && \
    	${RESOLUTION} != 400 && ${RESOLUTION} != 600
    .BEGIN:
    	@${ECHO_MSG} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\""
    	@${ECHO_MSG} "Possible values are: 118, 240, 300, 360, 400 and 600."
    	@${FALSE}
    .endif
    .endif

print/pkfonts300 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 print/pkfonts360/Makefile completo:

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

    .include	"${MASTERDIR}/Makefile"

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

## 5.11. 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 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 .gz.

## 5.12. 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 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 PREFIX/INFO_PATH. Por exemplo, lang/gcc34 instala arquivos de informações em PREFIX/INFO_PATH/gcc34 e `INFO` será algo assim:

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

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

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

### 5.13.1. `OPTIONS`

#### 5.13.1.1. 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 ${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` é /var/db/ports. `OPTIONS_NAME` é a origem do port com um underline como o separador de espaço, por exemplo, dns/bind99 será `dns_bind99`.

Quando o usuário executa `make config` (ou executa `make build` pela primeira vez), o framework verifica ${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 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.

#### 5.13.1.2. 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:

    OPTIONS_DEFINE=	OPT1 OPT2

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

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

ports/Mk/bsd.options.desc.mk possui descrições para muitas `OPTIONS` comuns. Geralmente são úteis, mas podem ser substituas se a descrição for insuficiente para o port.

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

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

    OPTIONS_SINGLE=		SG1
    OPTIONS_SINGLE_SG1=	OPT3 OPT4

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

    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:

    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:

    OPTIONS_GROUP=		GG1
    OPTIONS_GROUP_GG1=	OPT9 OPT10

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

    OPTIONS_DEFAULT=	OPT1 OPT3 OPT6

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

Exemplo 39. Uso Simples de `OPTIONS`

    OPTIONS_DEFINE=	FOO BAR
    OPTIONS_DEFAULT=FOO

    FOO_DESC=	Option foo support
    BAR_DESC=	Feature bar support

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

    .include <bsd.port.mk>

Exemplo 40. Verificar `OPTIONS` Desmacadas

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

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

Exemplo 41. Uso Prático de `OPTIONS`

    OPTIONS_DEFINE=		EXAMPLES
    OPTIONS_DEFAULT=	PGSQL LDAP SSL

    OPTIONS_SINGLE=		BACKEND
    OPTIONS_SINGLE_BACKEND=	MYSQL PGSQL BDB

    OPTIONS_MULTI=		AUTH
    OPTIONS_MULTI_AUTH=	LDAP PAM SSL

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

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

    ICU_LIB_DEPENDS=	libicuuc.so:devel/icu

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

    # Check other OPTIONS

    .include <bsd.port.mk>

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

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

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

Exemplo 42. Manipulação Incorreta de uma Opção

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

Exemplo 43. Manuseio Correto de uma Opção

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

| 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.
    .if !empty(VARIABLE:MVALUE)
como uma alternativa para
    .if ${VARIABLE:MVALUE}

### 5.13.3. 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 Substituição de Variáveis ​​Genéricas, `OPT_VARIABLE_` e `OPT_VARIABLE_OFF`.

`CONFIGURE_ARGS`

  Para `--enable-x` e `--disable-x`, veja `OPT_CONFIGURE_ENABLE`.

  Para `--with-x` e `--without-x`, veja `OPT_CONFIGURE_WITH`.

  Para todos os outros casos, veja `OPT_CONFIGURE_ON` e `OPT_CONFIGURE_OFF`.

`CMAKE_ARGS`

  Para argumentos que são booleanos (`on`, `off`, `true`, `false`, `0`, `1`) veja `OPT_CMAKE_BOOL` e `OPT_CMAKE_BOOL_OFF`.

  Para todos os outros casos, veja `OPT_CMAKE_ON` e `OPT_CMAKE_OFF`.

`MESON_ARGS`

  Para argumentos que precisam de `true` ou `false`, veja `OPT_MESON_TRUE` e `OPT_MESON_FALSE`.

  Para argumentos que precisam de `yes` ou `no`, use `OPT_MESON_YES` e `OPT_MESON_NO`.

  Para argumentos que precisam de `true` ou `false`, veja `OPT_MESON_ENABLED` e `OPT_MESON_DISABLED`.

  Para todos os outros casos, use `OPT_MESON_ON` e `OPT_MESON_OFF`.

`QMAKE_ARGS`

  Veja `OPT_QMAKE_ON` e `OPT_QMAKE_OFF`.

`USE_*`

  Veja `OPT_USE` e `OPT_USE_OFF`.

`*_DEPENDS`

  Veja Dependências, `OPT_DEPTYPE_` e `OPT_DEPTYPE_OFF`.

* (Qualquer variável)

  As variáveis ​​mais usadas possuem assistentes diretos, veja Substituição de Variáveis ​​Genéricas, `OPT_VARIABLE_` e `OPT_VARIABLE_OFF`.

  Para qualquer variável sem um assistente específico, veja `OPT_VARS` e `OPT_VARS_OFF`.

Dependências de opções

  Quando uma opção precisa de outra opção para funcionar, veja `OPT_IMPLIES`.

Conflitos de opções

  Quando uma opção não funciona se outra também estiver ativada, consulte `OPT_PREVENTS` e `OPT_PREVENTS_MSG`.

Targets para Build

  Quando uma opção precisa de algum processamento extra, veja Targets Adicionais de Compilação, `target-OPT-on` e `target-OPT-off`.

#### 5.13.3.1. `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:

    OPTIONS_DEFINE=	OPT1
    OPTIONS_SUB=	yes

é equivalente a:

    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

| O valor de `OPTIONS_SUB` é ignorado. Definindo-o com qualquer valor irá adicionar entradas `PLIST_SUB` e `SUB_LIST` para todas as opções.

#### 5.13.3.2. `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:

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

é equivalente a:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

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

#### 5.13.3.3. Assistentes `CONFIGURE_ARGS`

##### 5.13.3.3.1. `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:

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

é equivalente a:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

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

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

##### 5.13.3.3.2. `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:

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

é equivalente a:

    OPTIONS_DEFINE=	OPT1 OPT2

    .include <bsd.port.options.mk>

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

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

##### 5.13.3.3.3. `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:

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

é equivalente a:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

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

| Na maioria das vezes, os assistentes em `OPT_CONFIGURE_ENABLE` e `OPT_CONFIGURE_WITH` fornecem uma funcionalidade mais curta e abrangente.

#### 5.13.3.4. Assistentes `CMAKE_ARGS`

##### 5.13.3.4.1. `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:

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

é equivalente a:

    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

| Veja `OPT_CMAKE_BOOL` e `OPT_CMAKE_BOOL_OFF` para um assistente mais curto quando o valor for booleano.

##### 5.13.3.4.2. `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:

    OPTIONS_DEFINE=	OPT1
    OPT1_CMAKE_BOOL=	TEST DEBUG
    OPT1_CMAKE_BOOL_OFF=	OPTIMIZE

é equivalente a:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

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

#### 5.13.3.5. Assistentes `MESON_ARGS`

##### 5.13.3.5.1. `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:

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

é equivalente a:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

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

##### 5.13.3.5.2. `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:

    OPTIONS_DEFINE=	OPT1
    OPT1_MESON_TRUE=	test debug
    OPT1_MESON_FALSE=	optimize

é equivalente a:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

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

##### 5.13.3.5.3. `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:

    OPTIONS_DEFINE=	OPT1
    OPT1_MESON_YES=	test debug
    OPT1_MESON_NO=	optimize

é equivalente a:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

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

##### 5.13.3.5.4. `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:

    OPTIONS_DEFINE=	OPT1
    OPT1_MESON_ENABLED=	test
    OPT1_MESON_DISABLED=	debug

é equivalente a:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    .if ${PORT_OPTIONS:MOPT1}
    MESON_ARGS+=	-Dtest=enabled -Ddebug=disabled
    .else
    MESON_ARGS+=	-Dtest=disabled -Ddebug=enabled
    .endif

#### 5.13.3.6. `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:

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

é equivalente a:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

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

#### 5.13.3.7. `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 `OPT_CONFIGURE_ENABLE` descrito anteriormente para demonstrar:

    OPTIONS_DEFINE=	OPT1 OPT2
    OPT1_IMPLIES=	OPT2

    OPT1_CONFIGURE_ENABLE=	opt1
    OPT2_CONFIGURE_ENABLE=	opt2

É equivalente a:

    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

Exemplo 44. Uso Simples de `OPT_IMPLIES`

Este port tem uma opção `X11` e uma opção `GNOME` que precisa da opção `X11` selecionada para poder compilar.

    OPTIONS_DEFINE=	X11 GNOME
    OPTIONS_DEFAULT=	X11

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

#### 5.13.3.8. `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:

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

É aproximadamente equivalente a:

    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.

Exemplo 45. Uso Simples de `OPT_PREVENTS`

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.

    OPTIONS_DEFINE=	X509 SCTP

    SCTP_PATCHFILES=	${PORTNAME}-6.8p1-sctp-2573.patch.gz:-p1
    SCTP_CONFIGURE_WITH=	sctp

    X509_PATCH_SITES=	http://www.roumenpetrov.info/openssh/x509/:x509
    X509_PATCHFILES=	${PORTNAME}-7.0p1+x509-8.5.diff.gz:-p1:x509
    X509_PREVENTS=		SCTP
    X509_PREVENTS_MSG=	X509 and SCTP patches conflict

#### 5.13.3.9. `OPT_VARS` e `OPT_VARS_OFF`

Fornece uma maneira genérica de definir e acrescentar valores em variáveis.

| Antes de usar `OPT_VARS` e `OPT_VARS_OFF`, veja se já não existe um assistente mais específico disponível em Substituição de Variáveis ​​Genéricas, `OPT_VARIABLE_` e `OPT_VARIABLE_OFF`.

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.

    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:

    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

| Valores contendo espaços em branco devem ser colocados entre aspas:
    OPT_VARS=	foo="bar baz"
Isso se deve ao jeito que a variável de expansão 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:
    OPT_VARS=	foo=	bar

#### 5.13.3.10. 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:

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

é equivalente a:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    .if ${PORT_OPTIONS:MOPT1}
    LIB_DEPENDS+=	liba.so:devel/a
    .else
    LIB_DEPENDS+=	libb.so:devel/b
    .endif

#### 5.13.3.11. 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:

    OPTIONS_DEFINE=	OPT1
    OPT1_USES=	gmake
    OPT1_CFLAGS_OFF=	-DTEST

é equivalente a:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

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

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

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

#### 5.13.3.12. Targets Adicionais de Compilação, `target-OPT-on` e `target-OPT-off`

Estes targets de 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:

    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:

    OPTIONS_DEFINE=	OPT1

    .include <bsd.port.options.mk>

    post-patch:
    .if ${PORT_OPTIONS:MOPT1}
    	@${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${EXAMPLESDIR}/|' ${WRKSRC}/Makefile
    .else
    	@${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${PREFIX}/bin/|' ${WRKSRC}/Makefile
    .endif

## 5.14. 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 Makefile tem:

    PORTNAME=	foo
    DISTVERSION=	1.0

então os arquivos de distribuição do port contêm um diretório de nível superior, 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.

### 5.14.1. `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 foo (e não foo-1.0) escreva:

    WRKSRC=	${WRKDIR}/foo

ou possivelmente

    WRKSRC=	${WRKDIR}/${PORTNAME}

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

    WRKSRC_SUBDIR=	src

### 5.14.3. `NO_WRKSUBDIR`

Se o port não extrair para nenhum subdiretório, então configure `NO_WRKSUBDIR` para indicar isso.

    NO_WRKSUBDIR=	yes

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

## 5.15. Manipulando Conflitos

Existem três variáveis ​​diferentes para registrar um conflito entre pacotes e ports: `CONFLICTS`, `CONFLICTS_INSTALL` e `CONFLICTS_BUILD`.

| As variáveis ​​de conflito definem automaticamente a variável `IGNORE`, que é mais amplamente documentada em 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.

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

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

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

Exemplo 46. Uso básico de `CONFLICTS_*`

dns/bind99 não pode ser instalado se dns/bind910 está presente porque eles instalam os mesmos arquivos. Primeiro, reúna o pacote base para usar:

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

Então adicione ao Makefile do dns/bind99:

    CONFLICTS_INSTALL=	bind910

E adicione ao Makefile do dns/bind910:

    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.

Exemplo 47. Usando `CONFLICTS_*` Com Globs.

Nas versões 2.0 até 2.4.1_2, deskutils/gnotime instalava uma versão integrada de databases/qof.

Para refletir este passado, o Makefile do database/qof contém:

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

deskutils/gnotime não possui nenhuma linha de conflitos porque sua versão atual não conflita com mais nada.

## 5.16. Instalando Arquivos

| 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 Makefile's de port devem ser mostrados na tela. Não silencie esses comandos com `@` ou `.SILENT`.

### 5.16.1. Macros `INSTALL_*`

Use as macros fornecidas em bsd.port.mk para garantir a propriedade correta dos arquivos nos targets `*-install` do port. Defina a propriedade diretamente em 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 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 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 install(1) com as flags apropriadas para cada situação.

| Não use `INSTALL_LIB` para instalar bibliotecas estáticas, porque otimiza-las (strip) torna-as sem utilidade. Use `INSTALL_DATA` neste caso.

### 5.16.2. 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:

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

Quando vários arquivos precisam ser otimizados (stripped):

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

Use file(1) em um arquivo para determinar se ele foi otimizado (stripped). Binários são relatados por file(1) como `stripped` ou `not stripped`. Além disso,strip(1) irá detectar programas que já foram otimizados (stripped) e retornar o comando sem erros.

| Quando `WITH_DEBUG` estiver definido, os arquivos elf não devem ser otimizados (stripped). As variáveis ​​(`STRIP_CMD`, `INSTALL_PROGRAM`, `INSTALL_LIB`, …​) e `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`.

### 5.16.3. 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 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 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 PREFIX/share.

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

Este exemplo irá instalar o conteúdo do diretório exemples do distfile do fornecedor para o local de exemplos apropriado do port.

    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 summer de um 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.

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

Essas macros não adicionam os arquivos instalados em pkg-plist. Eles devem ser adicionados manualmente. Para documentação opcional (`PORTDOCS`, veja Instalar Documentação Adicional) e exemplos (`PORTEXAMPLES`), os prefixos `%%PORTDOCS%%` ou `%%PORTEXAMPLES%%` devem ser prefixados no pkg-plist.

### 5.16.4. 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 pkg-plist são instalados, é seguro sempre instalar documentações no `STAGEDIR` (veja Staging). Por isso, blocos `.if` são necessários apenas quando os arquivos forem grandes o suficiente para causarem sobrecarga significativa de I/O.

    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 Targets Adicionais de Compilação, `target-OPT-on` e `target-OPT-off`.

Aqui estão algumas variáveis úteis e como elas são expandidas por padrão quando usadas no Makefile:

- `DATADIR` é expandido para PREFIX/shared/PORTNAME.

- `DATADIR_REL` é expandido para share/PORTNAME.

- `DOCSDIR` é expandido para PREFIX/shared/doc/PORTNAME.

- `DOCSDIR_REL` é expandido para share/doc/PORTNAME.

- `EXEMPLESDIR` é expandido para PREFIX/shared/examples/PORTNAME.

- `EXAMPLESDIR_REL` é expandido para share/examples/PORTNAME.

| 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 PREFIX. Isso é, por padrão share/doc/PORTNAME será substituído por `%%DOCSDIR%%` na lista de empacotamento e assim por diante. (Saiba mais sobre substituições pkg-plist aqui.)

Todos os arquivos e diretórios de documentação instalados condicionalmente são incluídos no pkg-plist com o prefixo `%%PORTDOCS%%`, por exemplo:

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

Como uma alternativa para listar os arquivos de documentação em 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`:

    PORTDOCS=	README.* ChangeLog docs/*

| O equivalente de `PORTDOCS` para arquivos instalados em `DATADIR` e `EXEMPLESDIR` são `PORTDATA` e `PORTEXAMPLES`, respectivamente. O conteúdo de pkg-message é exibido na instalação. Veja a seção sobre o uso do pkg-message para mais detalhes. pkg-message não precisa ser adicionado ao pkg-plist.

### 5.16.5. 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 lib, o que não funciona bem com o paradigma BSD. Muitos dos arquivos devem ser movidos para um desses diretórios: etc(setup/arquivos de configuração), libexec (executáveis ​​iniciados internamente), sbin (executáveis ​​para super-usuários/gerentes), info (documentação para o navegador de informações) ou share (arquivos independentes de arquitetura). Veja hier(7) para detalhes; as regras que regem /usr praticamente se aplicam a /usr/local também. A exceção são os ports que lidam com "notícias" USENET. Eles podem usar PREFIX/news como um destino para seus arquivos.

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

Exemplo 48. Usando `BINARY_ALIAS` para Deixar `gsed` Disponível como `sed`

Alguns ports esperam que o `sed` se comporte como o GNU sed e utilizam recursos que o sed(1) não possui. GNU sed está disponível em textproc/gsed no FreeBSD.

Use `BINARY_ALIAS` para substituir `sed` com `gsed` durante a compilação:

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

Exemplo 49. Usando `BINARY_ALIAS` Para Fornecer Aliases para Comandos `python3` Codificado

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:

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

Veja Usando Python para mais informações sobre `USES=python`.

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

Última alteração em: 18 de fevereiro de 2025 por Fernando Apesteguía

Anterior
Início
Próximo