Capítulo 6. Considerações Especiais

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

Índice

Esta seção explica as coisas mais comuns a se considerar ao criar um port.

6.1. Staging

bsd.port.mk espera que os ports trabalhem com um "stage directory". Isso significa que um port não deve instalar arquivos diretamente nos diretórios de destino regulares (isto é, sob o PREFIX, por exemplo), mas em um diretório separado a partir do qual o pacote será construído. Em muitos casos, isso não requer privilégios de root, tornando possível criar pacotes como um usuário não privilegiado. Com o staging, o port é compilado e instalado no diretório sde estágio, STAGEDIR. Um pacote é criado a partir do diretório de estágio e, em seguida, instalado no sistema. As ferramentas Automake referem-se a este conceito como DESTDIR, mas no FreeBSD, DESTDIR tem um significado diferente (veja PREFIX e DESTDIR).

Nenhum port realmente precisa de root. Ele pode ser evitado principalmente usando USES=uidfix. Se o port ainda executa comandos como chown(8), chgrp(1) ou força o proprietário ou grupo com install(1) então use USES=fakeroot para enganar essas chamadas. Algumas modificações no Makefile do port serão necessárias.

Os meta ports, ou ports que não instalam arquivos por si mesmos e apenas dependem de outros ports, devem evitar extrair desnecessariamente mtree(8) para o diretório de estágio. Este é o layout básico do diretório do pacote, e estes diretórios vazios serão vistos como órfãos. Para prevenir extração do mtree(8), adicione esta linha:

NO_MTREE=	yes

Metaports devem usar USES=metaport. Ele configura padrões para ports que não baixam, criam ou instalam nada.

Staging é ativado pré-fixando a variável STAGEDIR para caminhos usados ​​nos targets pre-install, do-install e post-install (veja os exemplos no livro). Normalmente, isso inclui as variáveis PREFIX, ETCDIR, DATADIR, EXEMPLESDIR, MANPREFIX, DOCSDIR, e assim por diante. Os diretórios devem ser criados como parte do target post-install. Evite usar caminhos absolutos sempre que possível.

Ports que instalam módulos do kernel devem preceder a variável STAGEDIR em seus destinos, padrão /boot/modules.

Ao criar um link simbólico, os links relativos são fortemente recomendados. Use ${RLN} para criar links simbólicos relativos. Ele usa o install(1) por baixo dos panos para descobrir automaticamente o link relativo a ser criado.

Exemplo 1. Crie Links Simbólicos Relativos Automaticamente

${RLN} usa o recurso simbólico relativo do install(1) que libera o mantenedor do port de computar o caminho relativo.

${RLN} ${STAGEDIR}${PREFIX}/lib/libfoo.so.42 ${STAGEDIR}${PREFIX}/lib/libfoo.so
${RLN} ${STAGEDIR}${PREFIX}/libexec/foo/bar ${STAGEDIR}${PREFIX}/bin/bar
${RLN} ${STAGEDIR}/var/cache/foo ${STAGEDIR}${PREFIX}/share/foo

Irá gerar:

% ls -lF ${STAGEDIR}${PREFIX}/lib
lrwxr-xr-x  1 nobody  nobody    181 Aug  3 11:27 libfoo.so@ -> libfoo.so.42
-rwxr-xr-x  1 nobody  nobody     15 Aug  3 11:24 libfoo.so.42*
% ls -lF ${STAGEDIR}${PREFIX}/bin
lrwxr-xr-x  1 nobody  nobody    181 Aug  3 11:27 bar@ -> ../libexec/foo/bar
% ls -lF ${STAGEDIRDIR}${PREFIX}/share
lrwxr-xr-x  1 nobody  nobody    181 Aug  3 11:27 foo@ -> ../../../var/cache/foo

6.2. Bibliotecas Empacotadas (Bundled)

Esta seção explica porque as dependências agrupadas(bundled) são consideradas ruins e o que fazer com elas.

6.2.1. Por Que as Bibliotecas Agrupadas(Bundled) São Ruins

Alguns softwares requerem que o mantenedor do port localize bibliotecas de terceiros e adicione as dependências necessárias ao port. Outros softwares agrupam todas as bibliotecas necessárias no arquivo de distribuição. A segunda abordagem parece mais fácil no começo, mas há algumas desvantagens sérias:

Esta lista é vagamente baseada nas wikis Fedora e Gentoo, ambas licenciadas sob CC-BY-SA 3.0.

Segurança

Se vulnerabilidades forem encontradas na biblioteca e arrumadas no upstream, elas podem não ser consertadas na biblioteca empacotada com o port. Uma razão pode ser que o autor não esteja ciente do problema. Isto significa que o mantenedor do port deve consertá-las, ou atualizar para uma versão não vulnerável e enviar um patch para o autor. Isso tudo leva tempo, o que resulta em software vulnerável por mais tempo do que o necessário. Isso, por sua vez, torna mais difícil coordenar uma correção sem vazamento desnecessário de informações sobre a vulnerabilidade.

Bugs

Esse problema é semelhante ao problema de segurança no último parágrafo, mas geralmente menos grave.

Forking

É mais fácil para o autor criar um fork da biblioteca depois que ela é empacotada. Embora seja conveniente à primeira vista, isso significa que o código diverge do upstream, dificultando o tratamento da segurança ou outros problemas com o software. A razão para isso é que o patching se torna mais difícil.

Outro problema de forking é que, como o código diverge do upstream, os bugs são resolvidos repetidamente em vez de apenas uma vez em um local central. Isso, em primeiro lugar, anula a ideia de software de código aberto.

Colisão de símbolo

Quando uma biblioteca é instalada no sistema, ela pode colidir com a versão empacotada. Isso pode causar erros imediatos no tempo de compilação ou link. Também pode causar erros ao executar o programa, o que pode ser mais difícil de rastrear. O último problema poderia ser causado porque as versões das duas bibliotecas são incompatíveis.

Licenciamento

Ao agrupar projetos de diferentes fontes, os problemas de licença podem surgir com mais facilidade, especialmente quando as licenças são incompatíveis.

Desperdício de recursos

Bibliotecas empacotadas desperdiçam recursos em vários níveis. Demora mais para compilar o aplicativo real, especialmente se essas bibliotecas já estiverem presentes no sistema. Em tempo de execução, elas podem ocupar memória desnecessária quando a biblioteca do sistema já está carregada por um programa e a biblioteca agrupada é carregada por outro programa.

Desperdício de esforço

Quando uma biblioteca precisa de patches para o FreeBSD, esses patches precisam ser duplicados novamente na biblioteca. Isso desperdiça tempo do desenvolvedor porque os patches podem não ser aplicados de forma limpa. Também pode ser difícil perceber que estes patches são necessários em primeiro lugar.

6.2.2. O Que Fazer em Relação às Bibliotecas Agrupadas

Sempre que possível, use a versão separada da biblioteca adicionando um LIB_DEPENDS para o port. Se esse port ainda não existir, considere criá-lo.

Use bibliotecas agrupadas somente se o upstream tiver um bom histórico de segurança e se o uso de versões não agrupadas originarem patches excessivamente complexos.

Em alguns casos muito especiais, por exemplo, emuladores, como o Wine, um port tem que agrupar bibliotecas, porque elas estão em uma arquitetura diferente ou foram modificadas para se adequarem ao uso do software. Nesse caso, essas bibliotecas não devem ser expostas a outros ports para vinculação. Adicione BUNDLE_LIBS=yes no Makefile do port. Isso vai dizer ao pkg(8) para não computar as bibliotecas fornecidas. Pergunte sempre à equipe de gerenciamento do ports portmgr@FreeBSD.org antes de adicionar isso a um port.

6.3. Bibliotecas Compartilhadas

Se o port instalar uma ou mais bibliotecas compartilhadas, defina a variável USE_LDCONFIG para o make , a qual irá instruir o bsd.port.mk para executar o ${LDCONFIG} -m no diretório onde a nova biblioteca está instalada (geralmente em PREFIX/lib) durante o target post-install para registrá-la no cache da biblioteca compartilhada. Esta variável, quando definida, também facilitará a adição do par @exec /sbin/ldconfig -m e @unexec /sbin/ldconfig -R no pkg-plist, para que o usuário que instalou o pacote possa começar a usar a biblioteca compartilhada imediatamente e para que a desinstalação não faça com que o sistema acredite que a biblioteca ainda está lá.

USE_LDCONFIG=	yes

O diretório padrão pode ser substituído configurando a variável USE_LDCONFIG para uma lista de diretórios nos quais as bibliotecas compartilhadas devem ser instaladas. Por exemplo, se o port instalar bibliotecas compartilhadas em PREFIX/lib/foo e PREFIXO/lib/bar utilize isso no Makefile:

USE_LDCONFIG=	${PREFIX}/lib/foo ${PREFIX}/lib/bar

Por favor, verifique novamente, muitas vezes isso não é necessário ou é algo que pode ser evitado através do uso da opção -rpath ou da configuração da variável LD_RUN_PATH durante a fase de vinculação (consulte lang/mosml para um exemplo), ou através de um shell-wrapper que defina o LD_LIBRARY_PATH antes de executar o binário, como por exemplo o www/seamonkey faz.

Ao instalar bibliotecas de 32 bits em um sistema de 64 bits, use USE_LDCONFIG32 como alternativa.

Se o software usa o autotools, e especificamente, o libtool, adicione USES=libtool.

Quando o número da versão da biblioteca principal aumenta na atualização para a nova versão do port, todos os outros ports que se vinculam à biblioteca afetada devem ter seu PORTREVISION incrementado, para forçar a recompilação com a nova versão da biblioteca.

6.4. Ports com Restrições de Distribuição ou Preocupações Legais

As licenças variam e algumas delas impõem restrições sobre como o aplicativo pode ser empacotado, se pode ser vendido com fins lucrativos e assim por diante.

É de responsabilidade de um mantenedor de um port ler os termos de licenciamento do software e certificar-se de que o projeto do FreeBSD não será responsabilizado por violá-los, redistribuindo o código fonte ou os binários compilados via FTP/HTTP ou CD-ROM. Se estiver em dúvida, entre em contato com a Lista de discussão de ports do FreeBSD.

Em situações como esta, as variáveis ​​descritas nas próximas seções podem ser definidas.

6.4.1. NO_PACKAGE

Esta variável indica que não podemos gerar um pacote binário da aplicação. Por exemplo, a licença pode proibir a redistribuição binária, ou pode proibir a distribuição de pacotes criados a partir de código adaptado.

No entanto, o DISTFILES do port pode ser livremente espelhado no FTP/HTTP. Eles também podem ser distribuídos em um CD-ROM (ou mídia similar), a menos que a variável NO_CDROM esteja definida também.

Se o pacote binário geralmente não é útil, e o aplicativo sempre deve ser compilado a partir do código-fonte, use o NO_PACKAGE. Por exemplo, se o aplicativo tiver informações de configuração específicas do site codificadas nele em tempo de compilação, defina o NO_PACKAGE.

Defina a variável NO_PACKAGE para uma string descrevendo o motivo pelo qual o pacote não pode ser gerado.

6.4.2. NO_CDROM

Esta variável sozinha indica que, embora tenhamos permissão para gerar pacotes binários, não podemos colocar nem esses pacotes nem o DISTFILES em um CD-ROM (ou mídia similar) para revenda. No entanto, os pacotes binários e os DISTFILES do ports ainda estarão disponíveis via FTP/HTTP.

Se esta variável for definida junto com NO_PACKAGE, então apenas o DISTFILES do port estará disponível e somente via FTP/HTTP.

Defina a variável NO_CDROM para uma string descrevendo o motivo pelo qual o port não pode ser redistribuído em CD-ROM. Por exemplo, use isto se a licença do port for somente para uso "não comercial".

6.4.3. NOFETCHFILES

Arquivos definidos em NOFETCHFILES não podem ser obtidos de nenhum dos MASTER_SITES. Um exemplo de tal tipo de arquivo é quando o arquivo é fornecido apenas em CD-ROM pelo fornecedor.

Ferramentas que verificam a disponibilidade desses arquivos nos MASTER_SITES devem ignorar estes arquivos e não informar nada sobre eles.

6.4.4. RESTRICTED

Defina esta variável sozinha, se a licença do aplicativo não permitir o espelhamento do DISTFILES e nem a distribuição do pacote binário de forma alguma.

Não defina as variáveis NO_CDROM ou NO_PACKAGE juntamente com a variável RESTRICT, uma vez que esta última variável implica as anteriores.

Defina a variável RESTRICTED para uma string que descreva o motivo pelo qual o port não pode ser redistribuído. Normalmente, isso indica que o port contém software proprietário e que o usuário precisará baixar manualmente o DISTFILES, possivelmente após se registrar para ter acesso ao software ou após concordar em aceitar os termos de um EULA.

6.4.5. RESTRICTED_FILES

Quando a variável RESTRICT ou a NO_CDROM está definida, o valor padrão normalmente contém ${DISTFILES}${PATCHFILES} caso contrário, ela fica vazia. Se apenas alguns dos arquivos da distribuição forem restritos, defina essa variável para listá-los.

6.4.6. LEGAL_TEXT

Se o port tem preocupações legais as quais não foram abordadas pelas variáveis acima, defina a variável LEGAL_TEXT para uma string explicando a preocupação. Por exemplo, se o FreeBSD obteve uma permissão especial para redistribuir o binário, esta variável deve indicar isso.

Um port que defina qualquer uma das variáveis ​​acima também deverá ser adicionado ao /usr/ports/LEGAL. A primeira coluna é uma glob que corresponde aos distfiles restritos. A segunda coluna é a origem do port. A terceira coluna é a saída do comando make -VLEGAL.

6.4.8. Exemplos

A maneira preferida de declarar "os distfiles para este port devem ser obtidos manualmente" é a seguinte:

.if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX})
IGNORE=	may not be redistributed because of licensing reasons. Please visit some-website to accept their license and download ${DISTFILES} into ${DISTDIR}
.endif

Isso tanto informa o usuário, quanto define os metadados apropriados na máquina do usuário para uso por programas automatizados.

Note que esta estrofe deve ser precedida por uma inclusão de bsd.port.pre.mk.

6.5. Mecanismos de Compilação

6.5.1. Compilando Ports em Paralelo

O framework de ports do FreeBSD suporta compilação paralela usando múltiplos subprocessos do comando make, o que permite que os sistemas SMP utilizem todo o poder disponível da CPU, permitindo que as compilações dos ports sejam mais rápidas e eficazes.

Isso é alcançado passando-se a flag -jX para o make(1) executando no código do fornecedor. Este é o comportamento de compilação padrão dos ports. Infelizmente, nem todos os ports lidam bem com compilações paralelas e pode ser necessário desabilitar explicitamente esse recurso adicionando a variável MAKE_JOBS_UNSAFE=yes. Ela é usada quando um port é conhecido por não funcionar com a opção -jX devido a race conditions e problemas de compilação intermitentes.

Ao definir a variável MAKE_JOBS_UNSAFE, é muito importante explicar com um comentário no Makefile, ou pelo menos na mensagem de commit, porque o port não pode ser compilado quando ela está ativa. Caso contrário, é quase impossível corrigir o problema ou testar se ele foi corrigido ao efetuar o commit de uma atualização em uma data posterior.

6.5.2. make, gmake, e imake

Existem várias implementações diferentes do make. O software portado geralmente requer uma implementação específica, como o GNU make, conhecido no FreeBSD como gmake.

Se o port usa o GNU make, adicione o gmake no USES.

A variável MAKE_CMD pode ser usada para referenciar o comando específico configurado pelo USES no Makefile do port. Use o MAKE_CMD apenas dentro dos Makefiles do aplicativo no WRKSRC para chamar o comando make para a implementação esperada pelo software portado.

Se o port é um aplicativo X que usa o Imake para criar o Makefile do Imakefile, defina USES=imake. Veja a seção sobre USES=imake no Usando Macros USES para mais detalhes.

Se o Makefile do port tem algo diferente de all como o target de compilação principal, defina a variável ALL_TARGET adequadamente. O mesmo vale para install e INSTALL_TARGET.

6.5.3. Script configure

Se o port usa o script configure para gerar Makefiles a partir do Makefile.in defina GNU_CONFIGURE=yes. Para dar argumentos extras ao script configure (o argumento padrão é --prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH} --mandir = ${MANPREFIX}/man --build = ${CONFIGURE_TARGET}), defina estes argumentos extras em CONFIGURE_ARGS. Variáveis ​​de ambiente extras podem ser passadas usando CONFIGURE_ENV.

Tabela 1. Variáveis ​​para ports que usam o configure
VariávelSignifica

GNU_CONFIGURE

O port usa o script configure para preparar a construção.

HAS_CONFIGURE

Igual a GNU_CONFIGURE, exceto que o destino de configuração padrão não é adicionado a CONFIGURE_ARGS.

CONFIGURE_ARGS

Argumentos adicionais passados ​​para o script configure.

CONFIGURE_ENV

Variáveis de ambiente adicionais a serem definidas para execução de script configure.

CONFIGURE_TARGET

Substitui o target de configuração padrão. O valor padrão é ${MACHINE_ARCH}-portbld-freebsd${OSREL}.

6.5.4. Usando o cmake

Para ports que usam CMake, defina USES=cmake.

Tabela 2. Variáveis ​​para ports que usam o cmake
VariávelSignifica

CMAKE_ARGS

Flags do CMake especificas para o port a serem passadas para o binário do cmake.

CMAKE_ON

Para cada entrada em CMAKE_ON, um valor booleano ativado é adicionado ao CMAKE_ARGS. Veja CMAKE_ON and CMAKE_OFF.

CMAKE_OFF

Para cada entrada em CMAKE_OFF, um valor booleano desativado é adicionado ao CMAKE_ARGS. Veja CMAKE_ON and CMAKE_OFF.

CMAKE_BUILD_TYPE

Tipo de compilação (perfis de compilação predefinidos para o CMake). O padrão é Release ou Debug se a variável WITH_DEBUG estiver definida.

CMAKE_SOURCE_PATH

Caminho para o diretório do fonte. O padrão é ${WRKSRC}.

CONFIGURE_ENV

Variáveis ​​de ambiente adicionais a serem definidas para o binário do cmake.

Tabela 3. Variáveis ​​que os usuários podem definir para compilações com cmake
VariávelSignifica

CMAKE_NOCOLOR

Desativa o output colorido na compilação. Não é definido por padrão, a menos que BATCH ou PACKAGE_BUILDING esteja definido.

CMake suporta estes perfis de construção: Debug, Release, RelWithDebInfo e MinSizeRel. Debug e Release sistema de respeito de perfis *FLAGS, RelWithDebInfo e MinSizeRel ajustará CFLAGS para -O2 -g e -Os -DNDEBUG correspondentemente. O valor do invólucro inferior CMAKE_BUILD_TYPE é exportado para PLIST_SUB e deve ser usado se o port for instalar *.cmake dependendo do tipo de compilação (veja devel/kf5-kcrash por um exemplo). Por favor, note que alguns projetos podem definir seus próprios perfis de compilação e/ou forçar um tipo específico de compilação CMAKE_BUILD_TYPE dentro de CMakeLists.txt. Para fazer um port para tal projeto respeite CFLAGS e WITH_DEBUG, as definições CMAKE_BUILD_TYPE devem ser removidas desses arquivos.

A maioria dos projetos baseados em CMake suportam um método de compilação out-of-source. A compilação out-of-source de um port é a configuração padrão. Uma compilação in-source pode ser executada usando-se o sufixo :insource. Em uma compilação out-of-source, CONFIGURE_WRKSRC, BUILD_WRKSRC e INSTALL_WRKSRC serão definidos como ${WRKDIR}/.Build e esse diretório será usado para manter todos os arquivos gerados durante os estágios de configuração e compilação, deixando o diretório de origem intacto.

Exemplo 2. Exemplo de USES=cmake

Este trecho demonstra o uso do CMake para um port. O CMAKE_SOURCE_PATH geralmente não é necessário, mas pode ser definido quando os fontes não estão localizados no diretório superior ou se apenas um subconjunto do projeto for compilado pelo port.

USES=			cmake
CMAKE_SOURCE_PATH=	${WRKSRC}/subproject
Exemplo 3. CMAKE_ON and CMAKE_OFF

Ao adicionar valores booleanos a variável CMAKE_ARGS, será mais fácil usar as variáveis CMAKE_ON e CMAKE_OFF ​​em vez disso. Desta forma:

CMAKE_ON=	VAR1 VAR2
CMAKE_OFF=	VAR3

É equivalente a:

CMAKE_ARGS=	-DVAR1:BOOL=TRUE -DVAR2:BOOL=TRUE -DVAR3:BOOL=FALSE

Isto é apenas para os valores padrão desativados do CMAKE_ARGS. Os helpers descritos em OPT_CMAKE_BOOL e OPT_CMAKE_BOOL_OFF usam a mesma semântica, mas para valores opcionais.

6.5.5. Usando scons

Se o port usa SCons, definir USES=scons.

Para fazer os SConstruct de terceiros respeitarem tudo o que é passado para SCons no ambiente (isto é, o mais importante, CC/CXX/CFLAGS/CXXFLAGS), altere o SConstruct para que o Evironment de compilação fique da seguinte forma:

env = Environment(**ARGUMENTS)

Ele poderá então ser modificado com env.Append e env.Replace.

6.5.6. Compilando Aplicações Rust com cargo

Para ports que usam Cargo, defina USES=cargo.

Tabela 4. Variáveis ​​que os Usuários Podem Configurar para Compilar cargo
VariávelPadrãoDescrição

CARGO_CRATES

Lista de crates que o port depende. Cada entrada precisa ter um formato como cratename-semver por exemplo, libc-0.2.40. Os mantenedores de ports podem gerar essa lista a partir do Cargo.lock usando o comando make cargo-crates. É possível alterar manualmente as versões dos crates, mas tenha em mente as dependências transitivas.

CARGO_FEATURES

Lista de recursos do aplicativo a serem compilados (lista separada por espaço). Para desativar todos os recursos padrão, adicione o token especial --no-default-features para CARGO_FEATURES. Passar manualmente para CARGO_BUILD_ARGS, CARGO_INSTALL_ARGS, e CARGO_TEST_ARGS não é necessário.

CARGO_CARGOTOML

${WRKSRC}/Cargo.toml

O caminho para o Cargo.toml que será usado.

CARGO_CARGOLOCK

${WRKSRC}/Cargo.lock

O caminho para o Cargo.lock que será utilizado para o make cargo-crates. É possível especificar mais de um arquivo de bloqueio quando necessário.

CARGO_ENV

Uma lista de variáveis ​​de ambiente para passar para o Cargo semelhante a MAKE_ENV.

RUSTFLAGS

Flags para passar para o compilador Rust.

CARGO_CONFIGURE

yes

Use o padrão do-configure.

CARGO_UPDATE_ARGS

Argumentos extras para passar para o Cargo durante a fase de configuração. Os argumentos válidos podem ser consultados com cargo update --help.

CARGO_BUILDDEP

yes

Adiciona uma dependência de compilação em lang/rust.

CARGO_CARGO_BIN

${LOCALBASE}/bin/cargo

Localização do binário do cargo.

CARGO_BUILD

yes

Use o padrão do-build.

CARGO_BUILD_ARGS

Argumentos extras para passar para o Cargo durante a fase de compilação. Argumentos válidos podem ser consultados com cargo buil --help.

CARGO_INSTALL

yes

Use o padrão do-install.

CARGO_INSTALL_ARGS

Argumentos extras para passar para o Cargo durante a fase de instalação. Os argumentos válidos podem ser consultados com cargo isntall --help.

CARGO_INSTALL_PATH

.

Caminho para o crate instalar. Isto é passado para o cargo install via argumento --path. Quando múltiplos caminhos são informados, o cargo install é executado múltiplas vezes.

CARGO_TEST

yes

Use o padrão do-test.

CARGO_TEST_ARGS

Argumentos extras para passar para o Cargo durante a fase de teste. Os argumentos válidos podem ser consultados com cargo test --help.

CARGO_TARGET_DIR

${WRKDIR}/target

Localização do diretório de saída do cargo.

CARGO_DIST_SUBDIR

rust/crates

Diretório relativo a DISTDIR onde os arquivos de distribuição do crate serão armazenados.

CARGO_VENDOR_DIR

${WRKSRC}/cargo-crates

Localização do diretório do fornecedor onde todas os crates serão extraídos. Tente manter isto sob PATCH_WRKSRC, para que os patches possam ser aplicados facilmente.

CARGO_USE_GITHUB

no

Ativa a busca de crates bloqueadas para commits específicos do Git no GitHub via GH_TUPLE. Isso tentará modificar o Cargo.toml no WRKDIR para apontar para os fontes offline, em vez de buscá-los em um repositório Git durante a compilação.

CARGO_USE_GITLAB

no

O mesmo que CARGO_USE_GITHUB mas para instâncias GitLab e GL_TUPLE.

Exemplo 4. Criando um Port para uma Aplicação Simples em Rust

Criar um port baseado em cargo é um processo de três estágios. Primeiro, precisamos fornecer um modelo de port que busque o arquivo de distribuição do aplicativo:

PORTNAME=	tokei
DISTVERSIONPREFIX=	v
DISTVERSION=	7.0.2
CATEGORIES=	devel

MAINTAINER=	tobik@FreeBSD.org
COMMENT=	Display statistics about your code

USES=		cargo
USE_GITHUB=	yes
GH_ACCOUNT=	Aaronepower

.include <bsd.port.mk>

Gerar uma distinfo inicial:

% make makesum
=> Aaronepower-tokei-v7.0.2_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://codeload.github.com/Aaronepower/tokei/tar.gz/v7.0.2?dummy=/Aaronepower-tokei-v7.0.2_GH0.tar.gz
fetch: https://codeload.github.com/Aaronepower/tokei/tar.gz/v7.0.2?dummy=/Aaronepower-tokei-v7.0.2_GH0.tar.gz: size of remote file is not known
Aaronepower-tokei-v7.0.2_GH0.tar.gz                     45 kB  239 kBps 00m00s

Agora o arquivo de distribuição está pronto para uso e podemos ir em frente e extrair as dependências crate do pacote Cargo.lock:

% make cargo-crates
CARGO_CRATES=   aho-corasick-0.6.4 \
                ansi_term-0.11.0 \
                arrayvec-0.4.7 \
                atty-0.2.9 \
                bitflags-1.0.1 \
                byteorder-1.2.2 \
                [...]

A saída deste comando precisa ser colada diretamente no Makefile:

PORTNAME=	tokei
DISTVERSIONPREFIX=	v
DISTVERSION=	7.0.2
CATEGORIES=	devel

MAINTAINER=	tobik@FreeBSD.org
COMMENT=	Display statistics about your code

USES=		cargo
USE_GITHUB=	yes
GH_ACCOUNT=	Aaronepower

CARGO_CRATES=   aho-corasick-0.6.4 \
                ansi_term-0.11.0 \
                arrayvec-0.4.7 \
                atty-0.2.9 \
                bitflags-1.0.1 \
                byteorder-1.2.2 \
                [...]

.include <bsd.port.mk>

O distinfo precisa ser regenerado para conter todos os arquivos de distribuição dos crates:

% make makesum
=> rust/crates/aho-corasick-0.6.4.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://crates.io/api/v1/crates/aho-corasick/0.6.4/download?dummy=/rust/crates/aho-corasick-0.6.4.tar.gz
rust/crates/aho-corasick-0.6.4.tar.gz         100% of   24 kB 6139 kBps 00m00s
=> rust/crates/ansi_term-0.11.0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://crates.io/api/v1/crates/ansi_term/0.11.0/download?dummy=/rust/crates/ansi_term-0.11.0.tar.gz
rust/crates/ansi_term-0.11.0.tar.gz           100% of   16 kB   21 MBps 00m00s
=> rust/crates/arrayvec-0.4.7.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://crates.io/api/v1/crates/arrayvec/0.4.7/download?dummy=/rust/crates/arrayvec-0.4.7.tar.gz
rust/crates/arrayvec-0.4.7.tar.gz             100% of   22 kB 3237 kBps 00m00s
=> rust/crates/atty-0.2.9.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://crates.io/api/v1/crates/atty/0.2.9/download?dummy=/rust/crates/atty-0.2.9.tar.gz
rust/crates/atty-0.2.9.tar.gz                 100% of 5898  B   81 MBps 00m00s
=> rust/crates/bitflags-1.0.1.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
[...]

O port está agora pronto para uma compilação de teste e ajustes adicionais, como criar um plist, escrever uma descrição, adicionar informações de licença, opções, etc. como é normal.

Se você não estiver testando seu port em um ambiente limpo, como com o Poudriere, lembre-se de executar make clean antes de qualquer teste.

Exemplo 5. Ativando Recursos Adicionais do Aplicativo

Alguns aplicativos definem recursos adicionais em seus Cargo.toml. Eles podem ser compilados definindo a variável CARGO_FEATURES no port.

Aqui nós habilitamos as features Tokei’s json e yaml:

CARGO_FEATURES=	json yaml
Exemplo 6. Features de Codificação de Aplicativos como Opções de Port

Um exemplo de seção [features] no Cargo.toml pode parecer assim:

[features]
pulseaudio_backend = ["librespot-playback/pulseaudio-backend"]
portaudio_backend = ["librespot-playback/portaudio-backend"]
default = ["pulseaudio_backend"]

pulseaudio_backend é uma feature padrão. Ela está sempre ativada, a menos que desativemos explicitamente os recursos padrão adicionando --no-default-features para o CARGO_FEATURES. Aqui nós mudamos as features portaudio_backend e pulseaudio_backend em opções de port:

CARGO_FEATURES=	--no-default-features

OPTIONS_DEFINE=	PORTAUDIO PULSEAUDIO

PORTAUDIO_VARS=		CARGO_FEATURES+=portaudio_backend
PULSEAUDIO_VARS=	CARGO_FEATURES+=pulseaudio_backend
Exemplo 7. Listando Licenças Crate

Os crates têm suas próprias licenças. É importante saber o que elas são ao adicionar o bloco LICENSE para o port (ver Licenças). O target auxiliar cargo-crates-licenses tentará listar todas as licenças de todos os crates definidos no CARGO_CRATES.

% make cargo-crates-licenses
aho-corasick-0.6.4  Unlicense/MIT
ansi_term-0.11.0    MIT
arrayvec-0.4.7      MIT/Apache-2.0
atty-0.2.9          MIT
bitflags-1.0.1      MIT/Apache-2.0
byteorder-1.2.2     Unlicense/MIT
[...]

Os nomes das licenças geradas com make cargo-create-licenses são expressões de licenças do SPDX 2.1 que não correspondem aos nomes de licença definidos na estrutura de ports. Eles precisam ser traduzidos para os nomes de Lista de Licenças Predefinidas.

6.5.7. Usando meson

Para ports que usam Meson, defina USES=meson.

Tabela 5. Variáveis ​​para ports que usam o meson
VariávelDescrição

MESON_ARGS

Flags do Meson especificas para o port a serem passadas para o binário do meson.

MESON_BUILD_DIR

Caminho para o diretório de compilação relativo ao WRKSRC. O padrão é _build.

Exemplo 8. Exemplo de USES=meson

Este trecho demonstra o uso do Meson para um port.

USES=		meson
MESON_ARGS=	-Dfoo=enabled

6.5.8. Compilando Aplicações Go

Para ports que usam Go, defina USES=go. Consulte go para obter a lista de variáveis que podem ser configuradas para controlar o processo de compilação.

Exemplo 9. Criando um Port para uma Aplicação Baseada em Módulos Go

Criar um port baseado em Go é um processo de cinco estágios. Primeiro, precisamos fornecer um modelo de port que baixa o arquivo de distribuição do aplicativo:

PORTNAME=	ghq
DISTVERSIONPREFIX=	v
DISTVERSION=	0.12.5
CATEGORIES=	devel

MAINTAINER=	tobik@FreeBSD.org
COMMENT=	Remote repository management made easy

USES=		go:modules
USE_GITHUB=	yes
GH_ACCOUNT=	motemen

.include <bsd.port.mk>

Gerar uma distinfo inicial:

% make makesum
===>  License MIT accepted by the user
=> motemen-ghq-v0.12.5_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://codeload.github.com/motemen/ghq/tar.gz/v0.12.5?dummy=/motemen-ghq-v0.12.5_GH0.tar.gz
fetch: https://codeload.github.com/motemen/ghq/tar.gz/v0.12.5?dummy=/motemen-ghq-v0.12.5_GH0.tar.gz: size of remote file is not known
motemen-ghq-v0.12.5_GH0.tar.gz                          32 kB  177 kBps    00s

Agora o arquivo de distribuição está pronto para uso e podemos extrair as dependências necessárias de módulos Go. Esta etapa requer a instalação do ports-mgmt/modules2tuple:

% make gomod-vendor
[...]
GH_TUPLE=	\
		Songmu:gitconfig:v0.0.2:songmu_gitconfig/vendor/github.com/Songmu/gitconfig \
		daviddengcn:go-colortext:186a3d44e920:daviddengcn_go_colortext/vendor/github.com/daviddengcn/go-colortext \
		go-yaml:yaml:v2.2.2:go_yaml_yaml/vendor/gopkg.in/yaml.v2 \
		golang:net:3ec191127204:golang_net/vendor/golang.org/x/net \
		golang:sync:112230192c58:golang_sync/vendor/golang.org/x/sync \
		golang:xerrors:3ee3066db522:golang_xerrors/vendor/golang.org/x/xerrors \
		motemen:go-colorine:45d19169413a:motemen_go_colorine/vendor/github.com/motemen/go-colorine \
		urfave:cli:v1.20.0:urfave_cli/vendor/github.com/urfave/cli

A saída deste comando precisa ser colada diretamente no Makefile:

PORTNAME=	ghq
DISTVERSIONPREFIX=	v
DISTVERSION=	0.12.5
CATEGORIES=	devel

MAINTAINER=	tobik@FreeBSD.org
COMMENT=	Remote repository management made easy

USES=		go:modules
USE_GITHUB=	yes
GH_ACCOUNT=	motemen
GH_TUPLE=	Songmu:gitconfig:v0.0.2:songmu_gitconfig/vendor/github.com/Songmu/gitconfig \
		daviddengcn:go-colortext:186a3d44e920:daviddengcn_go_colortext/vendor/github.com/daviddengcn/go-colortext \
		go-yaml:yaml:v2.2.2:go_yaml_yaml/vendor/gopkg.in/yaml.v2 \
		golang:net:3ec191127204:golang_net/vendor/golang.org/x/net \
		golang:sync:112230192c58:golang_sync/vendor/golang.org/x/sync \
		golang:xerrors:3ee3066db522:golang_xerrors/vendor/golang.org/x/xerrors \
		motemen:go-colorine:45d19169413a:motemen_go_colorine/vendor/github.com/motemen/go-colorine \
		urfave:cli:v1.20.0:urfave_cli/vendor/github.com/urfave/cli

.include <bsd.port.mk>

O distinfo precisa ser gerado novamente para conter todos os arquivos de distribuição:

% make makesum
=> Songmu-gitconfig-v0.0.2_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://codeload.github.com/Songmu/gitconfig/tar.gz/v0.0.2?dummy=/Songmu-gitconfig-v0.0.2_GH0.tar.gz
fetch: https://codeload.github.com/Songmu/gitconfig/tar.gz/v0.0.2?dummy=/Songmu-gitconfig-v0.0.2_GH0.tar.gz: size of remote file is not known
Songmu-gitconfig-v0.0.2_GH0.tar.gz                    5662  B  936 kBps    00s
=> daviddengcn-go-colortext-186a3d44e920_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://codeload.github.com/daviddengcn/go-colortext/tar.gz/186a3d44e920?dummy=/daviddengcn-go-colortext-186a3d44e920_GH0.tar.gz
fetch: https://codeload.github.com/daviddengcn/go-colortext/tar.gz/186a3d44e920?dummy=/daviddengcn-go-colortext-186a3d44e920_GH0.tar.gz: size of remote file is not known
daviddengcn-go-colortext-186a3d44e920_GH0.tar.        4534  B 1098 kBps    00s
[...]

O port está agora pronto para uma compilação de teste e ajustes adicionais, como criar um plist, escrever uma descrição, adicionar informações de licença, opções, etc. como é normal.

Se você não estiver testando seu port em um ambiente limpo, como com o Poudriere, lembre-se de executar make clean antes de qualquer teste.

Exemplo 10. Definindo o Nome do Binário ou o Caminho da Instalação

Alguns ports precisam instalar o binário resultante com um nome diferente ou em um caminho diferente do padrão ${PREFIX}/bin. Isso pode ser feito usando a sintaxe de tupla GO_TARGET, por exemplo:

GO_TARGET=  ./cmd/ipfs:ipfs-go

irá instalar o binário ipfs como ${PREFIX}/bin/ipfs-go e

GO_TARGET=  ./dnscrypt-proxy:${PREFIX}/sbin/dnscrypt-proxy

irá instalar dnscrypt-proxy em ${PREFIX}/sbin.

6.5.9. Compilando Aplicações Haskell com cabal

Para ports que usam Cabal, defina o sistema de compilação USES=cabal. Consulte cabal para obter a lista de variáveis que podem ser configuradas para controlar o processo de compilação.

Exemplo 11. Criando um Port para uma Aplicação Hackage-hosted Haskell

Ao preparar um port Haskell Cabal, o programa devel/hs-cabal-install é necessário, portanto, certifique-se de que esteja instalado previamente. Primeiro, precisamos definir variáveis de ports comuns que permitem ao cabal-install buscar o arquivo de distribuição de pacotes:

PORTNAME=	ShellCheck
DISTVERSION=	0.6.0
CATEGORIES=	devel

MAINTAINER=	haskell@FreeBSD.org
COMMENT=	Shell script analysis tool

USES=		cabal

.include <bsd.port.mk>

Esse Makefile mínimo nos permite baixar o arquivo de distribuição:

% make cabal-extract
[...]
Downloading the latest package list from hackage.haskell.org
cabal get ShellCheck-0.6.0
Downloading  ShellCheck-0.6.0
Downloaded   ShellCheck-0.6.0
Unpacking to ShellCheck-0.6.0/

Agora, temos o arquivo de descrição do pacote ShellCheck.cabal, que permite baixar todas as dependências do pacote, incluindo as transitivas:

% make cabal-extract-deps
[...]
Resolving dependencies...
Downloading  base-orphans-0.8.2
Downloaded   base-orphans-0.8.2
Downloading  primitive-0.7.0.0
Starting     base-orphans-0.8.2 (lib)
Building     base-orphans-0.8.2 (lib)
Downloaded   primitive-0.7.0.0
Downloading  dlist-0.8.0.7
[...]

Como efeito colateral, as dependências do pacote também são compiladas, portanto, o comando pode levar algum tempo. Uma vez feito, uma lista de dependências necessárias pode ser gerada:

% make make-use-cabal
USE_CABAL=QuickCheck-2.12.6.1 \
hashable-1.3.0.0 \
integer-logarithms-1.0.3 \
[...]

Pacotes Haskell podem conter revisões, assim como nos ports do FreeBSD. As revisões podem afetar apenas os arquivos .cabal, mas ainda é importante extraí-los. Para verificar os itens USE_CABAL quanto a atualizações de revisão disponíveis, execute o seguinte comando:

% make make-use-cabal-revs
USE_CABAL=QuickCheck-2.12.6.1_1 \
hashable-1.3.0.0 \
integer-logarithms-1.0.3_2 \
[...]

Observe os números de versão adicionais após o símbolo _. Coloque a lista USE_CABAL recém-gerada em vez de uma antiga.

Finalmente, o distinfo precisa ser gerado novamente para conter todos os arquivos de distribuição:

% make makesum
=> ShellCheck-0.6.0.tar.gz doesn't seem to exist in /usr/local/poudriere/ports/git/distfiles/cabal.
=> Attempting to fetch https://hackage.haskell.org/package/ShellCheck-0.6.0/ShellCheck-0.6.0.tar.gz
ShellCheck-0.6.0.tar.gz                                136 kB  642 kBps    00s
=> QuickCheck-2.12.6.1/QuickCheck-2.12.6.1.tar.gz doesn't seem to exist in /usr/local/poudriere/ports/git/distfiles/cabal.
=> Attempting to fetch https://hackage.haskell.org/package/QuickCheck-2.12.6.1/QuickCheck-2.12.6.1.tar.gz
QuickCheck-2.12.6.1/QuickCheck-2.12.6.1.tar.gz          65 kB  361 kBps    00s
[...]

O port está agora pronto para uma compilação de teste e ajustes adicionais, como criar um plist, escrever uma descrição, adicionar informações de licença, opções, etc. como é normal.

Se você não estiver testando seu port em um ambiente limpo, como com o Poudriere, lembre-se de executar make clean antes de qualquer teste.

6.6. Usando o GNU Autotools

Se um port precisar de algum software GNU Autotools, adicione USES=autoreconf. Veja autoreconf Para maiores informações.

6.7. Usando o GNU gettext

6.7.1. Uso Básico

Se o port requer o gettext, defina USES=gettext, e o port herdará a dependência libintl.so do devel/gettext. Outros valores para uso do gettext estão listados em USES=gettext.

Um caso bastante comum é um port que utilize o gettext e o configure. Geralmente, o GNU configure deve ser capaz de localizar o gettext automaticamente.

USES=	gettext
GNU_CONFIGURE=	yes

Se falhar, dicas da localização do gettext podem ser informados por meio do CPPFLAGS e LDFLAGS` utilizando localbase do seguinte modo:

USES=	gettext localbase:ldflags
GNU_CONFIGURE=	yes

6.7.2. Uso Opcional

Alguns softwares permitem desabilitar o NLS. Por exemplo, passando --disable-nls para o configure. Nesse caso, o port deve usar gettext condicionalmente, dependendo do status da opção NLS. Para ports de baixa a média complexidade, use este idioma:

GNU_CONFIGURE=		yes

OPTIONS_DEFINE=		NLS
OPTIONS_SUB=		yes

NLS_USES=		gettext
NLS_CONFIGURE_ENABLE=	nls

.include <bsd.port.mk>

Ou usando a maneira antiga de usar opções:

GNU_CONFIGURE=		yes

OPTIONS_DEFINE=		NLS

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MNLS}
USES+=			gettext
PLIST_SUB+=		NLS=""
.else
CONFIGURE_ARGS+=	--disable-nls
PLIST_SUB+=		NLS="@comment "
.endif

.include <bsd.port.mk>

O próximo item na lista de tarefas a fazer é organizar de forma condicional os arquivos do catálogo de mensagens na lista de pacotes. A parte do Makefile desta tarefa já é fornecida pela expressão idiomática. Isto é explicado na seção sobre práticas avançadas de pkg-plist. Em poucas palavras, cada ocorrência de %%NLS%% dentro de pkg-plist será substituído por “@comment” se o NLS estiver desativado ou por uma cadeia nula se o NLS estiver ativado. Consequentemente, as linhas prefixadas por %%NLS%% se tornarão meros comentários na lista de empacotamento final se o NLS estiver desativado; caso contrário, o prefixo será deixado de fora. Em seguida, insira %%NLS%% antes de cada caminho para um arquivo de catálogo de mensagens em pkg-plist. Por exemplo:

%%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo
%%NLS%%share/locale/no/LC_MESSAGES/foobar.mo

Em casos de alta complexidade, técnicas mais avançadas podem ser necessárias, como geração dinâmica de lista de empacotamento.

6.7.3. Manipulando Diretórios do Catálogo de Mensagens

Há um ponto a ser observado sobre a instalação de arquivos de catálogo de mensagens. Os diretórios de destino para eles, que residem em LOCALBASE/shared/locale, não devem ser criados e removidos por um port. Os idiomas mais populares têm seus respectivos diretórios listados em PORTSDIR/Templates/BSD.local.dist. Os diretórios para muitos outros idiomas são governados pelo port devel/gettext. Consulte o seu pkg-plist e veja se o port vai instalar um arquivo de catálogo de mensagens para um idioma exclusivo.

6.8. Usando Perl

E se o MASTER_SITES estiver configurado para CPAN, o subdiretório correto é geralmente selecionado automaticamente. Se o subdiretório padrão estiver errado, o CPAN/Module pode ser usado para alterá-lo. O MASTER_SITES também pode ser definido para o antigo MASTER_SITE_PERL_CPAN, então o valor preferido para o MASTER_SITE_SUBDIR é o nome da hierarquia de nível superior. Por exemplo, o valor recomendado para p5-Module-Name é Module. A hierarquia de nível superior pode ser examinada em cpan.org. Isso mantém o port funcionando quando o autor do módulo muda.

A exceção a essa regra é quando o diretório relevante não existe ou o distfile não existe neste diretório. Neste caso, é permitido usar o id do autor como MASTER_SITE_SUBDIR. A macro CPAN: AUTOR pode ser usada, a qual será traduzida para o diretório de autor com hash. Por exemplo,CPAN: AUTOR será convertido para autores/id/A/AU/AUTOR.

Quando um port precisa de suporte a Perl, ele deve definir USES=perl5 com o opcional USE_PERL5 descrito em descrição do USES no perl5.

Tabela 6. Variáveis ​​Somente Leitura para Ports Que Usam Perl
Variáveis ​​Somente de LeituraSignifica

PERL

O caminho completo do interpretador Perl 5, seja no sistema ou instalado a partir de um port, mas sem o número da versão. Use isso quando o software precisar do caminho para o interpretador Perl. Para substituir as linhas “#!” em scripts, use USES=shebangfix.

PERL_VERSION

A versão completa do Perl instalada (por exemplo, 5,8,9).

PERL_LEVEL

A versão do Perl instalada como um inteiro no formato MNNNPP (por exemplo,500809).

PERL_ARCH

Local no qual o Perl armazena as bibliotecas dependentes da arquitetura. O valor padrão aponta para ${ARCH}-freebsd.

PERL_PORT

Nome do port Perl instalado (por exemplo,perl5).

SITE_PERL

Nome do diretório para onde vão os pacotes Perl específicos do site. Esse valor é adicionado a PLIST_SUB.

Ports de Módulos Perl que não possuem um site oficial devem linkar para cpan.org na linha WWW do pkg-descr. O formato preferido para a URL é http://search.cpan.org/dist/Module-Name/ (incluindo a barra final).

Não use ${SITE_PERL} em declarações de dependência. Fazê-lo pressupõe que o perl5.mk foi incluído, o que nem sempre é verdade. Os ports que dependem desse port terão dependências incorretas se os arquivos desse port forem movidos posteriormente em uma atualização. O caminho certo para declarar as dependências do módulo Perl é mostrado no exemplo abaixo.

Exemplo 12. Exemplo de Dependência Perl
p5-IO-Tee>=0.64:devel/p5-IO-Tee

Para ports Perl que instalam páginas de manual, as macros PERL5_MAN3 e PERL5_MAN1 podem ser usadas dentro do pkg-plist. Por exemplo,

lib/perl5/5.14/man/man1/event.1.gz
lib/perl5/5.14/man/man3/AnyEvent::I3.3.gz

pode ​​ser substituído por

%%PERL5_MAN1%%/event.1.gz
%%PERL5_MAN3%%/AnyEvent::I3.3.gz

Não existem macros PERL5_MANx para as outras seções (sendo x igual a 2 e de 4 até 9) porque estes são instalados nos diretórios comuns.

Exemplo 13. Um Port Que Requer Perl Apenas para Compilar

Como o valor padrão para USE_PERL5 é build e run, configure-o para:

USES=		perl5
USE_PERL5=	build
Exemplo 14. Um Port Que Também Requer Perl Para Patch

De tempos em tempos, o uso do sed(1) para patches se torna insuficiente. Quando usar perl(1) fica mais facil, para isso utilize:

USES=		perl5
USE_PERL5=	patch build run
Exemplo 15. Um Módulo Perl Que Precisa de ExtUtils::MakeMaker para Compilar

A maioria dos módulos Perl vêm com um script configure Makefile.PL. Neste caso, defina:

USES=		perl5
USE_PERL5=	configure
Exemplo 16. Um Módulo Perl Que Precisa Módulo::Build para Compilar

Quando um modulo Perl vem com um script configure Build.PL, pode exigir Module:Build, nesse caso, defina

USES=		perl5
USE_PERL5=	modbuild

Se for ao contrário, e exigir Module::Build::Tiny, defina

USES=		perl5
USE_PERL5=	modbuildtiny

6.9. Usando o X11

6.9.1. Componentes X.Org

A implementação do X11 disponível na Coleção de Ports é o X.Org. Se o aplicativo depender de componentes X, adicione USES= xorg e defina USE_XORG na lista de componentes necessários. Uma lista completa pode ser encontrada em xorg.

O Projeto Mesa é um esforço para fornecer implementação gratuita do OpenGL. Para especificar uma dependência em vários componentes deste projeto, use a variável USE_GL. Veja gl para a lista completa dos componentes disponíveis. Para compatibilidade com versões anteriores, o valor yes direciona para glu.

Exemplo 17. Exemplo USE_XORG
USES=		gl xorg
USE_GL=		glu
USE_XORG=	xrender xft xkbfile xt xaw
Tabela 7. Variáveis ​​para Ports Que Usam X

USES= imake

O port usa imake.

XMKMF

Definir o caminho de xmkmf se não no PATH. Padrão para xmkmf -a.

Exemplo 18. Usando Variáveis ​​Relacionadas ao X11
# Use some X11 libraries
USES=		xorg
USE_XORG=	x11 xpm

6.9.2. Ports que Requerem Motif

Se o port requer uma biblioteca Motif, defina USES=motif no Makefile. A implementação padrão do Motif é x11-toolkits/open-motif. Os usuários podem escolher o x11-toolkits/lesstif em vez disso, definindo WANT_LESSTIF no seu make.conf.

O MOTIFLIB será definido por motif.mk para referenciar a biblioteca Motif apropriada. Por favor, corrija o fonte do port para usar ${MOTIFLIB} onde quer que a biblioteca Motif seja referenciada no Makefile original ou no Imakefile.

Existem dois casos comuns:

  • Se o port se referir à biblioteca Motif como -lXm em seu Makefile ou Imakefile, substitua ${MOTIFLIB} por isso.

  • Se o port usa XmClientLibs em seu Imakefile, mude para ${MOTIFLIB} ${XTOOLLIB} ${XLIB}.

Observe que o MOTIFLIB (geralmente) se expande para -L/usr/local/lib -lXm -lXp ou /usr/local/lib/libXm.a, então não há necessidade de adicionar -L ou -l na frente.

6.9.3. Fontes X11

Se o port instalar fontes para o X Window System, coloque-as em LOCALBASE/lib/X11/fontes/local.

6.9.4. Obtendo um DISPLAY Falso com Xvfb

Algumas aplicações requerem uma tela X11 funcional para que a compilação seja bem-sucedida. Isso representa um problema para as máquinas que operam sem um monitor. Quando essa variável é usada, a infraestrutura de compilação iniciará o X virtual framebuffer. Um DISPLAY funcional é então passado para a compilação. Veja USES=exibição para os possíveis argumentos.

USES=	display

6.9.5. Entradas de Desktop

Entradas de desktop (um padrão Freedesktop) fornecem uma maneira de ajustar automaticamente os recursos do desktop quando um novo programa é instalado, sem a necessidade de intervenção do usuário. Por exemplo, programas recém-instalados aparecem automaticamente nos menus de aplicativos de ambientes de desktop compatíveis. Entradas de Desktop surgiram no ambiente de desktop GNOME, mas agora são um padrão e também funcionam com o KDE e o Xfce. Esta pitada de automação fornece um benefício real para o usuário, e as entradas de desktop são incentivadas para aplicativos que podem ser usados em um ambiente desktop.

6.9.5.1. Usando Arquivos .desktop Pré-definidos

Ports que incluem *.desktop pré-definidos devem incluir estes arquivos no pkg-plist e instalá-los no diretório $LOCALBASE/shared/applications. A macro INSTALL_DATA é útil para instalar esses arquivos.

6.9.5.2. Atualizando o Banco de Dados do Desktop

Se um port tiver uma entrada MimeType em seu portname.desktop, o banco de dados do desktop deve ser atualizado após a instalação e desinstalação. Para fazer isso, defina USES= desktop-file-utils.

6.9.5.3. Criando Entradas de Desktop com DESKTOP_ENTRIES

As entradas desktop podem ser facilmente criadas para aplicativos usando DESKTOP_ENTRIES. Um arquivo chamado name.desktop será criado, instalado e adicionado ao pkg-plist automaticamente. A sintaxe é:

DESKTOP_ENTRIES=	"NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify

A lista de possíveis categorias está disponível no Site Freedesktop. StartupNotify indica se a aplicação é compatível com notificações de inicialização. Estes são tipicamente um indicador gráfico como um relógio que aparece no ponteiro do mouse, menu ou painel para dar ao usuário uma indicação quando um programa está sendo iniciado. Um programa que seja compatível com as notificações de inicialização limpa o indicador depois de iniciado. Programas que não são compatíveis com as notificações de inicialização nunca limpariam o indicador (possivelmente confundindo e enfurecendo o usuário) e devem ter StartupNotify definido como false então o indicador não é mostrado.

Exemplo:

DESKTOP_ENTRIES=	"ToME" "Roguelike game based on JRR Tolkien's work" \
			"${DATADIR}/xtra/graf/tome-128.png" \
			"tome -v -g" "Application;Game;RolePlaying;" \
			false

6.10. Usando o GNOME

6.10.1. Introdução

Este capítulo explica a estrutura do framework GNOME utilizado pelos ports. O framework pode ser dividido livremente nos componentes base, componentes desktop GNOME e algumas macros especiais que simplificam o trabalho dos mantenedores dos ports.

6.10.2. Usando USE_GNOME

Adicionar esta variável ao port permite o uso das macros e componentes definidos em bsd.gnome.mk. O código em bsd.gnome.mk adiciona as dependências de tempo de compilação, tempo de execução ou biblioteca necessárias ou o tratamento de arquivos especiais. Aplicativos GNOME sob o FreeBSD usam o framework USE_GNOME. Inclua todos os componentes necessários como uma lista separada por espaço. Os componentes USE_GNOME são divididos nessas listas virtuais: componentes básicos, componentes do GNOME 3 e componentes legados. Se o port precisa apenas de bibliotecas GTK3, este é o caminho mais curto para defini-lo:

USE_GNOME=	gtk30

Componentes USE_GNOME adicionam automaticamente as dependências de que precisam. Por favor, veja Componentes GNOMEpara uma lista exaustiva de todos componentes USE_GNOME e quais outros componentes eles implicam e suas dependências.

Aqui está um exemplo de Makefile para um port do GNOME que usa muitas das técnicas descritas neste documento. Por favor, use-o como um guia para criar novos ports.

# $FreeBSD$

PORTNAME=	regexxer
DISTVERSION=	0.10
CATEGORIES=	devel textproc gnome
MASTER_SITES=	GNOME

MAINTAINER=	kwm@FreeBSD.org
COMMENT=	Interactive tool for performing search and replace operations

USES=		gettext gmake localbase:ldflags pathfix pkgconfig tar:xz
GNU_CONFIGURE=	yes
USE_GNOME=	gnomeprefix intlhack gtksourceviewmm3
INSTALLS_ICONS=	yes

GLIB_SCHEMAS=	org.regexxer.gschema.xml

.include <bsd.port.mk>

A macro USE_GNOME se utilizada sem nenhum argumento não irá adicionar nenhuma dependência ao port. O USE_GNOME não pode ser definido depois do bsd.port.pre.mk.

6.10.3. Variáveis

Esta seção explica quais macros estão disponíveis e como elas são usadas. Como elas são usadas no exemplo acima. A Componentes GNOME tem uma explicação mais detalhada. A variável USE_GNOME precisa ser definido para que essas macros sejam úteis.

INSTALLS_ICONS

Ports GTK+ que instalam ícones de estilo Freedesktop em ${LOCALBASE}/shared/icons deve usar essa macro para garantir que os ícones sejam armazenados em cache e exibidos corretamente. O arquivo de cache é nomeado icon-theme.cache. Não inclua esse arquivo em pkg-plist. Essa macro manipula isso automaticamente. Esta macro não é necessária para Qt, que usam um método interno.

GLIB_SCHEMAS

Lista de todos os arquivos de esquema de glib que o port instala. A macro adicionará os arquivos ao plist do port e manipulará o registro destes arquivos na instalação e desinstalação.

Os arquivos de esquema do glib são escritos em XML e terminam com a extensão gschema.xml. Eles estão instalados no diretório share/glib-2.0/schemas/. Esses arquivos de esquema contêm todos os valores de configuração do aplicativo com as configurações padrão. O banco de dados real usado pelos aplicativos é construído por glib-compile-schema, que é executado pela macro GLIB_SCHEMAS.

GLIB_SCHEMAS=foo.gschema.xml

Não adicione esquemas simplificados ao pkg-plist. Se eles estão listados em pkg-plist, eles não serão registrados e os aplicativos podem não funcionar corretamente.

GCONF_SCHEMAS

Liste todos os arquivos do esquema gconf. A macro adicionará os arquivos de esquema ao plist do port e manipulará seu registro na instalação e desinstalação.

O GConf é o banco de dados baseado em XML que praticamente todos os aplicativos GNOME usam para armazenar suas configurações. Esses arquivos são instalados no banco de dados no diretório etc/gconf/schemas. Esse banco de dados é definido pelos arquivos de esquema instalados que são usados para gerar os arquivos chave %gconf.xml. Para cada arquivo de esquema instalado pelo port, deve existir uma entrada no Makefile:

GCONF_SCHEMAS=my_app.schemas my_app2.schemas my_app3.schemas

Os esquemas do Gconf estão listados na macro GCONF_SCHEMAS em vez do pkg-plist. Se eles estiverem listados em pkg-plist, eles não serão registrados e os aplicativos podem não funcionar corretamente.

INSTALLS_OMF

Os arquivos do Open Source Metadata Framework (OMF) são comumente usados ​​pelos aplicativos GNOME 2. Esses arquivos contêm as informações do arquivo de ajuda do aplicativo e requerem processamento especial pelo ScrollKeeper/rarian. Para registrar adequadamente arquivos OMF ao instalar aplicativos GNOME a partir de pacotes, certifique-se de que os arquivos omf estão listados em pkg-plist e que o Makefile do port tem o INSTALLS_OMF definido:

INSTALLS_OMF=yes

Quando definido, bsd.gnome.mk digitaliza automaticamente o pkg-plist e adiciona diretivas @exec e @unexec para cada .omf para rastrear no banco de dados de registro do OMF.

6.11. Componentes GNOME

Para mais ajuda com um port GNOME, veja alguns dos ports existentes por exemplo. A pagina GNOME do FreeBSD tem informações de contato, se precisar de mais ajuda. Os componentes são divididos em componentes GNOME que estão atualmente em uso e componentes legados. Se o componente suportar argumento, eles serão listados entre parênteses na descrição. O primeiro é o padrão. "Ambos" são mostrados se o componente usar como padrão a adição às dependências de construção e execução.

Tabela 8. Componentes GNOME
ComponentePrograma associadoDescrição

atk

accessibility/atk

Kit de ferramentas de acessibilidade (ATK)

atkmm

accessibility/atkmm

c++ bindings para atk

cairo

graphics/cairo

Biblioteca de gráficos vetoriais com suporte a saída entre dispositivos

cairomm

graphics/cairomm

c++ bindings para o cairo

dconf

devel/dconf

Sistema de banco de dados de configuração (both, buil, run)

evolutiondataserver3

databases/evolution-data-server

Backends de dados para a suíte mail/PIM integrada do Evolution

gdkpixbuf2

graphics/gdk-pixbuf2

Biblioteca de gráficos para GTK+

glib20

devel/glib20

Biblioteca core do GNOME glib20

glibmm

devel/glibmm

c++ bindings para glib20

gnomecontrolcenter3

sysutils/gnome-control-center

Centro de Controle do GNOME 3

gnomedesktop3

x11/gnome-desktop

Biblioteca de interface do usuário do desktop GNOME 3

gsound

audio/gsound

Biblioteca GObject para reproduzir sons do sistema (both, build, run)

gtk-update-icon-cache

graphics/gtk-update-icon-cache

Utilitário Gtk-update-icon-cache do kit de ferramentas Gtk

gtk20

x11-toolkits/gtk20

Kit de ferramentas Gtk+ 2

gtk30

x11-toolkits/gtk30

Kit de ferramentas Gtk+ 3

gtkmm20

x11-toolkits/gtkmm20

c++ bindings 2.0 para o kit de ferramentas gtk20

gtkmm24

x11-toolkits/gtkmm24

c++ bindings 2.4 para o kit de ferramentas gtk20

gtkmm30

x11-toolkits/gtkmm30

c++ bindings 3.0 para o kit de ferramentas gtk30

gtksourceview2

x11-toolkits/gtksourceview2

Widget que adiciona destaque de sintaxe para o GtkTextView

gtksourceview3

x11-toolkits/gtksourceview3

Widget de texto que adiciona destaque de sintaxe ao widget GtkTextView

gtksourceviewmm3

x11-toolkits/gtksourceviewmm3

c++ bindings para a biblioteca gtksourceview3

gvfs

devel/gvfs

Sistema de arquivos virtual do GNOME

intltool

textproc/intltool

Ferramenta para Internacionalização (veja também intlhack)

introspection

devel/gobject-introspection

Ligações de introspecção e ferramentas básicas para gerar ligações de introspecção. Na maioria das vezes: build é suficiente, e :both/:run só é necessário para aplicativos que usam ligações de introspecção. (both, build, run)

libgda5

databases/libgda5

Fornece acesso uniforme a diferentes tipos de fontes de dados

libgda5-ui

databases/libgda5-ui

Biblioteca de interface do usuário da biblioteca libgda5

libgdamm5

databases/libgdamm5

c++ bindings para a biblioteca libgda5

libgsf

devel/libgsf

Abstração extensível de I/O para lidar com formatos de arquivo estruturados

librsvg2

graphics/librsvg2

Biblioteca para analisar e renderizar arquivos gráficos vetoriais SVG

libsigc++20

devel/libsigc++20

Framework de Callback para C++

libxml++26

textproc/libxml++26

c++ bindings para a biblioteca libxml2

libxml2

textproc/libxml2

Biblioteca do parser XML (both, build, run)

libxslt

textproc/libxslt

Biblioteca XSLT C (both, build, run)

metacity

x11-wm/metacity

Gerenciador de janelas do GNOME

nautilus3

x11-fm/nautilus

Gerenciador de arquivos GNOME

pango

x11-toolkits/cave

Estrutura de código aberto para o layout e renderização do texto i18n

pangomm

x11-toolkits/pangomm

c++ bindings para a biblioteca pango

py3gobject3

devel/py3-gobject3

Python 3, GObject 3.0 bindings

pygobject3

devel/py-gobject3

Python 2, GObject 3.0 bindings

vte3

x11-toolkits/vte3

Widget de terminal com melhor acessibilidade e suporte I18N

Tabela 9. Componentes Macro do GNOME
ComponenteDescrição

gnomeprefix

Forneça configure com alguns locais padrão.

intlhack

O mesmo que intltool, porém com os patches necessários para garantir o share/locale/. Por favor, use somente quando intltool sozinho não for suficiente.

referencehack

Esta macro existe para ajudar a dividir a API ou a documentação de referência em seu próprio port.

Tabela 10. Componentes Legados do GNOME
ComponentePrograma associadoDescrição

atspi

accessibility/at-spi

Interface do Provedor de Serviços de Tecnologia Assistiva

esound

audio/esound

Pacote de som do Enlightenment

gal2

x11-toolkits/gal2

Coleção de widgets obtidos do GNOME 2 gnumeric

gconf2

devel/gconf2

Sistema de banco de dados de configuração para o GNOME 2

gconfmm26

devel/gconfmm26

c++ bindings para o gconf2

gdkpixbuf

graphics/gdk-pixbuf

Biblioteca de gráficos para GTK+

glib12

devel/glib12

biblioteca principal glib 1.2

gnomedocutils

textproc/gnome-doc-utils

Utilitários de documentação para o GNOME

gnomemimedata

misc/gnome-mime-data

MIME e banco de dados de aplicativos para o GNOME 2

gnomesharp20

x11-toolkits/gnome-sharp20

Interfaces do GNOME 2 para o tempo de execução do .NET

gnomespeech

accessibility/gnome-speech

API de conversão de texto em voz do GNOME 2

gnomevfs2

devel/gnome-vfs

Sistema de Arquivos Virtual do GNOME 2

gtk12

x11-toolkits/gtk12

Kit de ferramentas Gtk+ 1.2

gtkhtml3

www/gtkhtml3

Mecanismo leve de renderização/impressão/edição de HTML

gtkhtml4

www/gtkhtml4

Mecanismo leve de renderização/impressão/edição de HTML

gtksharp20

x11-toolkits/gtk-sharp20

Interfaces GTK+ e GNOME 2 para o runtime .NET

gtksourceview

x11-toolkits/gtksourceview

Widget que adiciona destaque de sintaxe para o GtkTextView

libartgpl2

graphics/libart_lgpl

Biblioteca para gráficos 2D de alto desempenho

libbonobo

devel/libbonobo

Componente e sistema de documentos compostos para o GNOME 2

libbonoboui

x11-toolkits/libbonoboui

GUI frontend para o componente libbonobo do GNOME 2

libgda4

databases/libgda4

Fornece acesso uniforme a diferentes tipos de fontes de dados

libglade2

devel/libglade2

Biblioteca glade do GNOME 2

libgnome

x11/libgnome

Bibliotecas para o GNOME 2, um ambiente de desktop GNU

libgnomecanvas

graphics/libgnomecanvas

Biblioteca Gráfica para o GNOME 2

libgnomekbd

x11/libgnomekbd

Biblioteca compartilhada de teclado do GNOME 2

libgnomeprint

print/libgnomeprint

Biblioteca de suporte de impressão do Gnome 2

libgnomeprintui

x11-toolkits/libgnomeprintui

Biblioteca de suporte de impressão do Gnome 2

libgnomeui

x11-toolkits/libgnomeui

Bibliotecas para a GUI do GNOME 2, um ambiente de desktop GNU

libgtkhtml

www/libgtkhtml

Mecanismo leve de renderização/impressão/edição de HTML

libgtksourceviewmm

x11-toolkits/libgtksourceviewmm

c++ binding do GtkSourceView

libidl

devel/libIDL

Biblioteca para criação de árvores de arquivo do CORBA IDL

libsigc++12

devel/libsigc++12

Framework de Callback para C++

libwnck

x11-toolkits/libwnck

Biblioteca usada para escrever pagers e listas de tarefas

libwnck3

x11-toolkits/libwnck3

Biblioteca usada para escrever pagers e listas de tarefas

orbit2

devel/ORBit2

CORBA ORB de alto desempenho com suporte para a linguagem C

pygnome2

x11-toolkits/py-gnome2

Python bindings para GNOME 2

pygobject

devel/py-gobject

Python 2, GObject 2.0 bindings

pygtk2

x11-toolkits/py-gtk2

Conjunto de Python bindings para GTK+

pygtksourceview

x11-toolkits/py-gtksourceview

Python bindings para GtkSourceView 2

vte

x11-toolkits/vte

Widget de terminal com melhor acessibilidade e suporte I18N

Tabela 11. Componentes Obsoletos: Não Use
ComponenteDescrição

pangox-compat

O pangox-compatfoi descontinuado e separado do pacote pango.

6.12. Usando o Qt

Para ports que fazem parte do Qt, veja qt-dist.

6.12.1. Ports que requerem o Qt

A coleção de ports fornece suporte para o Qt 5 com USES+=qt:5. Configure o USE_QT para a lista de componentes obrigatórios do Qt (bibliotecas, ferramentas, plugins).

O framework Qt exporta um número de variáveis ​​que podem ser usadas por ports, algumas delas listadas abaixo:

Tabela 12. Variáveis ​​Fornecidas aos Ports Que Usam o Qt

QMAKE

Caminho completo para o binário qmake.

LRELEASE

Caminho completo para utilitário Irelease.

MOC

Caminho completo para moc.

RCC

Caminho completo para rcc.

UIC

Caminho completo para uic.

QT_INCDIR

Diretório include Qt.

QT_LIBDIR

Caminho das bibliotecas Qt.

QT_PLUGINDIR

Caminho de plugins do Qt.

6.12.2. Seleção de Componentes

As dependências individuais das ferramentas e da biblioteca Qt devem ser especificadas em USE_QT. Todo componente pode ser sufixado com _build ou _run, o sufixo indica se a dependência no componente está no tempo de compilação ou no tempo de execução. Se um sufixo não for usado, a dependência do componente será tanto em tempo de compilação quanto em tempo de execução. Geralmente, os componentes da biblioteca são especificados como unsuffixed, os componentes das ferramentas são especificados com o sufixo _build e os componentes dos plugins são especificados com o sufixo _run. Os componentes mais comumente usados estão listados abaixo (todos os componentes disponíveis estão listados em _USE_QT_ALL e _USE_QT5_ONLY em /usr/ports/Mk/Uses/qt.mk):

Tabela 13. Componentes da Biblioteca Qt Disponíveis
NomeDescrição

3d

Módulo Qt3D

assistant

Navegador de documentação do Qt 5

canvas3d

Módulo Qt canvas3d

charts

Módulo de gráficos Qt 5

concurrent

Módulo multi-threading Qt

connectivity

Módulo de conectividade Qt (Bluetooth/NFC)

core

Módulo não-gráfico do núcleo Qt

datavis3d

Módulo de visualização de dados 3D Qt 5

dbus

Módulo de comunicação entre processos Qt D-Bus

declarative

Framework declarativo Qt para interfaces dinâmicas de usuário

designer

Designer gráfico de interface de usuário do Qt 5

diag

Ferramenta para relatar informações de diagnóstico sobre o Qt e seu ambiente

doc

Documentação do Qt 5

examples

Código-fonte dos exemplos do Qt 5

gamepad

Módulo de Gamepad Qt 5

graphicaleffects

Efeitos gráficos rápidos do Qt

gui

Módulo de interface gráfica do usuário do Qt

help

Módulo de integração de ajuda on-line do Qt

l10n

Mensagens localizadas do Qt

linguist

Ferramenta de tradução do Qt 5

location

Módulo de localização do Qt

multimedia

Módulo de suporte de áudio, vídeo, rádio e câmera do Qt

network

Módulo de rede do Qt

networkauth

Módulo de autenticação de rede do Qt

opengl

Módulo de suporte OpenGL compatível com o Qt 5

paths

Cliente de linha de comando para QStandardPaths

phonon4

Framework de multimídia do KDE

pixeltool

Lupa de tela do Qt 5

plugininfo

Dumper de metadados do plugin Qt5

printsupport

Módulo de suporte de impressão do Qt

qdbus

Interface de linha de comando do Qt para o D-Bus

qdbusviewer

Interface gráfica do Qt 5 para o D-Bus

qdoc

Gerador de documentação do Qt

qdoc-data

Arquivos de configuração do QDoc

qev

Ferramenta de introspecção de eventos Qt QWidget

qmake

Gerador de Makefile do Qt

quickcontrols

Conjunto de controles para construir interfaces completas no Qt Quick

quickcontrols2

Conjunto de controles para construir interfaces completas no Qt Quick

remoteobjects

Módulo SXCML Qt5

script

Módulo de script compatível com Qt 4

scripttools

Componentes adicionais do Qt Script

scxml

Módulo SXCML Qt5

sensors

Módulo de sensores do Qt

serialbus

Funções do Qt para acessar sistemas de bus industriais

serialport

Funções do Qt para acessar portas seriais

speech

Recursos de acessibilidade para o Qt5

sql

Módulo de integração a banco de dados SQL do Qt

sql-ibase

Plugin de banco de dados InterBase/Firebird do Qt

sql-mysql

Plugin de banco de dados MySQL do Qt

sql-odbc

Plugin Qt para conectividade Open Database

sql-pgsql

Plugin de banco de dados do PostgreSQL do Qt

sql-sqlite2

Plugin de banco de dados SQLite 2 do Qt

sql-sqlite3

Plugin de banco de dados SQLite 3 do Qt

sql-tds

Plugin de conectividade ao banco de dados TDS do Qt

svg

Módulo de suporte SVT do Qt

testlib

Módulo de teste unitário do Qt

uiplugin

Interface de plug-in do Qt widget personalizado para o Qt Designer

uitools

Módulo de suporte a formulários de interface de usuário do Qt Designer

virtualkeyboard

Módulo de teclado virtual do Qt 5

wayland

Qt5 wrapper para o Wayland

webchannel

Biblioteca Qt 5 para integração de C++/QML com clientes HTML/js

webengine

Biblioteca Qt 5 para renderizar conteúdo da web

webkit

QtWebKit com uma base de código WebKit mais moderna

websockets

Implementação do protocolo WebSocket do Qt

websockets-qml

Implementação do protocolo WebSocket do Qt (QML bindings)

webview

Componente do Qt para exibir o conteúdo da web

widgets

Módulo de widgets C++ do Qt

x11extras

Recursos específicos da plataforma Qt para sistemas baseados em X11

xml

Implementações SAX e DOM do Qt

xmlpatterns

Suporte do Qt para XPath, XQuery, XSLT e XML Schema

Para determinar as bibliotecas das quais um aplicativo depende, execute o ldd no executável principal após uma compilação bem sucedida.

Tabela 14. Componentes Disponíveis da Ferramenta Qt
NomeDescrição

buildtools

Ferramentas de compilação (moc, rcc), necessária para quase todas as aplicações do Qt.

linguisttools

ferramentas de localização: Irelease, lupdate

qmake

Utilitário gerador/compilador de Makefile

Tabela 15. Componentes Disponíveis de Plugin Qt
NomeDescrição

imageformats

plugins para formatos de imagem TGA, TIFF e MNG

Exemplo 19. Selecionando Componentes do Qt 5

Neste exemplo, o aplicativo portado usa a biblioteca de interface gráfica do usuário do Qt 5, a biblioteca principal do Qt 5, todas as ferramentas de geração de código do Qt 5 e o gerador de Makefile do Qt 5. Uma vez que a biblioteca gui implica na dependência da biblioteca principal, o core não precisa ser especificado. As ferramentas de geração de código do Qt 5 moc, uic e rcc, bem como o gerador de Makefile qmake são necessários apenas em tempo de compilação, assim eles são especificados com o sufixo _build:

USES=	qt:5
USE_QT=	gui buildtools_build qmake_build

6.12.3. Usando qmake

Se o aplicativo fornecer um arquivo de projeto qmake (*.pro), defina USES=qmake junto com USE_QTx. Observe que USES=qmake já implica uma dependência de compilação no qmake, portanto, o componente qmake pode ser omitido de USE_QT. Igual ao CMake, o qmake suporta compilações out-of-source, que podem ser ativadas especificando o argumento outsource (verUSES=qmakeexemplo) .

Tabela 16. Argumentos Possíveis para USES= qmake
VariávelDescrição

no_configure

Não adicione o target configure. Isso é implícito pelo HAS_CONFIGURE=yes e GNU_CONFIGURE=yes. Isso é requerido quando a compilação apenas precisa do ambiente de setup do USES= qmake, e dessa forma, executa-se o qmake por si próprio.

no_env

Suprime modificações dos ambientes configure e make. É necessário somente quando qmake é usado para configurar o software e a compilação falha em entender a configuração do ambiente pelo USES= qmake.

norecursive

Não passe o argumento -recursive para o qmake.

outsource

Realiza uma compilação out-of-source.

Tabela 17. Variáveis ​​para Ports Que Usam o qmake
VariávelDescrição

QMAKE_ARGS

Flags específicas do port qmake a serem passadas para o binario do qmake.

QMAKE_ENV

Variáveis ​​de ambiente a serem definidas para o binario qmake. O padrão é ${CONFIGURE_ENV}.

QMAKE_SOURCE_PATH

Caminho para os arquivos de projeto do qmake (.pro). O padrão é ${WRKSRC} se uma compilação out-of-source for solicitada, caso contrário, deixe em branco.

Ao usar USES= qmake, estas configurações são implementadas:

CONFIGURE_ARGS+=	--with-qt-includes=${QT_INCDIR} \
			--with-qt-libraries=${QT_LIBDIR} \
			--with-extra-libs=${LOCALBASE}/lib \
			--with-extra-includes=${LOCALBASE}/include

CONFIGURE_ENV+=	QTDIR="${QT_PREFIX}" QMAKE="${QMAKE}" \
		MOC="${MOC}" RCC="${RCC}" UIC="${UIC}" \
		QMAKESPEC="${QMAKESPEC}"

PLIST_SUB+=	QT_INCDIR=${QT_INCDIR_REL} \
		QT_LIBDIR=${QT_LIBDIR_REL} \
		QT_PLUGINDIR=${QT_PLUGINDIR_REL}

Alguns scripts de configuração não suportam os argumentos acima. Para suprimir a modificação de CONFIGURE_ENV e CONFIGURE_ARGS defina USES= qmake:no_env.

Exemplo 20. Exemplo USES= qmake

Este trecho demonstra o uso do qmake para um port Qt 5:

USES=	qmake:outsource qt:5
USE_QT=	buildtools_build

Aplicações Qt são frequentemente escritas para serem multi-plataforma e muitas vezes o X11/Unix não é a plataforma em que são desenvolvidas, o que por sua vez leva a certas pontas soltas, como:

  • Faltam caminhos de inclusão adicionais. Muitos aplicativos vêm com suporte ao ícone da bandeja do sistema, mas não buscam inclusões e/ou bibliotecas nos diretórios do X11. Para adicionar diretórios aos includes e bibliotecas de pesquisa do qmake através da linha de comando, use:

    QMAKE_ARGS+=	INCLUDEPATH+=${LOCALBASE}/include \
		LIBS+=-L${LOCALBASE}/lib

  • Caminhos falsos de instalação. Às vezes, dados como ícones ou arquivos .desktop são instalados por padrão em diretórios que não são verificados por aplicativos compatíveis com XDG. O editors/texmaker é um exemplo disso - veja patch-texmaker.pro no diretório de arquivos desse port para um modelo sobre como remediar isso diretamente no arquivo de projeto qmake.

6.13. Usando o KDE

6.13.1. Definições de Variáveis ​​do KDE

Se a aplicação depender do KDE, defina USES+=kde:5 e defina USE_KDE com a lista de componentes necessários. Sufixos _build e _run podem ser usados ​​para forçar o tipo de dependência de componentes (por exemplo, baseapps_run). Se nenhum sufixo for definido, o tipo padrão de dependência será usado. Para forçar os dois tipos, adicione o componente duas vezes com os dois sufixos (por exemplo, ecm_build ecm_run). Os componentes disponíveis estão listados abaixo (os componentes atualizados também estão listados em /usr/ports/Mk/Uses/kde.mk):

Tabela 18. Componentes Disponíveis do KDE
NomeDescrição

activities

Biblioteca de tempo de execução do KF5 para organizar o trabalho em atividades separadas

activities-stats

Estatísticas do KF5 para atividades

activitymanagerd

Serviço do sistema para gerenciar atividades do usuário, rastrear os padrões de uso

akonadi

Servidor de armazenamento para o KDE-Pim

akonadicalendar

Integração de Calendário do Akonadi

akonadiconsole

Console de gerenciamento e depuração do Akonadi

akonadicontacts

Bibliotecas e daemons para implementar o gerenciamento de contatos do Akonadi

akonadiimportwizard

Importa dados de outros clientes de email para o KMail

akonadimime

Bibliotecas e daemons para implementar o tratamento básico de email

akonadinotes

Biblioteca do KDE para acessar caixas postais no formato MBox

akonadisearch

Bibliotecas e daemons para implementar buscas no Akonadi

akregator

Um leitor de feeds do KDE

alarmcalendar

API do KDE para alarmes do KAlarm

apidox

Ferramentas de Documentação da API KF5

archive

Biblioteca KF5 que fornece classes para lidar com formatos de arquivo

attica

Biblioteca da API do Open Collaboration Services do KDE 5

attica5

Biblioteca da API do Open Collaboration Services do KDE 5

auth

Abstração do KF5 para funcionalidades de autenticação e políticas do sistema

baloo

KF5 Framework para pesquisar e gerenciar metadados do usuário

baloo-widgets

Biblioteca BalooWidgets

baloo5

KF5 Framework para pesquisar e gerenciar metadados do usuário

blog

API do KDE para acesso ao weblogging

bookmarks

Biblioteca KF5 para bookmarks e para o formato XBEL

breeze

Arte, estilos e recursos do Plasma5 para o estilo visual Breeze

breeze-gtk

Estilo visual do Plasma5 Breeze para Gtk

breeze-icons

Tema de ícones do Breeze para o KDE

calendarcore

Biblioteca de acesso ao calendário do KDE

calendarsupport

Bibliotecas de suporte de calendário para o KDEPim

calendarutils

Utilitário KDE e funções da interface do usuário para acessar o calendário

codecs

Biblioteca KF5 para manipulação de string

completion

Assistentes e widgets de conclusão de texto do KF5

config

Widgets do KF5 para diálogos de configuração

configwidgets

Widgets do KF5 para diálogos de configuração

contacts

Api do KDE para gerenciar informações de contato

coreaddons

Complementos do KF5 para o QtCore

crash

Biblioteca KF5 para lidar com análise de falhas e relatório de erros de aplicativos

dbusaddons

Complementos do KF5 para o QtDBus

decoration

Biblioteca do Plasma5 para criar decorações de janelas

designerplugin

Integração do KF5 para widgets de Framework no Qt Designer/Creator

discover

Ferramentas de gerenciamento de pacotes do Plasma5

dnssd

Abstração do KF5 para os recursos do sistema DNSSD

doctools

Geração de documentação do KF5 a partir do docbook

drkonqi

Manipulador de falhas do Plasma5

ecm

Módulos e scripts extras para o CMake

emoticons

Biblioteca KF5 para converter emoticons

eventviews

Bibliotecas de visualização de eventos para o KDEPim

filemetadata

Biblioteca KF5 para extrair metadados de arquivos

frameworkintegration

Espaço de trabalho e plugins de integração entre estruturas KF5

gapi

Biblioteca baseada no KDE para acessar serviços do Google

globalaccel

Biblioteca KF5 para incluir suporte para atalhos do espaço de trabalho global

grantlee-editor

Editor para os temas de Grantlee

grantleetheme

KDE PIM grantleetheme

gravatar

Biblioteca para suporte a gravatar

guiaddons

Complementos do KF5 para o QtGui

holidays

Biblioteca do KDE para feriados do calendário

hotkeys

Biblioteca do Plasma5 para teclas de atalho

i18n

Framework avançado de internacionalização do KF5

iconthemes

Biblioteca KF5 para manipular ícones em aplicativos

identitymanagement

Identidades do KDE pim

idletime

Biblioteca KF5 para monitorar a atividade do usuário

imap

API do KDE para suporte a IMAP

incidenceeditor

Bibliotecas do editor de incidências para o KDE Pim

infocenter

Utilidade do Plasma5 fornecendo informações do sistema

init

Iniciador de processos KF5 para acelerar o lançamento de aplicativos do KDE

itemmodels

Modelos KF5 para o sistema Qt Model / View

itemviews

KF5 widget addons para Qt Model/View

jobwidgets

Widgets do KF5 para rastrear a instância do KJob

js

Biblioteca KF5 que fornece um interpretador de script ECMA

jsembed

Biblioteca KF5 para ligar objetos JavaScript a QObjects

kaddressbook

Gerenciador de contatos do KDE

kalarm

Agendador de alarmes pessoal

kalarm

Agendador de alarmes pessoal

kate

Framework básico do editor para o sistema KDE

kcmutils

Utilitários KF5 para trabalhar com KCModules

kde-cli-tools

Ferramentas não interativas do sistema do Plasma5

kde-gtk-config

Configurador Plasma5 GTK2 e GTK3

kdeclarative

Biblioteca KF5 que prove a integração dos frameworks do QML e do KDE

kded

Daemon extensível do KF5 para fornecer serviços a nível do sistema

kdelibs4support

KF5 porting aid from KDELibs4

kdepim-addons

Complementos do KDE PIM

kdepim-apps-libs

Bibliotecas do KDE PIM relacionadas ao correio

kdepim-runtime5

Ferramentas e serviços do KDE PIM

kdeplasma-addons

Complementos do Plasma 5 para melhorar a experiência do Plasma

kdesu

Integração do KF5 com o su para privilégios elevados

kdewebkit

Biblioteca KF5 que fornece a integração do QtWebKit

kgamma5

Configurações de gama do monitor Plasma5

khtml

Motor de renderização KF5 KTHML

kimageformats

Biblioteca KF5 que fornece suporte para formatos de imagem adicionais

kio

Recurso e abstração de acesso à rede do KF5

kirigami2

Conjunto de componentes baseados em QtQuick

kitinerary

Modelo de dados e sistema de extração para informações de reservas de viagens

kmail

Cliente de correio do KDE

kmail

Cliente de correio do KDE

kmail-account-wizard

Assistente de conta de e-mail do KDE

kmenuedit

Editor de menu do Plasma5

knotes

Notas pop-up

kontact

Gerenciador de Informações Pessoais do KDE

kontact

Gerenciador de Informações Pessoais do KDE

kontactinterface

Cola do KDE para incorporar KParts no Kontact

korganizer

Programa de calendário e agendamento

kpimdav

Uma implementação do protocolo DAV com KJobs

kpkpass

Biblioteca para lidar com pass files da Apple Wallet

kross

Aplicação de scripting multi-language do KF5

kscreen

Biblioteca de gerenciamento de tela do Plasma5

kscreenlocker

Arquitetura de tela de bloqueio seguro do Plasma5

ksmtp

Biblioteca job-based para enviar email através de um servidor SMTP

ksshaskpass

Frontend ssh-add do Plasma5

ksysguard

Utilitário Plasma5 para rastrear e controlar os processos em execução

kwallet-pam

Integração PAM do Plasma5 KWallet

kwayland-integration

Plugins de integração para um desktop baseado em Wayland

kwin

Gerenciador de janelas do Plasma5

kwrited

Daemon do Plasma5 para ouvir paredes e escrever mensagens

ldap

API de acesso LDAP para o KDE

libkcddb

Biblioteca KDE CDDB

libkcompactdisc

Biblioteca do KDE para interfaceamento com CDs de áudio

libkdcraw

Interface LibRaw para o KDE

libkdegames

Bibliotecas usadas pelos jogos do KDE

libkdepim

Bibliotecas KDE PIM

libkeduvocdocument

Biblioteca para leitura e gravação de arquivos de vocabulário

libkexiv2

Interface da biblioteca Exiv2 para o KDE

libkipi

Interface de Plugin de Imagem do KDE

libkleo

Gerenciador de certificados para o KDE

libksane

Interface da biblioteca SANE para o KDE

libkscreen

Biblioteca de gerenciamento de tela do Plasma5

libksieve

Bibliotecas de inspeção para o KDEPim

libksysguard

Biblioteca do Plasma5 para rastrear e controlar processos em execução

mailcommon

Bibliotecas comuns para o KDEPim

mailimporter

Importar arquivos mbox para o KMail

mailtransport

Biblioteca do KDE para gerenciar o transporte de correio

marble

Globo virtual e atlas mundial para o KDE

mbox

Biblioteca do KDE para acessar caixas postais no formato MBox

mbox-importer

Importar arquivos mbox para o KMail

mediaplayer

Interface de plug-in do KF5 para recursos do media player

messagelib

Biblioteca para manipular mensagens

milou

Plasma5 Plasmóide para pesquisa

mime

Biblioteca para manipular dados MIME

newstuff

Biblioteca KF5 para baixar aplicativos da rede

notifications

Abstração KF5 para notificações do sistema

notifyconfig

Sistema de configuração KF5 para o KNotify

okular

Visualizador universal de documentos do KDE

oxygen

Estilo Oxygen Plasma5

oxygen-icons5

O tema de ícones do Oxygen para o KDE

package

Biblioteca KF5 para carregar e instalar pacotes

parts

Sistema de plugin centrado em documentos KF5

people

Biblioteca KF5 para fornecer acesso a contatos

pim-data-exporter

Importar e exportar configurações do KDE PIM

pimcommon

Bibliotecas comuns para o KDEPim

pimtextedit

Biblioteca do KDE para utilitários de edição de texto específicos do PIM

plasma-browser-integration

Componentes do Plasma5 para integrar navegadores na área de trabalho

plasma-desktop

Área de trabalho plasma Plasma5

plasma-framework

UI runtime baseado no plugin KF5 usado para escrever interfaces de usuários

plasma-integration

Plugins de integração do Qt Platform Theme para os workspaces do Plasma

plasma-pa

Misturador de áudio de pulso do Plasma5 Plasma

plasma-sdk

Aplicações do Plasma5 úteis para o desenvolvimento Plasma

plasma-workspace

Workspace Plasma5 Plasma

plasma-workspace-wallpapers

Plasma5 wallpapers

plotting

Framework de plotagem leve KF5

polkit-kde-agent-1

Daemon do Plasma5 que fornece uma interface de usuário de autenticação do polkit

powerdevil

Ferramenta Plasma5 para gerenciar as configurações de consumo de energia

prison

API para produzir códigos de barras

pty

Abstração KF5 pty

purpose

Oferece ações disponíveis para um propósito específico

qqc2-desktop-style

Estilo Qt QuickControl2 para o KDE

runner

Sistema de consulta paralelizado do KF5

service

Plugin KF5 avançado e serviço de introspecção

solid

Integração e detecção de hardware do KF5

sonnet

Biblioteca de verificação de ortografia baseada no plugin do KF5

syndication

Biblioteca de manipulação de feeds do KDE

syntaxhighlighting

Mecanismo de destaque de sintaxe KF5 para texto e código estruturados

systemsettings

Configurações do sistema Plasma5

texteditor

Editor avançado de texto embutido do KF5

textwidgets

Widgets avançados do KF5 para edição de texto

threadweaver

Complementos do KF5 para o QtDBus

tnef

API do KDE para o tratamento de dados TNEF

unitconversion

Biblioteca KF5 para conversão de unidade

user-manager

Gerenciador de usuários do Plasma5

wallet

Contêiner KF5 seguro e unificado para senhas de usuários

wayland

Wrapper da biblioteca KF5 Cliente e Servidor para as bibliotecas Wayland

widgetsaddons

Complementos do KF5 para o QtWidgets

windowsystem

Biblioteca KF5 para acesso ao sistema de janelas

xmlgui

Janelas principais configuráveis pelo usuário do KF5

xmlrpcclient

Interação KF5 com serviços XMLRPC

Exemplo 21. Exemplo USE_KDE

Este é um exemplo simples para um port do KDE. O USES= cmake instrui o port a utilizar o CMake, uma ferramenta de configuração amplamente usada pelos projetos do KDE (veja Usando o cmakepara informações detalhadas sobre o uso). O USE_KDE informa a dependência das bibliotecas do KDE. Os componentes necessários do KDE e outras dependências podem ser determinadas através do log de configuração. O USE_KDE não implica no USE_QT. Se um port requer alguns componentes do Qt, especifique-os em USE_QT.

USES=		cmake kde:5 qt:5
USE_KDE=	ecm
USE_QT=		core buildtools_build qmake_build

6.14. Usando o LXQt

As aplicações que dependem do LXQt devem definir USES+= lxqt e definir a variável USE_LXQT para a lista de componentes necessários da tabela abaixo

Tabela 19. Componentes disponíveis do LXQt
NomeDescrição

buildtools

Auxiliares para módulos CMake adicionais

libfmqt

Libfm Qt bindings

lxqt

LXQt core library

qtxdg

Implementação do Qt das especificações do XDG do freedesktop.org

Exemplo 22. Exemplo USE_LXQT

Este é um exemplo simples, USE_LXQT adiciona uma dependência em bibliotecas LXQt. Os componentes necessários do LXQt e outras dependências podem ser determinados a partir do log de configuração.

USES=	cmake lxqt qt:5 tar:xz
USE_QT=		core dbus widgets buildtools_build qmake_build
USE_LXQT=	buildtools libfmqt

6.15. Usando Java

6.15.1. Definições de Variáveis

Se o port precisar de um Java™ Development Kit (JDK) para compilar, executar ou até mesmo extrair o distfile, então defina USE_JAVA.

Existem vários JDKs na coleção de ports, de vários fornecedores e em várias versões. Se o port precisar usar uma versão específica, especifique-a usando a variável JAVA_VERSION. A versão mais atual é java/openjdk15, com java/openjdk14, java/openjdk13, java/openjdk12, java/openjdk11, java/openjdk8, e java/openjdk7 também disponíveis.

Tabela 20. Variáveis ​​Que Podem ser Definidas por Ports Que Usam Java
VariávelSignifica

USE_JAVA

Defina para as variáveis ​​restantes para ter algum efeito.

JAVA_VERSION

Lista das versões Java adequadas separadas por espaço para o port. Um opcional ""` permite especificar um intervalo de versões (valores permitidos: `7[] 8[] 11[] 12[] 13[] 14[] 15[]).

JAVA_OS

Lista de sistemas operacionais adequados do port JDK separados por espaço para o port (valores permitidos: native linux).

JAVA_VENDOR

Lista de fornecedores adequados de ports JDK separados por espaços para o port (valores permitidos: freebsd bsdjava sun openjdk).

JAVA_BUILD

Quando definido, adiciona o port JDK selecionado às dependências de compilação.

JAVA_RUN

Quando definido, adicione o port JDK selecionado às dependências de execução.

JAVA_EXTRACT

Quando definido, adicione o port JDK selecionado às dependências de extração.

Abaixo está a lista de todas as configurações que um port receberá após a configuração de USE_JAVA:

Tabela 21. Variáveis ​​Fornecidas para Ports que Usam Java
VariávelValor

JAVA_PORT

O nome do port do JDK (por exemplo,java/openjdk6).

JAVA_PORT_VERSION

A versão completa do port do JDK (por exemplo,1.6.0). Somente os dois primeiros dígitos deste número de versão são necessários, use ${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/}.

JAVA_PORT_OS

O sistema operacional usado pelo port do JDK (por exemplo, 'native').

JAVA_PORT_VENDOR

O fornecedor do port JDK (por exemplo,'openjdk').

JAVA_PORT_OS_DESCRIPTION

Descrição do sistema operacional usado pelo port JDK (por exemplo, 'Native').

JAVA_PORT_VENDOR_DESCRIPTION

Descrição do fornecedor do port JDK (por exemplo,'OpenJDK BSD Porting Team').

JAVA_HOME

Caminho para o diretório de instalação do JDK (por exemplo, '/usr/local/openjdk6').

JAVAC

Caminho para o compilador Java (por exemplo, '/usr/local/openjdk6/bin/javac').

JAR

Caminho para ferramenta jar a ser usada (por exemplo, '/usr/local/openjdk6/bin/jar' ou '/usr/local/bin/fastjar').

APPLETVIEWER

Caminho para o utilitário appletviewer (por exemplo,'/usr/local/openjdk6/bin/appletviewer').

JAVA

Caminho para o executável Java. Use isto para executar programas Java (por exemplo, '/usr/local/openjdk6/bin/java').

JAVADOC

Caminho para o utilitário javadoc.

JAVAH

Caminho para o programa javah.

JAVAP

Caminho para o programa javap.

JAVA_KEYTOOL

Caminho para o utilitário keytool.

JAVA_N2A

Caminho para a ferramenta native2ascii.

JAVA_POLICYTOOL

Caminho para o programa policytool.

JAVA_SERIALVER

Caminho para o utilitário serialver.

RMIC

Caminho para o gerador de stub/skeleton RMI, rmic.

RMIREGISTRY

Caminho para o programa de registro RMI, rmiregistry.

RMID

Caminho para o daemon do RMI rmid.

JAVA_CLASSES

Caminho para o arquivo que contém os arquivos de classe do JDK, ${JAVA_HOME}/jre/lib/rt.jar.

Use o java-debug make target para obter informações para depurar o port. Ele exibirá o valor de muitas das variáveis ​​listadas anteriormente.

Além disso, essas constantes são definidas para que todos os ports Java possam ser instalados de maneira consistente:

Tabela 22. Constantes definidas para os ports que usam Java
ConstanteValor

JAVASHAREDIR

O diretório base para tudo relacionado ao Java. Padrão: ${PREFIX}/shared/java.

JAVAJARDIR

O diretório onde os arquivos JAR são instalados. Padrão: ${JAVASHAREDIR}/classes.

JAVALIBDIR

O diretório onde os arquivos JAR instalados por outros ports estão localizados. Padrão: ${LOCALBASE}/shared/java/classes.

As entradas relacionadas são definidas em ambos PLIST_SUB (documentado em Alterando o pkg-plist Baseado em Variáveis Make) e SUB_LIST.

6.15.2. Compilando com Ant

Quando o port deve ser compilado usando o Apache Ant, ele deve definir USE_ANT. Ant é, portanto, considerado o comando sub-make. Quando nenhum target do-build é definido pelo port, será definido um padrão que execute Ant de acordo com MAKE_ENV, MAKE_ARGS e ALL_TARGET. Isso é semelhante ao mecanismo USES=gmake, documentado em Mecanismos de Compilação.

6.15.3. Melhores Práticas

Ao portar uma biblioteca Java, o port precisa instalar o(s) arquivo(s) JAR em ${JAVAJARDIR} e o resto em ${JAVASHAREDIR}/${PORTNAME} (exceto para a documentação, veja abaixo). Para reduzir o tamanho do arquivo de empacotamento, faça referência aos arquivos JAR diretamente no Makefile. Use esta declaração (onde myport.jar é o nome do arquivo JAR instalado como parte do port):

PLIST_FILES+=	${JAVAJARDIR}/myport.jar

Ao portar um aplicativo Java, o port geralmente instala tudo em um único diretório (incluindo suas dependências JAR). O uso de ${JAVASHAREDIR}/${PORTNAME} é fortemente indicado neste caso. Cabe ao mantenedor do port decidir se o port instala as dependências JAR adicionais sob esse diretório ou utiliza as já instaladas (de ${JAVAJARDIR}).

Ao portar um aplicativo Java™ que requer um servidor de aplicação, como o www/tomcat7 para executar o serviço, é bastante comum que o fornecedor distribua um .war. Um .war é uma aplicação Web ARchive a qual é extraído quando chamado pelo aplicativo. Evite adicionar um .war no pkg-plist. Isto não é considerado a melhor prática. Um servidor de aplicação irá expandir o arquivo war mas não irá remove-lo se o port for desinstalado. Uma forma mais desejável de trabalhar com este arquivo é extrair o seu conteudo, depois instalar os arquivos e, por fim, adicionar esses arquivos ao pkg-plist.

TOMCATDIR=	${LOCALBASE}/apache-tomcat-7.0
WEBAPPDIR=	myapplication

post-extract:
	@${MKDIR} ${WRKDIR}/${PORTDIRNAME}
	@${TAR} xf ${WRKDIR}/myapplication.war -C ${WRKDIR}/${PORTDIRNAME}

do-install:
	cd ${WRKDIR} && \
	${INSTALL} -d -o ${WWWOWN} -g ${WWWGRP} ${TOMCATDIR}/webapps/${PORTDIRNAME}
	cd ${WRKDIR}/${PORTDIRNAME} && ${COPYTREE_SHARE} \* ${WEBAPPDIR}/${PORTDIRNAME}

Independentemente do tipo de port (biblioteca ou aplicativo), a documentação adicional é instalada na mesma localização como para qualquer outro port. A ferramenta Javadoc é conhecida por produzir um conjunto diferente de arquivos, dependendo da versão do JDK utilizado. Para ports que não impõem o uso de um determinado JDK, é uma tarefa complexa especificar a lista de empacotamento (pkg-plist). Esta é uma razão pela qual os mantenedores de ports são fortemente encorajados a usar PORTDOCS. Além disso, mesmo se o conjunto de arquivos que serão gerados pelo javadoc puder ser previsto, o tamanho do pkg-plist resultante irá encorajar o uso do PORTDOCS.

O valor padrão para DATADIR é ${PREFIX}/shared/${PORTNAME}. É uma boa ideia sobreescrever DATADIR para ${JAVASHAREDIR}/${PORTNAME} para ports Java. De fato, DATADIR é automaticamente adicionado a PLIST_SUB (documentado em Alterando o pkg-plist Baseado em Variáveis Make) então use %%DATADIR%% diretamente em pkg-plist.

Quanto à escolha de compilar ports Java a partir do código fonte ou instalar diretamente a partir de uma distribuição binária, não há política definida no momento da escrita deste livro. No entanto, os membros do Projeto Java do FreeBSD encorajam os mantenedores de ports a terem seus ports compilados a partir do código fonte sempre que for possível.

Todos os recursos que foram apresentados nesta seção são implementados em bsd.java.mk. Se o port precisar de suporte Java mais sofisticado, por favor, primeiro dê uma olhada no log do bsd.java.mk no Subversion pois normalmente leva algum tempo para documentar os recursos mais recentes. Então, se o suporte necessário que estiver faltando for benéfico para muitos outros ports Java, sinta-se à vontade para discuti-lo na Lista de discussão do FreeBSD sobre Linguagem Java.

Embora haja uma categoria Java para PRs, isso refere-se ao esforço de portabilidade do JDK do projeto Java do FreeBSD. Portanto, envie o port Java na categoria ports como para qualquer outro port, a menos que o problema esteja relacionado a uma implementação do JDK ou ao bsd.java.mk.

Da mesma forma, existe uma política definida sobre as CATEGORIAS de um port Java, que é detalhada em Categorização.

6.16. Aplicações Web, Apache e PHP

6.16.1. Apache

Tabela 23. Variáveis ​​para Ports Que Usam o Apache

USE_APACHE

O port requer o Apache. Valores possíveis: yes (obtém qualquer versão), 22, 24, 22 a 24, 22+, etc. A versão padrão do APACHE é 22. Mais detalhes estão disponíveis em ports/Mk/bsd.apache.mk e em wiki.freebsd.org/Apache/.

APXS

Caminho completo para o binário apxs. Pode ser modificado no port.

HTTPD

Caminho completo para o binário httpd. Pode ser modificado no port.

APACHE_VERSION

A versão da instalação atual do Apache (variável somente leitura). Esta variável só está disponível após a inclusão de bsd.port.pre.mk. Valores possíveis: 22, 24.

APACHEMODDIR

Diretório para módulos Apache. Esta variável é automaticamente expandida em pkg-plist.

APACHEINCLUDEDIR

Diretório para cabeçalhos Apache. Esta variável é automaticamente expandida em pkg-plist.

APACHEETCDIR

Diretório para arquivos de configuração do Apache. Esta variável é automaticamente expandida em pkg-plist.

Tabela 24. Variáveis ​​Úteis para Portar Módulos do Apache

MODULENAME

Nome do módulo. O valor padrão é PORTNAME. Exemplo: mod_hello

SHORTMODNAME

Nome abreviado do módulo. Automaticamente derivado de MODULENAME, mas pode ser substituído. Exemplo: hello

AP_FAST_BUILD

Use o apxs para compilar e instalar o módulo.

AP_GENPLIST

Também cria automaticamente um pkg-plist.

AP_INC

Adiciona um diretório ao caminho de pesquisa de cabeçalhos durante a compilação.

AP_LIB

Adiciona um diretório ao caminho de pesquisa de bibliotecas durante a compilação.

AP_EXTRAS

Flags adicionais para passar para o apxs.

6.16.2. Aplicações Web

Aplicações web devem ser instaladas em PREFIX/www/appname. Este caminho está disponível tanto no Makefile quanto no pkg-plist como WWWDIR e o caminho relativo para PREFIX está disponível no Makefile como WWWDIR_REL.

O usuário e o grupo do processo do servidor web estão disponíveis como WWWOWN e WWWGRP, no caso de a propriedade de alguns arquivos precisar ser alterada. Os valores padrão de ambos são www. Use WWWOWN?=myuser e WWWGRP?=mygroup se o port precisar de valores diferentes. Isso permite ao usuário substituí-los facilmente.

Use WWWOWN e WWWGRP com moderação. Lembre-se de que todos os arquivos para os quais o servidor web tem permissão de escrita, são um risco de segurança esperando para acontecer.

Não insira o Apache como dependência, a menos que o aplicativo web precise explicitamente do Apache. Respeite que os usuários podem desejar executar um aplicativo web em um servidor web diferente do Apache.

6.16.3. PHP

Aplicações PHP declaram sua dependência a ele com USES=php. Veja php para maiores informações.

6.16.4. Módulos PEAR

Portar módulos PEAR é um processo muito simples.

Adicione USES=pear ao Makefile do port. O framework instalará os arquivos relevantes nos lugares certos e gerará automaticamente a lista no momento da instalação.

Exemplo 23. Exemplo de Makefile para Classes PEAR
PORTNAME=       Date
DISTVERSION=	1.4.3
CATEGORIES=	devel www pear

MAINTAINER=	example@domain.com
COMMENT=	PEAR Date and Time Zone Classes

USES=	pear

.include <bsd.port.mk>

Os módulos PEAR serão automaticamente flavorizados usando PHPflavors.

Se um PEAR_CHANNEL não padrão for usado, as dependências de compilação e de tempo de execução serão automaticamente adicionadas.

Módulos PEAR não precisam definir PKGNAMESUFFIX, é preenchido automaticamente usando PEAR_PKGNAMEPREFIX. Se um port precisar adicionar PKGNAMEPREFIX, também deve usar PEAR_PKGNAMEPREFIX para diferenciar entre diferentes flavors.

6.16.4.1. Módulos Horde

Da mesma forma, portar módulos Horde é um processo simples.

Adicione USES=horde ao Makefile do port . O framework instalará os arquivos relevantes nos lugares certos e gerará automaticamente a lista no momento da instalação.

As variáveis USE_HORDE_BUILD e USE_HORDE_RUN podem ser usadas para adicionar dependências de tempo de compilação e de tempo de execução em outros módulos Horde. Veja Mk/Uses/horde.mk para uma lista completa dos módulos disponíveis.

Exemplo 24. Exemplo de Makefile para Módulos Horde
PORTNAME=	Horde_Core
DISTVERSION=	2.14.0
CATEGORIES=	devel www pear

MAINTAINER=	horde@FreeBSD.org
COMMENT=	Horde Core Framework libraries

OPTIONS_DEFINE=	KOLAB SOCKETS
KOLAB_DESC=	Enable Kolab server support
SOCKETS_DESC=	Depend on sockets PHP extension

USES=	horde
USE_PHP=	session

USE_HORDE_BUILD=	Horde_Role
USE_HORDE_RUN=	Horde_Role Horde_History Horde_Pack \
		Horde_Text_Filter Horde_View

KOLAB_USE=	HORDE_RUN=Horde_Kolab_Server,Horde_Kolab_Session
SOCKETS_USE=	PHP=sockets

.include <bsd.port.mk>

Como os módulos Horde também são módulos PEAR, eles também serão automaticamente aromatizados usando PHP flavors.

6.17. Usando Python

A Coleção de Ports suporta a instalação paralela de várias versões do Python. Os ports devem usar um interpretador python, de acordo com a configuração do usuário de PYTHON_VERSION. Mais proeminentemente, isso significa substituir o caminho para o executável python em scripts com o valor de PYTHON_CMD.

Ports que instalam arquivos sob PYTHON_SITELIBDIR devem usar o prefixo pyXY- no prefixo do nome do pacote, assim o nome do pacote irá incorporar a versão do Python em que estão instalados.

PKGNAMEPREFIX=	${PYTHON_PKGNAMEPREFIX}
Tabela 25. Variáveis úteis para Ports que usam Python

USES=python

O port precisa do Python. A versão mínima necessária pode ser especificada com valores como 2.7+. Os intervalos de versão também podem ser especificados separando dois números de versão com um traço: USES=python:3.2-3.3

USE_PYTHON=distutils

Use o distutils do Python para configurar, compilar e instalar. Isso é necessário quando o port vem com setup.py. Isso sobrescreve os targets do-build e do-install e também pode substituir do-configure se o GNU_CONFIGURE não estiver definido. Além disso, isso implica em USE_PYTHON=flavors.

USE_PYTHON=autoplist

Crie a lista de empacotamento automaticamente. Isso também requer que USE_PYTHON=distutils seja definido.

USE_PYTHON=concurrent

O port usará um prefixo exclusivo, normalmente PYTHON_PKGNAMEPREFIX para determinados diretórios, como EXAMPLESDIR e DOCSDIR e também irá acrescentar um sufixo, a versão python de PYTHON_VER, para os binários e scripts que serão instalados. Isso permite que os ports sejam instalados para diferentes versões do Python ao mesmo tempo, o que de outra forma instalaria arquivos conflitantes.

USE_PYTHON=flavors

O port não usa distutils, mas ainda suporta várias versões do Python. .FLAVORS será definido para as versões suportadas do Python. Veja USES=python e Flavors para maiores informações.

USE_PYTHON=optsuffix

Se a versão atual do Python não for a versão padrão, o port receberá PKGNAMESUFFIX=${PYTHON_PKGNAMESUFFIX}. É útil apenas com flavors.

PYTHON_PKGNAMEPREFIX

Usado como um PKGNAMEPREFIX para distinguir pacotes para diferentes versões do Python. Exemplo: py27-

PYTHON_SITELIBDIR

Local da árvore site-packages, que contém o caminho de instalação do Python (geralmente LOCALBASE). A PYTHON_SITELIBDIR pode ser muito útil ao instalar módulos Python.

PYTHONPREFIX_SITELIBDIR

A variante PREFIX-clean do PYTHON_SITELIBDIR. Sempre use %%PYTHON_SITELIBDIR%% no pkg-plist quando possível. O valor padrão de %%PYTHON_SITELIBDIR%% é lib/python%%PYTHON_VERSION%%/site-packages

PYTHON_CMD

Linha de comando do interpretador Python, incluindo o número da versão.

Tabela 26. Assistentes do Módulo de Dependências do Python

PYNUMERIC

Linha de dependência para extensão numérica.

PYNUMPY

Linha de dependência para a nova extensão numérica, numpy. (PYNUMERIC foi descontinuado pelo fornecedor upstream).

PYXML

Linha de dependência para a extensão XML (não é necessária para o Python 2.0 e superior, pois também está na distribuição base).

PY_ENUM34

Dependência condicional do devel/py-enum34 dependendo da versão do Python.

PY_ENUM_COMPAT

Dependência condicional do devel/py-enum-compat dependendo da versão do Python.

PY_PATHLIB

Dependência condicional do devel/py-pathlib dependendo da versão do Python.

PY_IPADDRESS

Dependência condicional do net/py-ipaddress dependendo da versão do Python.

PY_FUTURES

Dependência condicional do devel/py-futures dependendo da versão do Python.

Uma lista completa das variáveis disponíveis pode ser encontrada em /usr/ports/Mk/Uses/python.mk.

Todas as dependências para ports Python usando Python flavors (quer com USE_PYTHON=distutils ou USE_PYTHON=flavors) deve ter o flavor Python anexado à sua origem usando @${PY_FLAVOR}. Veja Makefile para um Módulo Python Simples.

Exemplo 25. Makefile para um Módulo Python Simples
PORTNAME=	sample
DISTVERSION=	1.2.3
CATEGORIES=	devel

MAINTAINER=	john@doe.tld
COMMENT=	Python sample module

RUN_DEPENDS=	${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR}

USES=		python
USE_PYTHON=	autoplist distutils

.include <bsd.port.mk>

Algumas aplicações Python afirmam ter suporte a DESTDIR (que seria necessário para fazer o staging), mas ele está quebrado (Mailman até a versão 2.1.16, por exemplo). Isso pode ser contornado, recompilando os scripts. Isso pode ser feito, por exemplo, no target post-build. Assumindo que os scripts Python devem estar em PYTHONPREFIX_SITELIBDIR após a instalação, esta solução pode ser aplicada:

(cd ${STAGEDIR}${PREFIX} \
  && ${PYTHON_CMD} ${PYTHON_LIBDIR}/compileall.py \
   -d ${PREFIX} -f ${PYTHONPREFIX_SITELIBDIR:S;${PREFIX}/;;})

Isso recompila os fontes com um caminho relativo ao diretório de stage e acrescenta o valor de PREFIX para o nome do arquivo gravado no arquivo bytecode de saída por -d. O -f é necessário para forçar a recompilação e o :S;${PREFIX}/;; remove prefixos do valor de PYTHONPREFIX_SITELIBDIR para torná-lo relativo ao PREFIX.

6.18. Usando Tcl/Tk

A Coleção de Ports suporta a instalação paralela de múltiplas versões do Tcl/Tk. Ports devem tentar suportar pelo menos a versão padrão do Tcl/Tk e superior com USES=tcl. É possível especificar a versão desejada do tcl anexando :xx, por exemplo, USES=tcl:85.

Tabela 27. As variáveis read only muito úteis para Ports que usam Tcl/Tk

TCL_VER

versão major.minor escolhida do Tcl

TCLSH

caminho completo do interpretador Tcl

TCL_LIBDIR

caminho das bibliotecas Tcl

TCL_INCLUDEDIR

caminho dos arquivos de cabeçalho C do Tcl

TK_VER

versão major.minor escolhida do Tk

WISH

caminho completo do interpretador Tk

TK_LIBDIR

caminho das bibliotecas Tk

TK_INCLUDEDIR

caminho dos arquivos de cabeçalho C do Tk

Veja o USES=tcl e USES=tk do Usando Macros USES para uma descrição completa dessas variáveis. Uma lista completa dessas variáveis ​​está disponível em /usr/ports/Mk/Uses/tcl.mk.

6.19. Usando Ruby

Tabela 28. Variáveis ​​Úteis para Ports Que Usam Ruby
VariávelDescrição

USE_RUBY

Adiciona dependências de build e run no Ruby.

USE_RUBY_EXTCONF

O port utiliza extconf.rb para configurar.

USE_RUBY_SETUP

O port utiliza setup.rb para configurar.

RUBY_SETUP

Substitui o nome do script de configuração do setup.rb. Outro valor comum é install.rb.

Esta tabela mostra as variáveis selecionadas disponíveis para os autores dos ports através da infraestrutura de ports. Essas variáveis são usadas para instalar arquivos em seus locais apropriados. Use-os em pkg-plist tanto quanto possível. Não redefina essas variáveis no port.

Tabela 29. Variáveis ​​Somente Leitura Selecionadas para Ports Que Usam Ruby
VariávelDescriçãoExemplo de valor

RUBY_PKGNAMEPREFIX

Usado como um PKGNAMEPREFIX para distinguir pacotes para diferentes versões do Ruby.

ruby19-

RUBY_VERSION

Versão completa do Ruby na forma de x.y.z[.p].

1.9.3.484

RUBY_SITELIBDIR

Caminho de instalação de bibliotecas independentes de arquitetura.

/usr/local/lib/ruby/site_ruby/1.9

RUBY_SITEARCHLIBDIR

Caminho de instalação das bibliotecas dependentes de arquitetura.

/usr/local/lib/ruby/site_ruby/1.9/amd64-freebsd10

RUBY_MODDOCDIR

Caminho de instalação da documentação do módulo.

/usr/local/shared/doc/ruby19/patsy

RUBY_MODEXAMPLESDIR

Caminho de instalação dos exemplos do módulo.

/usr/local/shared/examples/ruby19/patsy

Uma lista completa das variáveis ​​disponíveis pode ser encontrada em /usr/ports/Mk/bsd.ruby.mk.

6.20. Usando SDL

O USE_SDL é usado para auto configurar as dependências para os ports que usam uma biblioteca baseada em SDL como o devel/sdl12 e o graphics/sdl_image.

Estas bibliotecas SDL para a versão 1.2 são reconhecidas:

Estas são as bibliotecas SDL para a versão 2.0 reconhecidas:

Portanto, se um port tiver uma dependência do net/sdl_net e do audio/sdl_mixer, a sintaxe será:

USE_SDL=	net mixer

A dependência devel/sdl12, a qual é exigida por net/sdl_net e audio/sdl_mixer, é automaticamente adicionada também.

Usar USE_SDL com entradas para o SDL 1.2, irá automaticamente:

  • Adicionar uma dependência em sdl12-config para BUILD_DEPENDS

  • Adicionar a variável SDL_CONFIG em CONFIGURE_ENV

  • Adicionar as dependências das bibliotecas selecionadas ao LIB_DEPENDS

Usar USE_SDL com entradas para o SDL 2.0, irá automaticamente:

  • Adicionar uma dependência em sdl2-config para BUILD_DEPENDS

  • Adicionar a variável SDL2_CONFIG ao CONFIGURE_ENV

  • Adicionar as dependências das bibliotecas selecionadas ao LIB_DEPENDS

6.21. Usando wxWidgets

Esta seção descreve o status das bibliotecas wxWidgets na árvore de ports e sua integração com o sistema de ports.

6.21.1. Introdução

Existem muitas versões das bibliotecas do wxWidgets que entram em conflito entre elas (instalam arquivos com o mesmo nome). Na árvore de ports este problema foi resolvido instalando cada versão sob um nome diferente usando sufixos de número de versão.

A desvantagem óbvia disso é que cada aplicativo precisa ser modificado para encontrar a versão esperada. Felizmente, a maioria dos aplicativos chama o script wx-config para determinar os sinalizadores necessários para o compilador e o vinculador. O script é nomeado de maneira diferente para cada versão disponível. A maioria dos aplicativos respeita uma variável de ambiente ou aceita um argumento de configuração para especificar o script wx-config que deve ser chamado. Caso contrário, eles têm que ser corrigidos.

6.21.2. Seleção de Versão

Para fazer o port usar uma versão específica do wxWidgets existem duas variáveis disponíveis para definir (se apenas uma for definida, a outra será definida para um valor padrão):

Tabela 30. Variáveis ​​para Selecionar as Versões do wxWidgets
VariávelDescriçãoValor padrão

USE_WX

Lista de versões que o port pode usar

Todas as versões disponíveis

USE_WX_NOT

Lista de versões que o port não pode usar

Nenhum

As versões disponíveis do wxWidgets e os ports correspondentes na árvore são:

Tabela 31. Versões Disponíveis do wxWidgets
VersãoPort

2.8

x11-toolkits/wxgtk28

3.0

x11-toolkits/wxgtk30

As variáveis ​​em Variáveis ​​para Selecionar as Versões do wxWidgets podem ser definidas para uma ou mais dessas combinações separadas por espaços:

Tabela 32. Especificações de Versão do wxWidgets
DescriçãoExemplo

Versão única

2.8

Range ascendente

2.8+

Range descendente

3.0-

Range total (deve ser crescente)

2.8-3.0

Também existem algumas variáveis ​​para selecionar as versões preferidas entre as disponíveis. Elas podem ser configuradas para uma lista de versões, as primeiras terão maior prioridade.

Tabela 33. Variáveis para selecionar as versões preferidas do wxWidgets
NomeDesenhado para

WANT_WX_VER

o port

WITH_WX_VER

o usuário

6.21.3. Seleção de Componentes

Existem outras aplicações que, apesar de não serem bibliotecas wxWidgets, estão relacionadas a eles. Estas aplicações podem ser especificadas em WX_COMPS. Estes componentes estão disponíveis:

Tabela 34. Componentes wxWidgets Disponíveis
NomeDescriçãoRestrição de versão

wx

biblioteca principal

nenhum

contrib

bibliotecas contribuídas

none

python

wxPython(ligações Python)

2.8-3.0

O tipo de dependência pode ser selecionado para cada componente, adicionando-se um sufixo separado por um ponto-e-vírgula. Se não estiver presente, será usado um tipo padrão (veja Tipos de Dependência Padrão do wxWidgets). Estes tipos estão disponíveis:

Tabela 35. Tipos de Dependências wxWidgets Disponíveis
NomeDescrição

build

Componente é necessário para a compilação, equivalente a BUILD_DEPENDS

run

O componente é necessário para execução, equivalente a RUN_DEPENDS

lib

O componente é necessário para a compilação e execução, equivalente a LIB_DEPENDS

Os valores padrão para os componentes estão detalhados nesta tabela:

Tabela 36. Tipos de Dependência Padrão do wxWidgets
ComponenteTipo de dependência

wx

lib

contrib

lib

python

run

mozilla

lib

svg

lib

Exemplo 26. Selecionando Componentes wxWidgets

Este fragmento corresponde a um port que usa wxWidgets versão 2.4 e suas bibliotecas contribuídas.

USE_WX=		2.8
WX_COMPS=	wx contrib

6.21.4. Detectando Versões Instaladas

Para detectar uma versão instalada, defina WANT_WX. Se não estiver definido para uma versão específica, os componentes terão um sufixo de versão. O HAVE_WX será preenchido após a detecção.

Exemplo 27. Detectando as versões instaladas wxWidgets e seus componentes

Este fragmento pode ser usado em um port que usa wxWidgets se estiver instalado ou uma opção estiver selecionada.

WANT_WX=	yes

.include <bsd.port.pre.mk>

.if defined(WITH_WX) || !empty(PORT_OPTIONS:MWX) || !empty(HAVE_WX:Mwx-2.8)
USE_WX=			2.8
CONFIGURE_ARGS+=	--enable-wx
.endif

Este fragmento pode ser usado em um port que permite suporte ao wxPython se ele estiver instalado ou se uma opção for selecionada, em adição ao wxWidgets, ambas nas versões 2.8.

USE_WX=		2.8
WX_COMPS=	wx
WANT_WX=	2.8

.include <bsd.port.pre.mk>

.if defined(WITH_WXPYTHON) || !empty(PORT_OPTIONS:MWXPYTHON) || !empty(HAVE_WX:Mpython)
WX_COMPS+=		python
CONFIGURE_ARGS+=	--enable-wxpython
.endif

6.21.5. Variáveis ​​Definidas

Estas variáveis ​​estão disponíveis no port (depois de definir uma de Variáveis ​​para Selecionar as Versões do wxWidgets).

Tabela 37. Variáveis ​​definidas para ports que usam wxWidgets
NomeDescrição

WX_CONFIG

O caminho para o script wxWidgets wx-config (com nome diferente)

WXRC_CMD

O caminho para o programa wxWidgets wxrc (com nome diferente)

WX_VERSION

A versão do wxWidgets que será usada (por exemplo,2.6)

6.21.6. Processando em bsd.port.pre.mk

Defina WX_PREMK para ser capaz de usar as variáveis ​​logo após a inclusão do bsd.port.pre.mk.

Ao definir WX_PREMK, a versão, dependências, componentes e variáveis ​​definidas não serão alteradas mesmo se alterado as variáveis ​​do port wxWidgets depois de incluir o bsd.port.pre.mk.

Exemplo 28. Usando Variáveis ​​nos Comandos wxWidgets

Este fragmento ilustra o uso de WX_PREMK executando o script wx-config para obter a string de versão completa, atribuí-lo a uma variável e passá-lo para o programa.

USE_WX=		2.8
WX_PREMK=	yes

.include <bsd.port.pre.mk>

.if exists(${WX_CONFIG})
VER_STR!=	${WX_CONFIG} --release

PLIST_SUB+=	VERSION="${VER_STR}"
.endif

As variaveis wxWidgets ​​podem ser usadas com segurança em comandos quando estão dentro de targets sem a necessidade de WX_PREMK.

6.21.7. Argumentos Adicionais do configure

Alguns scripts GNU configure não podem encontrar wxWidgets com apenas o conjunto de variáveis ​​de ambiente WX_CONFIG, exigindo argumentos adicionais. WX_CONF_ARGS pode ser usado para fornecê-los.

Tabela 38. Valores Legais para WX_CONF_ARGS
Valor possívelArgumento resultante

absolute

--with-wx-config=${WX_CONFIG}

relative

--with-wx=${LOCALBASE} --with-wx-config=${WX_CONFIG:T}

6.22. Usando Lua

Esta seção descreve o status das bibliotecas Lua na árvore de ports e sua integração com o sistema de ports.

6.22.1. Introdução

Existem muitas versões das bibliotecas Lua e interpretadores correspondentes, que entram em conflito entre eles (instalam arquivos com o mesmo nome). Na árvore de ports este problema foi resolvido instalando cada versão sob um nome diferente usando sufixos de número de versão.

A desvantagem óbvia disso é que cada aplicativo precisa ser modificado para encontrar a versão esperada. Mas isto pode ser resolvido adicionando alguns sinalizadores adicionais ao compilador e ao linker.

Aplicativos que usam Lua normalmente devem ser compilados para apenas uma versão. No entanto, os módulos carregáveis para Lua são compilados em flavor separado para cada versão Lua que eles suportam, e as dependências de tais módulos devem especificar o flavor usando o sufixo @${LUA_FLAVOR} no caminho do port.

6.22.2. Seleção de Versão

Um port usando Lua deve ter uma linha dessa forma:

USES=	lua

Se uma versão específica de Lua, ou intervalo de versões for necessária, ela pode ser especificada como um parâmetro na forma XY (que pode ser usado várias vezes), XY+, -XY, ou XY-ZA. A versão padrão do Lua definida por meio do DEFAULT_VERSIONS será usada se cair no intervalo solicitado, caso contrário, a versão solicitada mais próxima do padrão será usada. Por exemplo:

USES=	lua:52-53

Observe que nenhuma tentativa é feita para ajustar a seleção da versão com base na presença de qualquer versão Lua já instalada.

A forma XY+ de especificação de versão não deve ser usada sem consideração cuidadosa; a API Lua muda consideravelmente em todas as versões, e ferramentas de configuração como CMake ou Autoconf frequentemente não funcionarão em versões futuras do Lua até ser atualizado para isso.

6.22.3. Flags de Configuração e Compilador

Software that uses Lua may have been written to auto-detect the Lua version in use. In general ports should override this assumption, and force the use of the specific Lua version selected as described above. Depending on the software being ported, this might require any or all of:

  • Usando LUA_VER como parte de um parâmetro para o script de configuração do software via CONFIGURE_ARGS ou CONFIGURE_ENV (ou equivalente para outros sistemas de compilação);

  • Adicionando -I${LUA_INCDIR}, -L${LUA_LIBDIR}, e -llua-${LUA_VER} para CFLAGS, LDFLAGS, LIBS respectivamente, conforme apropriado;

  • Altere a configuração do software ou arquivos de compilação para selecionar a versão correta.

6.22.4. Flavors de Versão

Um port que instala um módulo Lua (em vez de um aplicativo que simplesmente faz uso do Lua) deve compilar um flavor separado para cada versão do Lua suportada . Isso é feito adicionando o parâmetro module:

USES=	lua:module

Um número de versão ou intervalo de versões também pode ser especificado; use uma vírgula para separar os parâmetros.

Uma vez que cada flavor deve ter um nome de pacote diferente, a variável LUA_PKGNAMEPREFIX é fornecida e será definida com um valor apropriado; o uso pretendido é:

PKGNAMEPREFIX=	${LUA_PKGNAMEPREFIX}

Ports de módulo normalmente devem instalar arquivos apenas em LUA_MODLIBDIR, LUA_MODSHAREDIR, LUA_DOCSDIR, e LUA_EXAMPLESDIR>, todos os quais estão definidos para se referir a subdiretórios específicos da versão. A instalação de quaisquer outros arquivos deve ser feita com cuidado para evitar conflitos entre as versões.

Um port (diferente de um módulo Lua) que deseja compilar um pacote separado para cada versão Lua deve usar o parâmetro flavors:

USES=	lua:flavors

Isso funciona da mesma maneira que o parâmetro module descrito acima, mas sem a suposição de que o pacote deve ser documentado como um módulo Lua (então LUA_DOCSDIR e LUA_EXAMPLESDIR não são definidos por padrão). No entanto, o port pode escolher definir LUA_DOCSUBDIR como um nome de subdiretório adequado (geralmente o PORTNAME do port, desde que não entre em conflito com o PORTNAME de qualquer módulo), caso em que a estrutura definirá LUA_DOCSDIR e LUA_EXAMPLESDIR.

Tal como acontece com os ports de módulo, um port com flavor deve evitar a instalação de arquivos que entrariam em conflito entre as versões. Normalmente, isso é feito adicionando LUA_VER_STR como um sufixo para nomes de programas (por exemplo, usando USES=uniquefiles), e de outra forma usando LUA_VER ou LUA_VER_STR como parte de quaisquer outros arquivos ou subdiretórios usados fora de LUA_MODLIBDIR e LUA_MODSHAREDIR.

6.22.5. Variáveis ​​Definidas

Essas variáveis ​​estão disponíveis no port.

Tabela 39. Variáveis ​​Definidas para Ports Que Usam Lua
NomeDescrição

LUA_VER

A versão Lua que será usada (por exemplo,5,1)

LUA_VER_STR

A versão Lua sem os pontos (por exemplo,51)

LUA_FLAVOR

O nome do flavor correspondente à versão selecionada Lua, a ser usado para especificar dependências

LUA_BASE

O prefixo que deve ser usado para localizar o Lua (e componentes) que já estão instalados

LUA_PREFIX

O prefixo onde o Lua (e os seus componentes) são instalados por este port

LUA_INCDIR

O diretório onde os arquivos header do Lua estão instalados

LUA_LIBDIR

O diretório onde as bibliotecas Lua são instaladas

LUA_REFMODLIBDIR

O diretório no qual as bibliotecas dos módulos Lua (.so) que já estão instalados podem ser encontrados

LUA_REFMODSHAREDIR

O diretório no qual os módulos Lua (.lua) que já estão instalados podem ser encontrados

LUA_MODLIBDIR

O diretório no qual as bibliotecas dos módulos Lua (.so) serão instalados por este port

LUA_MODSHAREDIR

O diretório no qual os módulos Lua (.lua) serão instalados por este port

LUA_PKGNAMEPREFIX

O prefixo do nome do pacote usado por módulos Lua

LUA_CMD

O nome do interpretador Lua (exemplo lua53)

LUAC_CMD

O nome do compilador Lua (exemplo luac53)

Essas variáveis adicionais estão disponíveis para ports que especificaram o parâmetro module:

Tabela 40. Variáveis Definidas para Ports de Módulos Lua
NomeDescrição

LUA_DOCSDIR

o diretório no qual a documentação do módulo deve ser instalada.

LUA_EXAMPLESDIR

o diretório no qual os arquivos de exemplo do módulo devem ser instalados.

6.22.6. Exemplos

Exemplo 29. Makefile para uma aplicação que utiliza Lua

Este exemplo mostra como fazer referência a um módulo Lua necessário em tempo de execução. Observe que a referência deve especificar um flavor.

PORTNAME=	sample
DISTVERSION=	1.2.3
CATEGORIES=	whatever

MAINTAINER=	john@doe.tld
COMMENT=	Sample

RUN_DEPENDS=	${LUA_REFMODLIBDIR}/lpeg.so:devel/lua-lpeg@${LUA_FLAVOR}

USES=		lua

.include <bsd.port.mk>
Exemplo 30. Makefile para módulo simples de Lua
PORTNAME=	sample
DISTVERSION=	1.2.3
CATEGORIES=	whatever
PKGNAMEPREFIX=	${LUA_PKGNAMEPREFIX}

MAINTAINER=	john@doe.tld
COMMENT=	Sample

USES=		lua:module

DOCSDIR=	${LUA_DOCSDIR}

.include <bsd.port.mk>

6.23. Usando iconv

Após 2013-10-08 (r254273), o FreeBSD 10-CURRENT e as versões mais recentes têm um iconv nativo no sistema operacional. Em versões anteriores, o converters/libiconv era usado como dependência.

Para softwares que precisam do iconv, defina USES=iconv. As versões do FreeBSD antes do 10-CURRENT em 2013-08-13 (r254273) não tem um iconv nativo. Nestas versões anteriores, uma dependência do converters/libiconv será adicionada automaticamente.

Quando um port define USES=iconv, estas variáveis ​​estarão disponíveis:

Nome da variávelPropósitoValor antes do FreeBSD 10-CURRENT 254273(2013-08-13)Valor após o FreeBSD 10-CURRENT 254273(2013-08-13)

ICONV_CMD

Diretório onde o binário iconv reside

${LOCALBASE}/bin/iconv

/usr/bin/iconv

ICONV_LIB

argumento do ld para vincular ao libiconv (se necessário)

-liconv

(vazio)

ICONV_PREFIX

Diretório onde a implementação do iconv reside (útil para configurar scripts)

${LOCALBASE}

/usr

ICONV_CONFIGURE_ARG

Argumento de configuração pré-configurado para scripts de configuração

--with-libiconv-prefix=${LOCALBASE}

(vazio)

ICONV_CONFIGURE_BASE

Argumento de configuração pré-configurado para scripts de configuração

--with-libiconv=${LOCALBASE}

(vazio)

Esses dois exemplos preenchem automaticamente as variáveis ​​com o valor correto para sistemas usando respectivamente o converters/libiconv ou o iconv nativo:

Exemplo 31. Simples uso do iconv
USES=		iconv
LDFLAGS+=	-L${LOCALBASE}/lib ${ICONV_LIB}
Exemplo 32. Uso do iconv com configure
USES=		iconv
CONFIGURE_ARGS+=${ICONV_CONFIGURE_ARG}

Como mostrado acima, a variável ICONV_LIB estará vazia quando um iconv nativo estiver presente. Isso pode ser usado para detectar o iconv nativo e responder adequadamente.

Às vezes um programa tem um argumento ld ou caminho de pesquisa codificado em um Makefile ou no script configure. Essa abordagem pode ser usada para resolver esse problema:

Exemplo 33. Corrigindo Hardcoded -liconv
USES=		iconv

post-patch:
	@${REINPLACE_CMD} -e 's/-liconv/${ICONV_LIB}/' ${WRKSRC}/Makefile

Em alguns casos, é necessário definir valores alternativos ou executar operações dependendo se há um iconv nativo. O bsd.port.pre.mk deve ser incluído antes de testar o valor de ICONV_LIB:

Exemplo 34. Verificando Disponibilidade do iconv Nativo
USES=		iconv

.include <bsd.port.pre.mk>

post-patch:
.if empty(ICONV_LIB)
	# native iconv detected
	@${REINPLACE_CMD} -e 's|iconv||' ${WRKSRC}/Config.sh
.endif

.include <bsd.port.post.mk>

6.24. Usando o Xfce

Ports que precisam de bibliotecas ou aplicações Xfce, utilizam USES=xfce.

Dependencias específicas de bibliotecas e aplicativos Xfce são definidas com valores atribuídos a USE_XFCE. Eles são definidos em /usr/ports/Mk/Uses/xfce.mk. Os valores possíveis são:

Valores de USE_XFCE
garcon

sysutils/garcon

libexo

x11/libexo

libgui

x11-toolkits/libxfce4gui

libmenu

x11/libxfce4menu

libutil

x11/libxfce4util

painel

x11-wm/xfce4-panel

thunar

x11-fm/thunar

xfconf

x11/xfce4-conf

Exemplo 35. Exemplo de USES=xfce
USES=		xfce
USE_XFCE=	libmenu
Exemplo 36. Usando os Próprios Widgets GTK2 do Xfce

Neste exemplo, o aplicativo portado usa os widgets específicos do GTK2, o x11/libxfce4menu e o x11/xfce4-conf.

USES=		xfce:gtk2
USE_XFCE=	libmenu xfconf

Os componentes Xfce incluídos dessa maneira incluirão automaticamente todas as dependências necessárias. Não é mais necessário especificar a lista inteira. Se o port precisar apenas de x11-wm/xfce4-panel, use:

USES=		xfce
USE_XFCE=	panel

Não há necessidade de listar os componentes que o x11-wm/xfce4-panel precisa para ele mesmo, desta forma:

USES=		xfce
USE_XFCE=	libexo libmenu libutil panel

Contudo, os componentes Xfce e as dependências do port que não dependem do Xfce devem ser incluídas explicitamente. Não conte com um componente Xfce para fornecer uma sub-dependência diferente de si para o port principal.

6.25. Usando Bancos de Dados

Utilize uma das macros USES de Banco de Dados de Macros USES para adicionar a dependência de um banco de dados.

Tabela 41. Banco de Dados de Macros USES
Base de DadosMacro USES

Berkeley DB

bdb

MariaDB, MySQL, Percona

mysql

PostgreSQL

pgsql

SQLite

sqlite

Exemplo 37. Usando o Berkeley DB 6
USES=	bdb:6

Veja bdb para maiores informações.

Exemplo 38. Usando MySQL

Quando um port precisa da biblioteca cliente do MySQL, adicione

USES=	mysql

Veja mysql para mais informações.

Exemplo 39. Usando PostgreSQL

Quando um port precisar do servidor PostgreSQL versão 9.6 ou posterior, adicione

USES=		pgsql:9.6+
WANT_PGSQL=	server

Veja pgsql para mais informações.

Exemplo 40. Usando SQLite 3
USES=	sqlite:3

Veja sqlite para mais informações.

6.26. Iniciando e Parando Serviços (com scripts rc)

Os scripts rc.d são usados ​​para iniciar serviços na inicialização do sistema e para fornecer aos administradores uma maneira padrão de parar, iniciar e reiniciar o serviço. Ports se integram ao sistema de estrutura do rc.d. Detalhes sobre seu uso podem ser encontrados no capitulo sobre rc.d do handbook. A explicação detalhada dos comandos disponíveis é fornecida em rc(8) e rc.sub(8). Finalmente, existe um artigo sobre aspectos práticos do sistema de scripts do rc.d.

Com um port mítico chamado doorman, o qual precisa iniciar um daemon doormand. Adicione o seguinte ao Makefile:

USE_RC_SUBR=	doormand

Vários scripts podem ser listados e serão instalados. Os scripts devem ser colocados no subdiretório files e um sufixo .in deve ser adicionado ao nome do arquivo. Expansões padrões SUB_LIST serão executadas neste arquivo. Usar as expansões %%PREFIX%% e %%LOCALBASE%% também é fortemente encorajado. Veja mais sobre a SUB_LIST na seção relevante.

A partir do FreeBSD 6.1-RELEASE, scripts locais rc.d (incluindo aqueles instalados pelos ports) estão incluídos no rcorder(8) do sistema base.

Um exemplo simples de script rc.d para iniciar o daemon doormand:

#!/bin/sh

# $FreeBSD: head/pt_BR.ISO8859-1/books/porters-handbook/book.xml 54410 2020-08-05 22:13:01Z dbaio $
#
# PROVIDE: doormand
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add these lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# doormand_enable (bool):	Set to NO by default.
#				Set it to YES to enable doormand.
# doormand_config (path):	Set to %%PREFIX%%/etc/doormand/doormand.cf
#				by default.

. /etc/rc.subr

name=doormand
rcvar=doormand_enable

load_rc_config $name

: ${doormand_enable:="NO"}
: ${doormand_config="%%PREFIX%%/etc/doormand/doormand.cf"}

command=%%PREFIX%%/sbin/${name}
pidfile=/var/run/${name}.pid

command_args="-p $pidfile -f $doormand_config"

run_rc_command "$1"

A menos que haja uma boa razão para iniciar o serviço mais cedo, ou ele seja executado como um usuário específico (diferente de root), todos os scripts de ports devem usar:

REQUIRE: LOGIN

Se o script de inicialização iniciar um daemon que deve ser desligado, o seguinte acionará uma parada do serviço no desligamento do sistema:

KEYWORD: shutdown

Se o script não está iniciando um serviço persistente, isso não é necessário.

Para os elementos de configuração opcional o estilo "=" de atribuição de variável padrão é preferível ao estilo ":=", já que o primeiro define um valor padrão apenas se a variável não estiver definida, e o segundo define um se a variável não está definida ou se ela é nula. Um usuário pode muito bem incluir algo como:

doormand_flags=""

no seu rc.conf.local, e uma substituição de variável usando ":=" substituirá inadequadamente a intenção do usuário. A variável _enable não é opcional e deve usar o ":" por padrão.

Os Ports não devem iniciar e parar seus serviços durante a instalação e desinstalação. Não abuse das keywords plist descritas em @preexec command, @postexec command, @preunexec command, @postunexec command executando comandos que modificam o sistema em execução, incluindo iniciar ou interromper serviços.

6.26.1. Pre-Commit Checklist

Antes de contribuir um port com um script rc.d, e mais importante, antes de realizar o commit de um, por favor consulte esta lista de verificação para ter certeza de que ele está pronto.

O port devel/rclint pode verificar a maioria destes itens, mas não substitui uma revisão adequada.

  1. Se este é um novo arquivo, ele tem uma extensão .sh? Se assim for, isso deve ser mudado para apenas file.in uma vez que os arquivos rc.d não podem terminar com essa extensão.

  2. O arquivo tem uma tag $FreeBSD: head/pt_BR.ISO8859-1/books/porters-handbook/book.xml 54410 2020-08-05 22:13:01Z dbaio $?

  3. O nome do arquivo (menos .in), a linha PROVIDE e $ name são as mesmas? O nome do arquivo ao corresponder com o PROVIDE irá facilitar a depuração, especialmente para problemas de rcorder(8). Combinar o nome do arquivo e o $ name torna mais fácil descobrir quais variáveis ​​são relevantes no rc.conf[.local]. Isso também é uma política para todos os novos scripts, incluindo aqueles no sistema base.

  4. A linha REQUIRE está definida para LOGIN? Isso é obrigatório para scripts que são executados como um usuário não root. Se ele for executado como root, há uma boa razão para ele ser executado antes de LOGIN? Caso contrário, ele deve ser executado depois para que os scripts locais possam ser agrupados em um ponto no rcorder(8) depois que quase tudo no sistema base já estiver rodando.

  5. O script inicia um serviço persistente? Em caso afirmativo, ele deve ter o KEYWORD: shutdown.

  6. Certifique-se de que não há um KEYWORD: FreeBSD presente. Isto não foi necessário nem desejável durante anos. Isto também é uma indicação de que o novo script foi copiado/colado de um script antigo, portanto, um cuidado extra deve ser dado à revisão.

  7. Se o script usa uma linguagem interpretada como o perl, o python ou o ruby, certifique-se de que o command_interpreter está definido adequadamente, por exemplo, para o Perl, adicione PERL=${PERL} para a SUB_LIST e utilize %%PERL%%. De outra forma,

    # service name stop

    provavelmente não funcionará corretamente. Consulte service(8) para maiores informações.

  8. Todas as ocorrências de /usr/local foram substituídas por %%PREFIX%%?

  9. As atribuições das variáveis ​​padrão vêm depois de load_rc_config?

  10. Existem atribuições padrões para sequências vazias? Elas devem ser removidas, mas verifique se a opção está documentada nos comentários na parte superior do arquivo.

  11. As variáveis ​​definidas estão realmente sendo utilizadas no script?

  12. As opções listadas no padrão name _flags são realmente obrigatórias? Se assim for, elas devem estar em command_args. A opção -d é uma flag vermelha (com o perdão do trocadilho) aqui, já que geralmente é a opção de "daemonizar" o processo e, portanto, é realmente obrigatório.

  13. O name_flags nunca deve ser incluído em command_args (e vice-versa, embora esse erro seja menos comum).

  14. O script executa qualquer código incondicionalmente? Isso é desaprovado. Normalmente, essas coisas devem ser tratadas através de um start_precmd.

  15. Todos os testes booleanos devem usar a função checkyesno. Nenhum teste deve usar [Yy][Ee][Ss], etc.

  16. Se houver um loop (por exemplo, esperando que algo inicie), ele tem um contador para terminar o loop? Não queremos que a inicialização seja bloqueada para sempre se houver um erro.

  17. O script cria arquivos ou diretórios que precisam de permissões específicas, por exemplo, um pid que precisa ser de propriedade do usuário que executa o processo? Em vez da rotina tradicional touch(1)/chown(8)/chmod(1), considere usar install(1) com os argumentos de linha de comando apropriados para fazer todo o procedimento com um passo.

6.27. Adicionando Usuários e Grupos

Alguns ports exigem que uma conta de usuário específica esteja presente, geralmente para daemons executados como esse usuário. Para esses ports, escolha um UID único entre 50 a 999 e registre-o em ports/UIDs (para usuários) e em ports/GIDs(para grupos). A identificação única deve ser a mesma para usuários e grupos.

Por favor, inclua um patch para estes dois arquivos quando for necessário que um novo usuário ou grupo seja criado para o port.

Então use USERS e GROUPS dentro do Makefile e o usuário será criado automaticamente ao instalar o port.

USERS=	pulse
GROUPS=	pulse pulse-access pulse-rt

A lista atual de UIDs e GIDs reservados pode ser encontrada em ports/UIDs e ports/GIDs.

6.28. Ports que Dependem dos Fontes do kernel

Alguns ports (como módulos carregáveis ​​do kernel) precisam dos arquivos fonte do kernel para que o port possa ser compilado. Aqui está a maneira correta de determinar se o usuário os instalou:

USES=	kmod

Além desta verificação, o recurso kmod cuida da maioria dos itens que esses ports precisam levar em consideração.

6.29. Bibliotecas Go

Os ports não devem empacotar ou instalar bibliotecas Go ou código-fonte. Os ports Go devem baixar as dependências na hora da compilação e devem instalar apenas programas que os usuários precisam, e não o que os desenvolvedores Go precisam.

Ports devem (por ordem de preferência):

  • Usar as dependências fornecidas no código fonte do pacote.

  • Baixar as versões das dependências especificadas pelo upstream (no caso do go.mod, vendor.json ou similar).

  • Como um último recurso (as dependências não estão incluídas e nem as versões foram especificadas exatamente) busque as versões das dependências disponíveis no momento do desenvolvimento/release.

6.30. Bibliotecas Haskell

Assim como na linguagem Go, Ports não devem empacotar ou instalar as bibliotecas Haskell. Os ports Haskell devem vincular estaticamente a suas dependências e buscar todos os arquivos de distribuição no estágio fetch.

6.31. Arquivos Shell Completion

Muitos shells modernos (incluindo bash, tcsh e zsh) suportam parâmetro e/ou opção de tab-completion. Esse suporte geralmente vem de arquivos completion, os quais contêm as definições de como as tabs completion funcionarão para um determinado comando. As vezes ports vem com seus arquivos completion, ou os mantenedores de ports podem ter criado um eles mesmos.

Quando disponível, os arquivos de completion devem sempre ser instalados. Não é necessário fazer uma opção para eles. Apesar que se uma opção for usada, sempre habilite-a em OPTIONS_DEFAULT.

Tabela 42. Caminhos dos arquivos shell completion

bash

${PREFIX}/etc/bash_completion.d

zsh

${PREFIX}/shared/zsh/site-functions

Não registre nenhuma dependência nos próprios shells.

Última alteração em: 9 de março de 2024 por Danilo G. Baio

Início