A segunda parte do Makefile
descreve os arquivos que devem ser baixados para compilar o port e onde eles podem ser baixados.
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.
PORTVERSION
ManualmenteBIND9 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
>![]()
%
pkg version -t 9.9.9 9.9.9p1
<
O sinal | |
O sinal |
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/}CATEGORIES= dns net ipv6 MASTER_SITES= ISC/bind9/${ISCVERSION}
PKGNAMESUFFIX= 99 DISTNAME= ${PORTNAME}-${ISCVERSION}
MAINTAINER= mat@FreeBSD.org COMMENT= BIND DNS suite with updated DNSSEC and DNS64 LICENSE= ISCL # ISC releases things like 9.8.0-P1 or 9.8.1rc1, which our versioning does not like ISCVERSION= 9.9.9-P6
Defina a versão upstream em | |
Use | |
Use | |
Use |
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
O modificador |
À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
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
).
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.
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_
, a versão abreviada FOO
pode ser utilizada. Por exemplo, use:FOO
MASTER_SITES= FOO
E se MASTER_SITE_SUBDIR
for necessário, use isso:
MASTER_SITES=FOO
/bar
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}
MASTER_SITES
Macro | Subdiretório deduzido |
---|---|
APACHE_COMMONS_BINARIES | ${PORTNAME:S,commons-,,} |
APACHE_COMMONS_SOURCE | ${PORTNAME:S,commons-,,} |
APACHE_JAKARTA | ${PORTNAME:S,-,/,}/source |
BERLIOS | ${PORTNAME:tl}.berlios |
CHEESESHOP | source/${DISTNAME:C/(.).*/\1/}/${DISTNAME:C/(.*)-[0-9].*/\1/} |
CPAN | ${PORTNAME:C/-.*//} |
DEBIAN | pool/main/${PORTNAME:C/^((lib)?.).*$/\1/}/${PORTNAME} |
FARSIGHT | ${PORTNAME} |
FESTIVAL | ${PORTREVISION} |
GCC | releases/${DISTNAME} |
GENTOO | distfiles |
GIMP | ${PORTNAME}/${PORTVERSION:R}/ |
GH | ${GH_ACCOUNT}/${GH_PROJECT}/tar.gz/${GH_TAGNAME}?dummy=/ |
GHC | ${GH_ACCOUNT}/${GH_PROJECT}/ |
GNOME | sources/${PORTNAME}/${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/} |
GNU | ${PORTNAME} |
GNUPG | ${PORTNAME} |
GNU_ALPHA | ${PORTNAME} |
HORDE | ${PORTNAME} |
LODEV | ${PORTNAME} |
MATE | ${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/} |
MOZDEV | ${PORTNAME:tl} |
NL | ${PORTNAME} |
QT | archive/qt/${PORTVERSION:R} |
SAMBA | ${PORTNAME} |
SAVANNAH | ${PORTNAME:tl} |
SF | ${PORTNAME:tl}/${PORTNAME:tl}/${PORTVERSION} |
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:
USE_GITHUB
DescriçãoVariá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 Seção 5.4.3.1, “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.
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
.
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.
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
.
USE_GITHUB
Quando o Upstream Não Usa VersõesSe nunca houve uma versão upstream, não invente uma como 0.1
ou 1.0
. Crie o port com um DISTVERSION
de g
, onde YYYY
MM
DD
g
é para Git e
representa a data em que o commit é referenciado em YYYY
MM
DD
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.
USE_GITHUB
para Acessar um Commit Entre Duas VersõesSe 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
v0.7.3-14-gf0038b1f0038b1
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 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
<
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
v0.7.3c66c71d
%
git describe --tags --long
v0.7.3-0-gc66c71dc66c71d
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_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_
é criada, contendo o diretório no qual o arquivo foi extraído. As variáveis group
}${WRKSRC_
podem ser usadas para mover diretórios durante o group
}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 :
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.group
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
Ao utilizar USE_GITHUB=nodefault
, o Makefile
deve ter DISTFILES
em seu bloco inicial. A definição deve ser:
DISTFILES= ${DISTNAME}${EXTRACT_SUFX}
USE_GITHUB
com Vários Arquivos de DistribuiçãoDe 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_
. Aqui, para o grupo group
}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
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.
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 \ [...]
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.
USE_GITLAB
DescriçãoVariá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 Seção 5.4.4.1, “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. |
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
.
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.
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_
é criada, contendo o diretório no qual o arquivo foi extraído. As variáveis group
}${WRKSRC_
podem ser usadas para mover diretórios durante o group
}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 :
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.group
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
Ao utilizar USE_GITLAB=nodefault
, o Makefile
deve ter DISTFILES
em seu bloco inicial. A definição deve ser:
DISTFILES= ${DISTNAME}${EXTRACT_SUFX}
USE_GITLAB
com Vários Arquivos de DistribuiçãoDe 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_
. Aqui, para o grupo group
}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
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.
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
.
Como EXTRACT_SUFX
é usado apenas em DISTFILES
, apenas defina um deles..
À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}
.
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=
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
.
(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.
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”.
MASTER_SITES:n
com Um Arquivo Por SiteMASTER_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”.
MASTER_SITES:n
com Mais de Um Arquivo Por SiteMASTER_SITES= ftp://ftp.example.com/:source1 \ http://www.example.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 \ source3.tar.gz:source2
Ok, então o exemplo anterior não refletiu as necessidades do novo port? Nesta seção vamos explicar em detalhes como o mecanismo de busca avançado MASTER_SITES:n
funciona e como ele pode ser usado.
Elementos podem ser pós-fixados com :
onde n
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).
Elementos pós-fixados com :n
pertence ao grupo n
, :m
pertence ao grupo m
e assim por diante.
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
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.
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
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.
A semântica de grupo pode ser usada em qualquer uma das variáveis MASTER_SITES
, PATCH_SITES
, MASTER_SITE_SUBDIR
, PATCH_SITE_SUBDIR
, DISTFILES
e PATCHFILES
de acordo com esta sintaxe:
Todos elementos MASTER_SITES
, PATCH_SITES
, MASTER_SITE_SUBDIR
e PATCH_SITE_SUBDIR
devem ser terminados com o caractere barra /
. Se algum elemento pertencer a algum grupo, o grupo de pós-fixação :
deve vir logo após o terminador n
/
. 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”.
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
MASTER_SITES:n
com Vírgula, Vários Arquivos, Vários Sites e Vários SubdiretóriosMASTER_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
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
)”.
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.
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
”.
MASTER_SITES:n
com PATCH_SITES
PATCH_SITES= http://site1/ http://site2/:test PATCHFILES= patch1:test
Todos os ports atuais permanecem os mesmos. A feature MASTER_SITES:n
só é ativada se houver elementos pós-fixados com :
como elementos de acordo com as regras de sintaxe acima, especialmente como mostrado no item 7.n
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.
Novos Targets de Port
Existem targets master-sites-
e n
patch-sites-
que listarão os elementos do respectivo grupo n
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
.
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
.
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
.
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>.