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 .

Índice

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:

    • Makefile s para os novos ports, uma vez que sejam recopiados

    • Makefile para a nova categoria

    • Makefile para as categorias dos ports antigos

    • Makefile s para ports que dependem dos ports antigos

    • (para crédito extra, inclua os outros arquivos que precisam ser alterados, conforme o procedimento no Guia do Committer.)

  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}

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, enquanto make(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.

  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 Makefile s 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

Início