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

Importante:

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

4

Defina a versão upstream em ISCVERSION, com um comentário dizendo porque é necessário.

1

Use ISCVERSION para obter um PORTVERSION compatível com o ports.

2

Use ISCVERSION diretamente para obter a URL correta para baixar o arquivo de distribuição.

3

Use ISCVERSION diretamente para nomear o arquivo de distribuição.


Exemplo 5.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 5.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 5.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}

Nota:

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

Importante:

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

Dica:

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

Nota:

Alguns nomes MASTER_SITE_* são bastante longos e, para facilitar o uso, foram definidos atalhos:

Tabela 5.3. Atalhos para Macros MASTER_SITE_*
MacroAtalho
PERL_CPANCPAN
GITHUBGH
GITHUB_CLOUDGHC
LIBREOFFICE_DEVLODEV
NETLIBNL
RUBYGEMSRG
SOURCEFORGESF

5.4.2.2. Macros Mágicas de MASTER_SITES

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

MASTER_SITES=	SF

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

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

Isso também pode ser escrito como

MASTER_SITES=	SF
MASTER_SITE_SUBDIR=	stardict/WyabdcRealPeopleTTS/${PORTVERSION}
Tabela 5.4. Macros Mágicas de MASTER_SITES
MacroSubdiretório deduzido
APACHE_COMMONS_BINARIES${PORTNAME:S,commons-,,}
APACHE_COMMONS_SOURCE${PORTNAME:S,commons-,,}
APACHE_JAKARTA${PORTNAME:S,-,/,}/source
BERLIOS${PORTNAME:tl}.berlios
CHEESESHOPsource/${DISTNAME:C/(.).*/\1/}/${DISTNAME:C/(.*)-[0-9].*/\1/}
CPAN${PORTNAME:C/-.*//}
DEBIANpool/main/${PORTNAME:C/^((lib)?.).*$/\1/}/${PORTNAME}
FARSIGHT${PORTNAME}
FESTIVAL${PORTREVISION}
GCCreleases/${DISTNAME}
GENTOOdistfiles
GIMP${PORTNAME}/${PORTVERSION:R}/
GH${GH_ACCOUNT}/${GH_PROJECT}/tar.gz/${GH_TAGNAME}?dummy=/
GHC${GH_ACCOUNT}/${GH_PROJECT}/
GNOMEsources/${PORTNAME}/${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}
GNU${PORTNAME}
GNUPG${PORTNAME}
GNU_ALPHA${PORTNAME}
HORDE${PORTNAME}
LODEV${PORTNAME}
MATE${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}
MOZDEV${PORTNAME:tl}
NL${PORTNAME}
QTarchive/qt/${PORTVERSION:R}
SAMBA${PORTNAME}
SAVANNAH${PORTNAME:tl}
SF${PORTNAME:tl}/${PORTNAME:tl}/${PORTVERSION}

5.4.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.5. USE_GITHUBDescrição
VariávelDescriçãoPadrão
GH_ACCOUNTNome da conta do usuário do GitHub que hospeda o projeto${PORTNAME}
GH_PROJECTNome do projeto no GitHub${PORTNAME}
GH_TAGNAMENome 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_SUBDIRQuando 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 Seção 5.4.3.1, “Baixando Múltiplos Arquivos do GitHub” para maiores informações.(none)
GH_TUPLEGH_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. 

Importante:

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

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

Dica:

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 5.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 5.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 Exemplo 5.1, “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 5.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-gf0038b1pode 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 Exemplo 5.1, “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
<

Nota:

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.4.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 Seção 5.4.9, “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 Tabela 5.5, “USE_GITHUBDescriçã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.

Cuidado:

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.

Nota:

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 Seção 5.4.9, “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

Importante:

Ao utilizar USE_GITHUB=nodefault, o Makefile deve ter DISTFILES em seu bloco inicial. A definição deve ser:

DISTFILES=    ${DISTNAME}${EXTRACT_SUFX}
Exemplo 5.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 Gitfa579bc. 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 5.16. Uso de USE_GITHUB com Vários Arquivos de Distribuição Usando GH_TUPLE

Isto é funcionalmente equivalente a Exemplo 5.15, “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 5.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.

Nota:

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.4.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 5.6. USE_GITLAB Descrição
VariávelDescriçãoPadrão
GL_SITENome do site que hospeda o projeto GitLabhttps://gitlab.com
GL_ACCOUNTNome da conta do usuário do GitLab hospedando o projeto${PORTNAME}
GL_PROJECTNome do projeto em GitLab${PORTNAME}
GL_COMMITO 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_SUBDIRQuando 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 Seção 5.4.4.1, “Baixando Múltiplos Arquivos do GitLab para maiores informações.(none)
GL_TUPLEGL_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 5.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 5.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.

Dica:

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.

Nota:

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


5.4.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 Seção 5.4.9, “Múltiplos Arquivos de Distribuição ou Patches de Vários Locais” e Seção 5.4.4.1, “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. Tabela 5.6, “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.

Cuidado:

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.

Nota:

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 Seção 5.4.9, “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

Importante:

Ao utilizar USE_GITLAB=nodefault, o Makefile deve ter DISTFILES em seu bloco inicial. A definição deve ser:

DISTFILES=    ${DISTNAME}${EXTRACT_SUFX}
Exemplo 5.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 5.21. Uso de USE_GITLAB com Vários Arquivos de Distribuição Usando GL_TUPLE

Isto é funcionalmente equivalente a Exemplo 5.20, “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.4.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 Capítulo 17, Usando Macros USES para mais detalhes. Se nenhum destes estiver definido, o EXTRACT_SUFX padrão é .tar.gz.

Nota:

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

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

Dica:

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

Nota:

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

Importante:

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.4.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 Seção 5.4.9.2, “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 Exemplo 5.22, “Uso Simplificado de MASTER_SITES:n com Um Arquivo Por Site”.

Exemplo 5.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 Exemplo 5.23, “Uso Simplificado de MASTER_SITES:n com Mais de Um Arquivo Por Site”.

Exemplo 5.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.4.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 Exemplo 5.24, “Uso Detalhado de MASTER_SITES:n no MASTER_SITE_SUBDIR e Exemplo 5.25, “Uso Detalhado de MASTER_SITES:n com Vírgula, Vários Arquivos, Vários Sites e Vários Subdiretórios”.

      Exemplo 5.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 5.25. Uso Detalhado de MASTER_SITES:n com Vírgula, Vários Arquivos, Vários Sites e Vários Subdiretórios
      MASTER_SITES=	http://site1/%SUBDIR%/http://site2/:DEFAULT \
      		http://site3/:group3 http://site4/:group4 \
      		http://site5/:group5 http://site6/:group6 \
      		http://site7/:DEFAULT,group6 \
      		http://site8/%SUBDIR%/:group6,group7 \
      		http://site9/:group8
      DISTFILES=	file1 file2:DEFAULT file3:group3 \
      		file4:group4,group5,group6 file5:grouping \
      		file6:group7
      MASTER_SITE_SUBDIR=	directory-trial:1 directory-n/:groupn \
      		directory-one/:group6,DEFAULT \
      		directory

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

      • arquivo1 será obtido a partir de

        • MASTER_SITE_OVERRIDE

        • http://site1/directory-trial:1/

        • http://site1/directory-one/

        • http://site1/directory/

        • http://site2/

        • http://site7/

        • MASTER_SITE_BACKUP

      • arquivo2 será baixado exatamente como o arquivo1 já que ambos pertencem ao mesmo grupo

        • MASTER_SITE_OVERRIDE

        • http://site1/directory-trial:1/

        • http://site1/directory-one/

        • http://site1/directory/

        • http://site2/

        • http://site7/

        • MASTER_SITE_BACKUP

      • arquivo3 será obtido a partir de

        • MASTER_SITE_OVERRIDE

        • http://site3/

        • MASTER_SITE_BACKUP

      • arquivo4 será obtido a partir de

        • MASTER_SITE_OVERRIDE

        • http://site4/

        • http://site5/

        • http://site6/

        • http://site7/

        • http://site8/directory-one/

        • MASTER_SITE_BACKUP

      • arquivo5 será obtido a partir de

        • MASTER_SITE_OVERRIDE

        • MASTER_SITE_BACKUP

      • file6 será obtido a partir de

        • MASTER_SITE_OVERRIDE

        • http://site8/

        • MASTER_SITE_BACKUP


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

    Isso foi simplificado o máximo possível. Veja Exemplo 5.26, “Uso Detalhado de MASTER_SITES:n com SourceForge (SF)”.

    Exemplo 5.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 Exemplo 5.27, “Uso Simplificado de MASTER_SITES:n com PATCH_SITES.

    Exemplo 5.27. Uso Simplificado de MASTER_SITES:n com PATCH_SITES
    PATCH_SITES=	http://site1/ http://site2/:test
    PATCHFILES=	patch1:test

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

  2. 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 Exemplo 5.25, “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.

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

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

Nota:

Isso não afeta o MASTER_SITES definido no Makefile.

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.