Capítulo 17. Using USES Macros

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

Índice

17.1. Uma introdução ao USES

As macros USES facilitam declarar requisitos e configurações de um port. Elas podem adicionar dependências, alterar o comportamento de compilação do port, adicionar metadados a pacotes e assim por diante, tudo selecionando valores simples e predefinidos.

Cada seção deste capítulo descreve um possível valor para USES , juntamente com seus possíveis argumentos. Argumentos são anexados ao valor após dois pontos ( : ). Vários argumentos são separados por vírgulas ( , ).

Exemplo 1. Usando Vários Valores 
USES=	bison perl
Exemplo 2. Adicionando um Argumento 
USES=	tar:xz
Exemplo 3. Adicionando Vários Argumentos 
USES=	drupal:7,theme
Exemplo 4. Entrelaçando Tudo Isso Junto 
USES=	pgsql:9.3+ cpe python:2.7,build

17.2. 7z

Argumentos possíveis: (none), p7zip , partial

Extrair usando 7z(1) ao invés de bsdtar(1) e definir EXTRACT_SUFX=.7z . A opção p7zip força uma dependência do 7z a partir de archivers/p7zip se aquele do sistema base não for capaz de extrair os arquivos. EXTRACT_SUFX não é alterado se a opção partial é usada, isso pode ser usado se o arquivo de distribuição principal não tiver extensão .7z .

17.3. ada

Argumentos possíveis: (none), 5 , 6

Depende de um compilador capaz de usar Ada e define a variável CC de acordo. O padrão é usar gcc 5 do ports. Use a opção de versão :X para forçar a compilação com uma versão diferente.

17.4. autoreconf

Argumentos possíveis: (none), build

Execute autoreconf . Ele encapsula os comandos aclocal , autoconf , autoheader , automake , autopoint e libtoolize . Cada comando aplica-se a ${AUTORECONF_WRKSRC} /configure.ac ou seu nome antigo ${AUTORECONF_WRKSRC}/configure.in . E se configure.ac define subdiretórios com seus próprios configure.ac usando AC_CONFIG_SUBDIRS , autoreconf irá recursivamente atualizar aqueles também. O argumento :build só adiciona dependências de build-time sobre essas ferramentas, mas não executa o autoreconf . Um port pode definir AUTORECONF_WRKSRC se WRKSRC não contiver o caminho para o configure.ac .

17.5. blaslapack

Argumentos possíveis: (none), atlas , netlib (padrão), gotoblas , openblas

Adiciona dependências das bibliotecas Blas / Lapack.

17.6. bdb

Argumentos possíveis: (none), 48 , 5 (padrão), 6

Adiciona uma dependência à biblioteca Berkeley DB. O padrão utiliza databases/db5 . Também pode depender de databases/db48 ao usar o argumento :48 ou databases/db6 com :6 . É possível declarar um intervalo de valores aceitáveis, :48+ procura pela versão maior instalada e utiliza a 4.8 se nenhuma outra estiver instalada. INVALID_BDB_VER pode ser usado para especificar versões que não funcionam com este port. O framework expõe as seguintes variáveis ao port:

BDB_LIB_NAME

O nome da biblioteca Berkeley DB. Por exemplo, ao usar databases/db5 , contém db-5.3 .

BDB_LIB_CXX_NAME

O nome da biblioteca Berkeley DBC++. Por exemplo, ao usar databases/db5 , contém db_cxx-5.3 .

BDB_INCLUDE_DIR

A localização do diretório incluso Berkeley DB. Por exemplo, ao usar databases/db5 , ele irá conter ${LOCALBASE}/include/db5 .

BDB_LIB_DIR

A localização do diretório da biblioteca Berkeley DB. Por exemplo, ao usar databases/db5 , contém ${LOCALBASE}/lib .

BDB_VER

A versão detectada de Berkeley DB. Por exemplo, se estiver usando USES=bdb:48+ e Berkeley DB 5 estiver instalado, irá conter 5 .

databases/db48 está obsoleto e não é suportado. Não deve ser usado por nenhum port.

17.7. bison

Argumentos possíveis: (none), build , run , both

Utiliza devel/bison por padrão, sem argumentos ou com o argumento build , isso implica que bison seja uma dependência de build-time, run implica como dependência de run-time e both implica em dependências build-time e run-time.

17.8. cabal

Não devem ser criados Ports de bibliotecas Haskell, veja Bibliotecas Haskell para maiores informações.

Argumentos possíveis: (none), hpack

Define valores e targets padrões usados para compilar software Haskell usando o Cabal. Uma dependência de compilação no port do compilador Haskell (GHC) é adicionada. Se o argumento hpack for fornecido, uma dependência de compilação do devel/hs-hpack será adicionada e o hpack será chamado na etapa de configuração para gerar o arquivo .cabal.

O framework fornece as seguintes variáveis:

USE_CABAL

Se o software usar dependências Haskell, liste-as nesta variável. Cada item deve estar presente no Hackage e ser listado no formato packagename- 0.1.2 . As dependências podem ter revisões, especificadas após o símbolo _ . A geração automática de lista de dependências é suportada, consulte Compilando Aplicações Haskell com cabal .

CABAL_FLAGS

Lista de flags a serem passadas para o cabal-install durante o estágio de configuração e compilação. As flags são passadas sem alterações (verbatim).

EXECUTABLES

Lista de arquivos executáveis instalados pelo port. Valor padrão: ${PORTNAME} . Os itens desta lista são adicionados automaticamente ao pkg-plist.

SKIP_CABAL_PLIST

Se definido, não adicione itens ${EXECUTABLES} ao pkg-plist.

opt_USE_CABAL

Adiciona itens ao ${USE_CABAL} , dependendo da opção opt .

opt_EXECUTABLES

Adiciona itens ao ${EXECUTABLES} , dependendo da opção opt .

opt_CABAL_FLAGS

Se a opção opt estiver ativada, acrescente o valor a ${CABAL_FLAGS} . Caso contrário, anexe -value para desativar a flag.

FOO_DATADIR_VARS

Para um executável chamado FOO , liste os pacotes Haskell, cujos arquivos de dados devem estar acessíveis pelo executável.

17.9. cargo

Argumentos possíveis: (none)

Utiliza Cargo para configuração, compilação e testes. Ele pode ser usado para portar aplicativos Rust que usam o sistema de build Cargo. Para obter mais informações, consulte Compilando Aplicações Rust com cargo ..

17.10. charsetfix

Argumentos possíveis: (none)

Previne que o port instale arquivos charset.alias . Estes arquivos devem ser instalados apenas pelo converters/libiconv . CHARSETFIX_MAKEFILEIN pode ser definido para um caminho relativo ao WRKSRC se charset.alias não for instalado pelo ${WRKSRC}/Makefile.in .

17.11. cmake

Argumentos possíveis: (none), env , notall , noman

Utiliza QMake para configuração e compilação.

Por padrão, uma compilação out-of-source é executada, deixando os fontes em WRKSRC livres de artefatos de compilação. Com o argumento insource , uma compilação in-source será executada. A configuração deste argumento deve ser a exceção quando uma compilação regular out-of-source não funcionar.

Por padrão, o argumento Ninja é usado para a compilação. Em alguns casos isso não funciona corretamente. Com o argumento noninja , a compilação irá usar o make para as compilações. Ele só deve ser usado se uma compilação baseada no Ninja não funcionar.

Com o argumento run , uma dependência de execução é registrada além de uma dependência de compilação.

Para maiores informações, veja Usando o cmake .

17.12. compiler

Argumentos possíveis: (none), env (padrão, implícito) c++17-lang, c++14-lang, c++11-lang, gcc-c++11-lib, c++11-lib, c++0x, c11, openmp, nestedfct, features

Determina qual compilador usar com base em qualquer um desejo. Use c++17-lang se o port precisar de um compilador compatível com c++17, c++14-lang se o port precisar de um compilador compatível com c++14, c++11-lang se o port precisar de um compilador compatível com c++11, gcc-c++11-lib se o port precisar do compilador {gcc-plus-plus} com uma biblioteca c++11, ou c++11-lib se o port precisar de uma biblioteca padrão c++11-ready. Se o port precisar de um compilador que compreenda as funções c++0X, C11, OpenMP ou funções aninhadas, os parâmetros correspondentes deverão ser usados.

Use features para solicitar uma lista de recursos suportados pelo compilador padrão. Depois de incluir o arquivo bsd.port.pre.mk o port pode inspecionar os resultados usando estas variáveis:

  • COMPILER_TYPE : o compilador padrão no sistema, gcc ou clang

  • ALT_COMPILER_TYPE : o compilador alternativo no sistema, gcc ou clang. Apenas definido se dois compiladores estiverem presentes na base do sistema.

  • COMPILER_VERSION : os dois primeiros dígitos da versão do compilador padrão.

  • ALT_COMPILER_VERSION : os dois primeiros dígitos da versão do compilador alternativo, se presente.

  • CHOSEN_COMPILER_TYPE : o compilador escolhido, gcc ou clang

  • COMPILER_FEATURES : os recursos suportados pelo compilador padrão. Atualmente lista a biblioteca C++.

17.13. cpe

Argumentos possíveis: (none)

Inclui informações da Common Platform Enumeration (CPE) no manifesto do pacote como uma string CPE 2.3 formatada. Veja as especificações CPE para mais detalhes. Para adicionar informações de CPE a um port, siga estas etapas:

  1. Procure pelo registro oficial CPE para o produto de software, usando o mecanismo de pesquisa CPE do NVD ou no dicionário oficial CPE (aviso, o arquivo XML é muito grande). Nunca crie os dados da CPE.

  2. Adicione cpe na variável USES e compare o resultado de make -V CPE_STR com o registro no dicionário CPE. Continue com um passo de cada vez até make -V CPE_STR ficar correto.

  3. Se o nome do produto (segundo campo, com o valor padrão para PORTNAME ) estiver incorreto, defina CPE_PRODUCT .

  4. Se o nome do fornecedor (primeiro campo, com o valor padrão para CPE_PRODUCT ) estiver incorreto, defina CPE_VENDOR .

  5. Se o campo de versão (terceiro campo, com o valor padrão para PORTVERSION ) estiver incorreto, defina CPE_VERSION .

  6. Se o campo de atualização (quarto campo, valor padrão vazio) estiver incorreto, defina CPE_UPDATE .

  7. Se ainda não estiver correto, verifique o arquivo Mk/Uses/cpe.mk para detalhes adicionais, ou entre em contato com o Ports Security Team ports-secteam@FreeBSD.org .

  8. Derive o máximo possível do nome CPE a partir de variáveis ​​existentes, tal como as variáveis PORTNAME e PORTVERSION . Use modificadores de variáveis ​​para extrair as partes relevantes delas, em vez de colocar o nome direto no código.

  9. Sempre execute make -V CPE_STR e verifique a saída antes de fazer o commit de qualquer coisa que mude o PORTNAME ou PORTVERSION ou qualquer outra variável que é usada para derivar a variável CPE_STR .

17.14. cran

Argumentos possíveis: (none), auto-plist , compiles

Utiliza a Comprehensive R Archive Network. Especifique auto-plist para gerar automaticamente o arquivo pkg-plist . Especifique compiles se o port tiver código que precise ser compilado.

17.15. desktop-file-utils

Argumentos possíveis: (none)

Utiliza update-desktop-database a partir de devel/desktop-file-utils . Uma etapa extra de post-install será executada sem interferir em nenhuma etapa de post-install que já esteja no Makefile do port. Uma linha com @desktop-file-utils será adicionada ao plist.

17.16. desthack

Argumentos possíveis: (none)

Altera o comportamento do GNU configure para suportar corretamente a variável DESTDIR no caso do software original não suportar.

17.17. display

Argumentos possíveis: (none), ARGS

Define um display environment virtual. Se a variável de ambiente DISPLAY não estiver definida, então Xvfb é adicionado como uma dependência de compilação e a variável CONFIGURE_ENV é estendida com o número do port da instância do Xvfb em execução no momento. O parâmetro ARGS é definido como install por padrão e controla a fase na qual se inicia e para a exibição virtual.

17.18. dos2unix

Argumentos possíveis: (none)

O port tem arquivos com terminações de linha no formato do DOS que precisam ser convertidos. Inúmeras variáveis ​​podem ser definidas para controlar quais arquivos serão convertidos. O padrão é converter todos arquivos, incluindo binários. Veja Substituições Automáticas Simples para exemplos.

  • DOS2UNIX_REGEX : casa nomes de arquivos com base em uma expressão regular.

  • DOS2UNIX_FILES : casa com nomes de arquivos literais.

  • DOS2UNIX_GLOB : casa com nomes de arquivos baseados em um padrão glob.

  • DOS2UNX_WRKSRC : o diretório onde iniciar as conversões. O padrão é ${WRKSRC} .

17.19. drupal

Argumentos possíveis: 7 , module , theme

Automatiza a instalação de um port que é um tema ou módulo Drupal. Use com a versão Drupal que o port está esperando. Por exemplo, USES=drupal:7,module diz que este port cria um módulo do Drupal 6. Um tema do Drupal 7 pode ser especificado com USES=drupal:7,theme .

17.20. fakeroot

Argumentos possíveis: (none)

Altera alguns comportamentos padrão dos sistemas de compilação para permitir instalar como um usuário normal. Veja https://wiki.debian.org/FakeRoot para mais informações sobre fakeroot .

17.21. fam

Argumentos possíveis: (none), fam , gamin

Usa um File Alteration Monitor como uma dependência de biblioteca, devel/fam ou devel/gamin . Usuários finais podem definir WITH_FAM_SYSTEM para especificar sua preferência.

17.22. firebird

Argumentos possíveis: (none), 25

Adiciona uma dependência da biblioteca client do banco de dados do Firebird.

17.23. fonts

Argumentos possíveis: (none), fc , fcfontsdir (padrão), fontsdir , none

Adiciona uma dependência de tempo de execução nas ferramentas necessárias para registrar fontes. Dependendo do argumento, adiciona entradas para o plist @fc ${FONTSDIR} , @fcfontsdir ${FONTSDIR} , @fontsdir ${FONTSDIR} , ou nenhuma entrada se o argumento for none . Valor padrão de FONTSDIR é ${PREFIX}/shared/fonts/${FONTNAME} e FONTNAME é ${PORTNAME} . Adiciona FONTSDIR para PLIST_SUB e SUB_LIST

17.24. fortran

Argumentos possíveis: gcc (padrão)

Usa o compilador GNU Fortran.

17.25. fuse

Argumentos possíveis: 2 (padrão), 3

O port irá depender da biblioteca FUSE e irá manipular a dependência do módulo do kernel dependendo da versão do FreeBSD.

17.26. gem

Argumentos possíveis: (none), noautoplist

Manipula a compilação com RubyGems. Se noautoplist for usado, a lista de empacotameno não será gerada automaticamente.

17.27. gettext

Argumentos possíveis: (none)

Descontinuado. Incluirá ambos gettext-runtime e gettext-tools .

17.28. gettext-runtime

Argumentos possíveis: (none), lib (padrão), build , run

Utiliza devel/gettext-runtime . Por padrão, sem argumentos ou com o argumento lib , implica uma dependência da biblioteca libintl.so . build e run implicam, respectivamente, uma dependência de gettext em build-time e run-time.

17.29. gettext-tools

Argumentos possíveis: (none), build (padrão), run

Utiliza devel/gettext-tools . Por padrão, sem argumento ou com o argumento build , uma dependência de msgfmt em build-time é registrada. Com o argumento run , uma dependência em run-time é registrada.

17.30. ghostscript

Argumentos possíveis: X , build , run , nox11

Uma versão X específica pode ser usada. Versões possíveis são 7 , 8 , 9 e agpl (padrão). nox11 indica que a versão -nox11 do port é necessária. build e run adicionam dependências de Ghostscript em build-time e run-time. O padrão é ambas as dependências, build-time e run-time.

17.31. gl

Argumentos possíveis: (none)

Fornece uma maneira fácil para depender dos componentes GL. Os componentes devem ser listados na variável USE_GL . Os componentes disponíveis são:

egl

adiciona uma dependência de biblioteca libEGL.so de graphics/libglvnd

gbm

Adiciona uma dependência de biblioteca libgbm.so de graphics/mesa-libs

gl

Adiciona uma dependência de biblioteca libGL.so de graphics/libglvnd

glesv2

Adiciona uma dependência de biblioteca libGLESv2.so de graphics/libglvnd

glew

Adiciona uma dependência de biblioteca libGLEW.so de graphics/glew

glu

Adiciona uma dependência de biblioteca libGLU.so de graphics/libGLU

glut

Adiciona uma dependência de biblioteca libglut.so de graphics/freeglut

opengl

Adiciona uma dependência de biblioteca libOpenGL.so de graphics/libglvnd

17.32. gmake

Argumentos possíveis: (none)

Utiliza devel/gmake como uma dependência em run-time e configura o ambiente para usar gmake como make padrão para a compilação.

17.33. gnome

Argumentos possíveis: (none)

Fornece uma maneira fácil para depender dos componentes do GNOME. Os componentes devem ser listados na variável USE_GNOME . Os componentes disponíveis são:

  • atk

  • atkmm

  • cairo

  • cairomm

  • dconf

  • esound

  • evolutiondataserver3

  • gconf2

  • gconfmm26

  • gdkpixbuf

  • gdkpixbuf2

  • glib12

  • glib20

  • glibmm

  • gnomecontrolcenter3

  • gnomedesktop3

  • gnomedocutils

  • gnomemenus3

  • gnomemimedata

  • gnomeprefix

  • gnomesharp20

  • gnomevfs2

  • gsound

  • gtk-update-icon-cache

  • gtk12

  • gtk20

  • gtk30

  • gtkhtml3

  • gtkhtml4

  • gtkmm20

  • gtkmm24

  • gtkmm30

  • gtksharp20

  • gtksourceview

  • gtksourceview2

  • gtksourceview3

  • gtksourceviewmm3

  • gvfs

  • intlhack

  • intltool

  • introspection

  • libartlgpl2

  • libbonobo

  • libbonoboui

  • libgda5

  • libgda5-ui

  • libgdamm5

  • libglade2

  • libgnome

  • libgnomecanvas

  • libgnomekbd

  • libgnomeprint

  • libgnomeprintui

  • libgnomeui

  • libgsf

  • libgtkhtml

  • libgtksourceviewmm

  • libidl

  • librsvg2

  • libsigc++12

  • libsigc++20

  • libwnck

  • libwnck3

  • libxml++26

  • libxml2

  • libxslt

  • metacity

  • nautilus3

  • orbit2

  • pango

  • pangomm

  • pangox-compat

  • py3gobject3

  • pygnome2

  • pygobject

  • pygobject3

  • pygtk2

  • pygtksourceview

  • referencehack

  • vte

  • vte3

A dependência padrão é em built-time e run-time, pode ser alterada com :build ou :run . Por exemplo: 

USES=		gnome
USE_GNOME=	gnomemenus3:build intlhack

Veja Usando o GNOME para maiores informações.

17.34. go

Não devem ser criados Ports de bibliotecas Go, veja Bibliotecas Go para maiores informações.

Argumentos possíveis: (none), modules , no_targets , run

Define valores e targets padrão usados para compilar aplicações Go. Uma dependência de compilação no port do compilador Go selecionada via GO_PORT é adicionada. Por padrão, a compilação é executada no modo GOPATH. Se o software Go usar módulos, o modo de reconhecimento de módulos pode ser ativado com o argumento modules . no_targets irá configurar o ambiente de compilação com GO_ENV , GO_BUILDFLAGS mas irá pular os targets post-extract e do-{build,install,test} . run também adicionará uma dependência de tempo de execução do que estiver em GO_PORT .

O processo de compilação é controlado por várias variáveis:

GO_PKGNAME

O nome do pacote Go ao compilar no modo GOPATH. Este é o diretório que será criado em ${GOPATH}/src . Se não estiver definido explicitamente e GH_SUBDIR ou GL_SUBDIR estiverem presente, o valor GO_PKGNAME será inferido deles. Isso não é necessário quando compilado no modo de reconhecimento de módulos.

GO_TARGET

Os pacotes a serem compilados. O valor padrão é ${GO_PKGNAME} . GO_TARGET também pode ser uma tupla na forma package:path onde path pode ser um nome de arquivo simples ou um caminho completo começando com ${PREFIX} .

GO_TESTTARGET

Os pacotes para testar. O valor padrão é ./…​ (o pacote atual e todos os subpacotes).

CGO_CFLAGS

Valores adicionais da variável CFLAGS a serem passados ​​para o compilador C pelo Go .

CGO_LDFLAGS

Valores adicionais da variável LDFLAGS a serem passados ​​para o compilador C pelo Go .

GO_BUILDFLAGS

Argumentos de compilação adicionais para passar para o go build .

GO_TESTFLAGS

Argumentos de compilação adicionais para passar para o go test .

GO_PORT

O port do compilador Go a ser utilizado. Por padrão é lang/go mas pode ser definido para lang/go-devel no make.conf para testes de futuras versões Go.

Esta variável não deve ser definida por ports individuais!

Ver Compilando Aplicações Go para exemplos de uso.

17.35. gperf

Argumentos possíveis: (none)

Adiciona uma dependência devel/gperf em buildtime se gperf não estiver presente no sistema base.

17.36. grantlee

Argumentos possíveis: 5 , selfbuild

Manipula a dependência em Grantlee. Especifique 5 para depender da versão baseada no Qt5, devel/grantlee5 . selfbuild é usado internamente pelo devel/grantlee5 para obter os números de suas versões.

17.37. groff

Argumentos possíveis: build , run , both

Registra uma dependência de textproc/groff se não estiver presente no sistema base.

17.38. gssapi

Argumentos possíveis: (none), base (padrão), heimdal , mit , flags , bootstrap

Manipular as dependências necessárias para os consumers do GSS-API. Apenas as bibliotecas que fornecem os mecanismos do Kerberos estão disponíveis. Por padrão, ou definido como base , a biblioteca GSS-API do sistema base é usada. Também pode ser definido para heimdal para usar security/heimdal ou mit para usar security/krb5 .

Quando a instalação local do Kerberos não está em LOCALBASE defina a variável HEIMDAL_HOME (para heimdal ) ou a variável KRB5_HOME (para krb5 ) para a instalação local do Kerberos.

Essas variáveis ​​são exportadas para os ports para serem usadas:

  • GSSAPIBASEDIR

  • GSSAPICPPFLAGS

  • GSSAPIINCDIR

  • GSSAPILDFLAGS

  • GSSAPILIBDIR

  • GSSAPILIBS

  • GSSAPI_CONFIGURE_ARGS

As opções de flags podem estar lado a lado com base , heimdal ou mit para adicionar automaticamente GSSAPICPPFLAGS , GSSAPILDFLAGS e GSSAPILIBS para CFLAGS , LDFLAGS e LDADD , respectivamente. Por exemplo, use base,flags .

A opção bootstrap é um prefixo especial apenas para o uso do security/krb5 e security/heimdal . Por exemplo, use bootstrap,mit .

Exemplo 5. Uso Típico 
OPTIONS_SINGLE=	GSSAPI
OPTIONS_SINGLE_GSSAPI=	GSSAPI_BASE GSSAPI_HEIMDAL GSSAPI_MIT GSSAPI_NONE

GSSAPI_BASE_USES=	gssapi
GSSAPI_BASE_CONFIGURE_ON=	--with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS}
GSSAPI_HEIMDAL_USES=	gssapi:heimdal
GSSAPI_HEIMDAL_CONFIGURE_ON=	--with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS}
GSSAPI_MIT_USES=	gssapi:mit
GSSAPI_MIT_CONFIGURE_ON=	--with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS}
GSSAPI_NONE_CONFIGURE_ON=	--without-gssapi

17.39. horde

Argumentos possíveis: (none)

Adicionar dependências de builtime e runtime em devel/pear-channel-horde . Outras dependências Horde podem ser adicionadas com USE_HORDE_BUILD e USE_HORDE_RUN . Veja Módulos Horde para maiores informações.

17.40. iconv

Argumentos possíveis: (none), lib , build , patch , translit , wchar_t

Utilização de funções iconv , seja do port converters/libiconv como uma dependência de buil-time e run-time, ou do sistema base em um 10-CURRENT após um iconv nativo ser comitado em r254273 . Por padrão, sem argumentos ou com o argumento lib , implica em iconv com dependências de build-time e run-time. build implica uma dependência de build-time e patch implica uma dependência de patch-time. Se o port usa extensões iconv WCHAR_T ou //TRANSLIT , adicione os argumentos relevantes para que o iconv correto seja usado. Para mais informações, veja Usando iconv .

17.41. imake

Argumentos possíveis: (none), env , notall , noman

Adiciona devel/imake como uma dependência de built-time e executa xmkmf -a durante o estágio configure . Se o argumento env é passado, o target configure não é definido. Se a flag -a for um problema para o port, adicione o argumento notall . E se xmkmf não gerar um target install.man , adicione o argumento noman .

17.42. kde

Argumentos possíveis: 5

Adiciona dependência de componentes KDE. Veja Usando o KDE para maiores informações.

17.43. kmod

Argumentos possíveis: (none), debug

Preenche o boilerplate para os ports de módulo do kernel, atualmente:

  • Adiciona kld em CATEGORIES .

  • Define SSP_UNSAFE .

  • Defina IGNORE se as fontes do kernel não forem encontradas em SRC_BASE .

  • Define KMODDIR para /boot/modules por padrão, adiciona isso para a variável PLIST_SUB e MAKE_ENV , e o cria após a instalação. Se a variável KMODDIR está definida para o /boot/kernel , ela será reescrita para /boot/modules . Isso evita quebrar pacotes ao atualizar o kernel devido ao /boot/kernel ser renomeado para /boot/kernel.old no processo.

  • Manipula módulos cross-referencing do kernel acerca da instalação e desinstalação, usando @kld .

  • Se o argumento debug é passado, o port pode instalar uma versão de debug do módulo no arquivo KERN_DEBUGDIR / KMODDIR . Por padrão, a variável KERN_DEBUGDIR é copiada da DEBUGDIR e definido para /usr/lib/debug . O framework irá cuidar da criação e remoção de quaisquer diretórios necessários.

17.44. lha

Argumentos possíveis: (none)

Define EXTRACT_SUFX para .lzh

17.45. libarchive

Argumentos possíveis: (none)

Registra uma dependência de archivers/libarchive . Quaisquer ports dependendo de libarchive deve incluir USES=libarchive .

17.46. libedit

Argumentos possíveis: (none)

Registra uma dependência de devel/libedit . Quaisquer ports dependendo de libedit devem incluir USES=libedit .

17.47. libtool

Argumentos possíveis: (none), keepla , build

Scripts libtool de patches. Isso deve ser adicionado a todos os ports que usam libtool . O argumento keepla pode ser usado para manter arquivos .la . Alguns ports não vêm com sua própria cópia da libtool e precisam de uma dependência de devel/libtool em build time, use o argumento :build para adicionar essa dependência.

17.48. linux

Argumentos possíveis: c6 , c7

Framework de compatibilidade de ports com Linux. Especifique c6 para depender de pacotes do CentOS 6. Especifique c7 para depender de pacotes do CentOS 7. Os pacotes disponíveis são:

  • allegro

  • alsa-plugins-oss

  • alsa-plugins-pulseaudio

  • alsalib

  • atk

  • avahi-libs

  • base

  • cairo

  • cups-libs

  • curl

  • cyrus-sasl2

  • dbusglib

  • dbuslibs

  • devtools

  • dri

  • expat

  • flac

  • fontconfig

  • gdkpixbuf2

  • gnutls

  • graphite2

  • gtk2

  • harfbuzz

  • jasper

  • jbigkit

  • jpeg

  • libasyncns

  • libaudiofile

  • libelf

  • libgcrypt

  • libgfortran

  • libgpg-error

  • libmng

  • libogg

  • libpciaccess

  • libsndfile

  • libsoup

  • libssh2

  • libtasn1

  • libthai

  • libtheora

  • libv4l

  • libvorbis

  • libxml2

  • mikmod

  • naslibs

  • ncurses-base

  • nspr

  • nss

  • openal

  • openal-soft

  • openldap

  • openmotif

  • openssl

  • pango

  • pixman

  • png

  • pulseaudio-libs

  • qt

  • qt-x11

  • qtwebkit

  • scimlibs

  • sdl12

  • sdlimage

  • sdlmixer

  • sqlite3

  • tcl85

  • tcp_wrappers-libs

  • tiff

  • tk85

  • ucl

  • xorglibs

17.49. localbase

Argumentos possíveis: (none), ldflags

Garante que as bibliotecas de dependências em LOCALBASE sejam usadas ​​em vez das do sistema base. Especifique ldflags para adicionar -L${LOCALBASE}/lib para a variável LDFLAGS ao invés de LIBS . Ports que dependem de bibliotecas que também estão presentes no sistema base devem usar isso. Também é usado internamente por algumas outras variáveis USES .

17.50. lua

Argumentos possíveis: (none), XY , XY + , - XY , XY - ZA , module , flavors , build , run , env

Adiciona uma dependência de Lua. Por padrão, esta é uma dependência de biblioteca, a menos que seja invalidado por uma opção build ou run . A opção env evita a adição de qualquer dependência, enquanto ainda define todas as variáveis usuais.

A versão padrão é definida pelo mecanismo usual DEFAULT_VERSIONS , a menos que uma versão ou intervalo de versões seja especificado como um argumento, por exemplo, 51 or 51-53 .

Os aplicativos que usam Lua são normalmente compilados para apenas uma única versão do Lua. No entanto, os módulos de biblioteca destinados a serem carregados pelo código Lua devem usar a opção module para compilar com vários flavors.

Para maiores informações, veja Usando Lua .

17.51. lxqt

Argumentos possíveis: (none)

Manipular dependências para o LXQt Desktop Environment. Use a variável USE_LXQT para selecionar os componentes necessários para o port. Veja Usando o LXQt para maiores informações.

17.52. makeinfo

Argumentos possíveis: (none)

Adiciona uma dependência de build-time em makeinfo se o mesmo não estiver presente no sistema base.

17.53. makeself

Argumentos possíveis: (none)

Indica que os arquivos de distribuição são archives makeself e define as dependências apropriadas.

17.54. mate

Argumentos possíveis: (none)

Fornece uma maneira fácil para depender de componentes do MATE. Os componentes devem ser listados em USE_MATE . Os componentes disponíveis são:

  • autogen

  • caja

  • common

  • controlcenter

  • desktop

  • dialogs

  • docutils

  • icontheme

  • intlhack

  • intltool

  • libmatekbd

  • libmateweather

  • marco

  • menus

  • notificationdaemon

  • panel

  • pluma

  • polkit

  • session

  • settingsdaemon

A dependência padrão é em built-time e run-time, pode ser alterada com :build ou :run . Por exemplo: 

USES=		mate
USE_MATE=	menus:build intlhack

17.55. meson

Argumentos possíveis: (none)

Fornece suporte para projetos baseados no Meson. Para maiores informações, consulte Usando meson .

17.56. metaport

Argumentos possíveis: (none)

Define as seguintes variáveis ​​para facilitar a criação de um metaport: MASTER_SITES , DISTFILES , EXTRACT_ONLY , NO_BUILD , NO_INSTALL , NO_MTREE , NO_ARCH .

17.57. mysql

Argumentos possíveis: (none), version , client (padrão), server , embedded

Fornece suporte para o MySQL. Se nenhuma versão for informada, tenta encontrar a versão atual instalada. Fall back para a versão padrão, MySQL-5.6. As possíveis versões são 55 , 55m , 55p , 56 , 56p , 56w , 57 , 57p , 80 , 100m , 101m e 102m . Os sufixos m e p são para MariaDB e Percona, variantes do MySQL. server e embbeded adicionam uma dependência de build- e run-time do servidor MySQL. Ao usar server ou embbeded , é adicionado client para também adicionar uma dependência no arquivo libmysqlclient.so . Um port pode definir IGNORE_WITH_MYSQL se algumas versões não forem suportadas.

O framework define a variável MYSQL_VER para a versão detectada do MySQL.

17.58. mono

Argumentos possíveis: (none), nuget

Adiciona uma dependência no framework Mono (atualmente apenas C#) definindo as dependências apropriadas.

Especifique nuget quando o port usa pacotes nuget. NUGET_DEPENDS precisa ser definido com os nomes e versões dos pacotes nuget no formato name = version . Uma pacote de origem opcional pode ser adicionado usando name=version:origin .

O target auxiliar, buildnuget , exibirá o conteúdo da variável NUGET_DEPENDS com base no arquivo packages.config fornecido.

17.59. motif

Argumentos possíveis: (none)

Utiliza x11-toolkits/open-motif como uma dependência de biblioteca. Os usuários finais podem definir WANT_LESSTIF para a dependência estar em x11-toolkits/lesstif ao invés de x11-toolkits/open-motif .

17.60. ncurses

Argumentos possíveis: (none), base , port

Utiliza ncurses, e faz com que algumas variáveis ​​úteis sejam definidas.

17.61. ninja

Argumentos possíveis: (none)

Utiliza ninja para compilar o port.

17.62. objc

Argumentos possíveis: (none)

Adiciona dependências de objetive C (compilador, biblioteca de runtime) se o sistema base não suportar isto.

17.63. openal

Argumentos possíveis: al , soft (padrão), yes , alut

Utiliza OpenAL. O backend pode ser especificado, com a implementação do software como padrão. O usuário pode especificar um backend preferido com WANT_OPENAL . Os valores válidos para este manipulador são soft (padrão) e si .

17.64. pathfix

Argumentos possíveis: (none)

Procura pelos arquivos Makefile.in e configure na variável PATHFIX_WRKSRC (padrão é WRKSRC ) e corrige os caminhos comuns para garantir que eles respeitem a hierarquia do FreeBSD. Por exemplo, ele corrige o diretório de instalação dos arquivos .pc do pkgconfig para ${PREFIX}/libdata/pkgconfig . Se o port usa USES=autoreconf , Makefile.am será adicionado automaticamente a PATHFIX_MAKEFILEIN .

Se o port tem definido USES=cmake ele vai procurar pelo arquivo CMakeLists.txt dentro da variável PATHFIX_WRKSRC . Se necessário, esse nome de arquivo padrão pode ser alterado com PATHFIX_CMAKELISTSTXT .

17.65. pear

Argumentos possíveis: env

Adiciona uma dependência do devel/pear . Ele irá configurar o comportamento padrão do software usando o Repositório de Extensão e Aplicativos do PHP. O uso do argumento env apenas configura as variáveis de ambiente PEAR. Veja Módulos PEAR para maiores informações.

17.66. perl5

Argumentos possíveis: (none)

Depende do Perl. A configuração é feita usando a variável USE_PERL5 .

USE_PERL5 pode conter as fases que precisam usar Perl, pode ser extract , patch , build , run ou test .

USE_PERL5 também pode conter configure , modbuild ou modbuildtiny quando Makefile.PL , Build.PL ou Módulo::Build::Tiny’s, flavor de Build.PL é necessário.

O padrão de USE_PERL5 é build run . Ao usar configure , modbuild ou modbuildtiny , uso de build e run são implícitos.

Veja Usando Perl para maiores informações.

17.67. pgsql

Argumentos possíveis: (none), X.Y , X.Y + , X.Y - , X.Y - Z.A

Fornece suporte para o PostgreSQL. O mantenedor do port pode definir a versão requisitada. Podem ser especificadas versões mínima e máxima ou um intervalo; por exemplo, 9.0- , 8.4+ , 8.4-9.2.

Por padrão, a dependência adicionada será o cliente, mas se o port exigir componentes adicionais, isso poderá ser feito usando WANT_PGSQL= component[:target] ; por exemplo, WANT_PGSQL=server:configure pltcl plperl . Os componentes disponíveis são:

  • client

  • contrib

  • docs

  • pgtcl

  • plperl

  • plpython

  • pltcl

  • server

17.68. php

Argumentos possíveis: (none), phpize , ext , zend , build , cli , cgi , mod , web , embed , pecl , flavors , noflavors

Fornece suporte para o PHP. Adiciona uma dependência de run-time na versão padrão do PHP, lang/php56 .

phpize

Utilizado para compilar uma extensão do PHP. Habilita flavors.

ext

Usado para compilar, instalar e registrar uma extensão do PHP. Habilita flavors.

zend

Usado para criar, instalar e registrar uma extensão do Zend. Habilita flavors.

build

Define PHP também como uma dependência de build-time.

cli

Precisa da versão CLI do PHP.

cgi

Precisa da versão CGI do PHP.

mod

Precisa do módulo Apache para o PHP.

web

Precisa do módulo Apache ou a versão CGI do PHP.

embed

Precisa da versão da biblioteca embarcada do PHP.

pecl

Fornece padrões para baixar extensões PHP do repositório PECL. Habilita flavors.

flavors

Habilita a geração de PHP flavors automático. Flavors serão gerados para todas as versões do PHP, exceto as presentes na variável IGNORE_WITH_PHP .

noflavors

Desativa a geração automática de flavors do PHP. Deve apenas ser usado com extensões fornecidas pelo próprio PHP.

Variáveis ​​são usadas para especificar quais módulos PHP são necessários, bem como qual versão do PHP são suportadas.

USE_PHP

A lista das extensões PHP requisitadas em run-time. Adicione :build ao nome da extensão para adicionar uma dependência em build-time. Exemplo: pcre xml:build gettext

IGNORE_WITH_PHP

O port não funciona com a versão do PHP fornecida. Para possíveis valores, observe o conteúdo da variável _ALL_PHP_VERSIONS no arquivo Mk/Uses/php.mk .

Ao compilar uma extensão do PHP ou Zend com :ext ou :zend , estas variáveis ​​podem ser definidas:

PHP_MODNAME

O nome da extensão do PHP ou Zend. O valor padrão é ${PORTNAME} .

PHP_HEADER_DIRS

Uma lista de subdiretórios dos quais instalar arquivos header. O framework sempre irá instalar os arquivos header que estão presentes no mesmo diretório que a extensão.

PHP_MOD_PRIO

A prioridade na qual carregar a extensão. É um número entre 00 e 99 .

Para extensões que não dependem de nenhuma extensão, a prioridade é definida automaticamente como 20 , para extensões que dependem de outra extensão, a prioridade é definida automaticamente como 30 . Algumas extensões podem precisar ser carregadas antes de todas as outras extensões, por exemplo www/php56-opcache . Algumas podem precisar ser carregadas após uma extensão com prioridade de 30 . Nesse caso, adicione PHP_MOD_PRIO= XX no Makefile do port. Por exemplo: 

USES=		php:ext
USE_PHP=	wddx
PHP_MOD_PRIO=	40

Estas variáveis ​​estão disponíveis para uso em PKGNAMEPREFIX ou PKGNAMESUFFIX :

PHP_PKGNAMEPREFIX

Contém php XY - onde XY é a versão do PHP atual. Use com módulos e extensões PHP.

PHP_PKGNAMESUFFIX

Contém -php XY onde XY é a versão do PHP atual do flavor. Use com aplicativos PHP.

PECL_PKGNAMEPREFIX

Contém php XY -pecl onde XY é a versão atual do PHP do flavor. Usar com módulos PECL.

Com flavors, todas as extensões PHP, extensões PECL, módulos PEAR devem ter um nome de pacote diferente, então todos devem usar uma dessas três variáveis ​​em suas variáveis PKGNAMEPREFIX ou PKGNAMESUFFIX .

17.69. pkgconfig

Argumentos possíveis: (none), build (padrão), run , both

Utiliza devel/pkgconf . Sem argumentos ou com o argumento build , implica em pkg-config como uma dependência de build-time. run implica em uma dependência em run-time e both implica em dependências de run-time e build-time.

17.70. pure

Argumentos possíveis: (none), ffi

Utiliza lang/pure . Usado largamente para build relacionado com ports pure. Com o argumento ffi , isso implica em devel/pure-ffi como uma dependência em run-time.

17.71. pyqt

Argumentos possíveis: (none), 4 , 5

Utiliza PyQt. Se o port é parte do próprio PyQT, defina PYQT_DIST . Use a variável USE_PYQT para selecionar os componentes que o port precisa. Os componentes disponíveis são:

  • core

  • dbus

  • dbussupport

  • demo

  • designer

  • designerplugin

  • doc

  • gui

  • multimedia

  • network

  • opengl

  • qscintilla2

  • sip

  • sql

  • svg

  • test

  • webkit

  • xml

  • xmlpatterns

Estes componentes só estão disponíveis com PyQT4:

  • assistant

  • declarative

  • help

  • phonon

  • script

  • scripttools

Estes componentes só estão disponíveis com PyQT5:

  • multimediawidgets

  • printsupport

  • qml

  • serialport

  • webkitwidgets

  • widgets

A dependência padrão para cada componente são build e run-time, para selecionar apenas build ou run, adicione _build ou _run para o nome do componente. Por exemplo: 

USES=		pyqt
USE_PYQT=	core doc_build designer_run

17.72. python

Argumentos possíveis: (none), XY , X.Y+ , -XY , XY-ZA , patch , build , run , test

Utiliza Python. Uma versão suportada ou um intervalo de versões podem ser especificados. Se o Python for necessário apenas no momento de build, run-time ou para os testes, ele pode ser definido como uma dependência de build, run ou teste com build , run ou test . Se o Python também for necessário durante a fase de patch, use patch . Veja Usando Python para maiores informações.

PYTHON_NO_DEPENDS=yes pode ser usado quando as variáveis ​​exportadas pelo framework serem necessárias, mas uma dependência de Python não. Pode acontecer quando usado com USES=shebangfix , e o objetivo é apenas consertar os shebangs, mas não adicionar uma dependência do Python.

17.73. qmail

Argumentos possíveis: (none), build , run , both , vars

Utiliza mail/qmail . Com o argumento build , implica no qmail como uma dependência de build-time. run implica em uma dependência de run-time. Usando nenhum argumento ou o argumento both implica em dependências de run-time e build-time. vars só ira definir variáveis ​​QMAIL para o port usar.

17.74. qmake

Argumentos possíveis: (none), norecursive , outsource , no_env , no_configure

Utiliza QMake para configuração. Para mais informações, veja Usando qmake .

17.75. qt

Argumentos possíveis: 5 , no_env

Adiciona dependência de componentes Qt. no_env é passado diretamente para USES= qmake . Veja Usando o Qt para maiores informações.

17.76. qt-dist

Argumentos possíveis: (none) ou 5 e (none) ou um de 3d , activeqt , androidextras , base , canvas3d , charts , connectivity , datavis3d , declarative , doc , gamepad , graphicaleffects , imageformats , location , macextras , multimedia , networkauth , purchasing , quickcontrols2 , quickcontrols , remoteobjects , script , scxml , sensors , serialbus , serialport , speech , svg , tools , translations , virtualkeyboard , wayland , webchannel , webengine , websockets , webview , winextras , x11extras , xmlpatterns

Fornece suporte para a compilação de componentes Qt 5. Ele cuida da definição do ambiente de configuração apropriado para o port compilar.

Exemplo 6. Compilando Componentes do Qt 5

O port é o componente networkauth do Qt 5, que faz parte do arquivo de distribuição networkauth . 

PORTNAME=	networkauth
DISTVERSION=	${QT5_VERSION}

USES=		qt-dist:5

Se PORTNAME não corresponder ao nome do componente, ele poderá ser passado como argumento em qt-dist .

Exemplo 7. Compilando Componentes do Qt 5 com Nomes Diferentes

O port é o componente gui do Qt 5, que faz parte do arquivo de distribuição base . 

PORTNAME=	gui
DISTVERSION=	${QT5_VERSION}

USES=		qt-dist:5,base

17.77. readline

Argumentos possíveis: (none), port

Usa readline como uma dependência de biblioteca e define CPPFLAGS e LDFLAGS como necessários. Se o argumento port é usado ou se readline não estiver presente no sistema base, adiciona uma dependência em devel/readline

17.78. samba

Possíveis argumentos: build , env , lib , run

Manipula dependências do Samba. env não irá adicionar qualquer dependência e apenas irá configurar as variáveis. build e run irão adicionar dependências de run-time e build-time de smbd . lib irá adicionar uma dependência em libsmbclient.so . As variáveis ​​que são exportadas são:

SAMBAPORT

A origem do port padrão Samba.

SAMBAINCLUDES

A localização dos arquivos header do Samba.

SAMBALIBS

O diretório onde as bibliotecas compartilhadas do Samba estão disponíveis.

17.79. scons

Argumentos possíveis: (none)

Fornece suporte para o uso do devel/scons . Veja Usando scons para maiores informações.

17.80. shared-mime-info

Argumentos possíveis: (none)

Utiliza update-mime-database a partir de misc/shared-mime-info . Este uses irão adicionar automaticamente uma etapa de post-install de tal forma que o próprio port ainda possa especificar sua própria etapa de post-install, se necessário. Também adiciona uma entrada @shared-mime-info para o plist.

17.81. shebangfix

Argumentos possíveis: (none)

Muitos softwares usam locais incorretos para interpretadores de scripts, principalmente /usr/bin/perl e /bin/bash . A macro shebangfix corrige linhas shebang em scripts listados em SHEBANG_REGEX , SHEBANG_GLOB ou SHEBANG_FILES .

SHEBANG_REGEX

Contém uma expressão regular estendida e é usado com o argumento -iregex do find(1) . Veja USES=shebangfix com a variável SHEBANG_REGEX .

SHEBANG_GLOB

Contém uma lista de padrões usados com o argumento -name do find(1) . Veja USES=shebangfix com a variável SHEBANG_GLOB .

SHEBANG_FILES

Contém uma lista de arquivos ou globs sh(1) . A macro shebangfix é executada a partir de ${WRKSRC} , assim SHEBANG_FILES pode conter caminhos relativos a ${WRKSRC} . Ele também pode lidar com caminhos absolutos se arquivos fora de ${WRKSRC} requisitarem uma correção. Veja USES=shebangfix com a variável SHEBANG_FILES .

Atualmente Bash, Java, Ksh, Lua, Perl, PHP, Python, Rubi, Tcl e Tk são suportados por padrão.

Aqui estão três variáveis de configuração:

SHEBANG_LANG

A lista de interpretadores suportados.

interp_CMD

O caminho para o interpretador de comandos no FreeBSD. O valor padrão é ${LOCALBASE}/bin/ interp .

interp_OLD_CMD

A lista de invocações erradas de interpretadores. Estes são tipicamente caminhos obsoletos, ou caminhos usados ​​em outros sistemas operacionais que estão incorretos no FreeBSD. Eles serão substituídos pelo caminho correto na variável interp__CMD .

Estes vão sempre ser parte da variável interp_OLD_CMD:"/usr/bin/envinterp" /bin/interp /usr/bin/interp /usr/local/bin/interp .

A variável interp_OLD_CMD contém vários valores. Qualquer entrada com espaços deve estar entre aspas. Veja Especificando todos os Caminhos ao Adicionar um Interpretador para USES=shebangfix .

A correção de shebangs é feita durante a fase patch . Se os scripts forem criados com shebangs incorretos durante a fase build , o processo de build (por exemplo, o script configure , ou o Makefiles ) deve ser corrigido ou ter o caminho certo (por exemplo, com CONFIGURE_ENV , CONFIGURE_ARGS , MAKE_ENV ou MAKE_ARGS ) para gerar as shebangs certas.

Os caminhos corretos para os interpretadores suportados estão disponíveis em interp_CMD .

Quando usado com USES=python , e o objetivo é apenas consertar os shebangs, mas a dependência de Python em si não é desejada, use a variável PYTHON_NO_DEPENDS=yes .

Exemplo 8. Adicionando outro interpretadoror para USES=shebangfix

Para adicionar outro interpretador, defina a variável SHEBANG_LANG . Por exemplo: 

SHEBANG_LANG=	lua
Exemplo 9. Especificando todos os Caminhos ao Adicionar um Interpretador para USES=shebangfix

Se isto não estiver definido ainda, e não tiver valores padrão para interp_OLD_CMD e interp_CMD a entrada Ksh poderia ser definida como: 

SHEBANG_LANG=	ksh
ksh_OLD_CMD=	"/usr/bin/env ksh" /bin/ksh /usr/bin/ksh
ksh_CMD=	${LOCALBASE}/bin/ksh
Exemplo 10. Adicionando uma Localização Estranha para um Interpretador

Alguns softwares usam localizações estranhas para um interpretador. Por exemplo, um aplicativo pode esperar que Python esteja localizado em /opt/bin/python2.7 . O caminho estranho a ser substituído pode ser declarado no Makefile do port: 

python_OLD_CMD=	/opt/bin/python2.7
Exemplo 11. USES=shebangfix com a variável SHEBANG_REGEX

Para corrigir todos os arquivos em ${WRKSRC}/scripts finalizados com .pl , .sh ou .cgi faça assim: 

USES=	shebangfix
SHEBANG_REGEX=	./scripts/.*\.(sh|pl|cgi)

SHEBANG_REGEX é usada executando find -E , que usa expressões regulares modernas, também conhecidas como expressões regulares estendidas. Veja re_format(7) para maiores informações.

Exemplo 12. USES=shebangfix com a variável SHEBANG_GLOB

Para corrigir todos os arquivos em ${WRKSRC} finalizados com .pl ou .sh , faça assim: 

USES=	shebangfix
SHEBANG_GLOB=	*.sh *.pl
Exemplo 13. USES=shebangfix com a variável SHEBANG_FILES

Para corrigir os arquivos script/foobar.pl e script/*.sh dentro de ${WRKSRC} , faça assim: 

USES=	shebangfix
SHEBANG_FILES=	scripts/foobar.pl scripts/*.sh

17.82. sqlite

Argumentos possíveis: (none), 2 , 3

Adiciona uma dependência SQLite. A versão padrão usada é 3, mas usar a versão 2 também é possível usando o modificador :2 .

17.83. ssl

Argumentos possíveis: (none), build , run

Fornece suporte para OpenSSL. Uma dependência apenas de compilação ou run-time pode ser especificada usando build ou run . Estas variáveis estão disponíveis para uso do port, elas também são adicionadas para a variável MAKE_ENV :

OPENSSLBASE

Caminho para a base de instalação do OpenSSL.

OPENSSLDIR

Caminho para arquivos de configuração do OpenSSL.

OPENSSLLIB

Caminho para as bibliotecas do OpenSSL.

OPENSSLINC

Caminho para os includes do OpenSSL.

OPENSSLRPATH

Se definido, o caminho que o vinculador precisa usar para localizar as bibliotecas do OpenSSL.

Se um port não for compilado com um flavor OpenSSL, defina a variável BROKEN_SSL , e possivelmente a variável BROKEN_SSL_REASON_flavor : 

BROKEN_SSL=	libressl
BROKEN_SSL_REASON_libressl=	needs features only available in OpenSSL

17.84. tar

Argumentos possíveis: (none), Z , bz2 , bzip2 , lzma , tbz , tbz2 , tgz , txz , xz

Define a variável EXTRACT_SUFX para .tar , .tar.Z , .tar.bz2 , .tar.bz2 , .tar.lzma , .tbz , .tbz2 , .tgz , .txz ou .tar.xz respectivamente.

17.85. tcl

Argumentos possíveis: version , wrapper , build , run , tea

Adiciona uma dependência para o Tcl. Uma versão específica pode ser requisitada usando version . A versão pode estar vazia, um ou mais números exatos de versão (atualmente 84 , 85 ou 86 ), ou um número mínimo de versão (atualmente 84+ , 85+ ou 86+ ). Para solicitar apenas um wrapper sem uma versão especifica, use wrapper . Uma dependência somente de compilação ou run-time pode ser especificada usando build ou run . Para compilar o port usando Tcl Extension Architecture, use o tea . Depois de incluir bsd.port.pre.mk o port pode inspecionar os resultados usando estas variáveis:

  • TCL_VER : seleciona a versão major.minor do Tcl

  • TCLSH : caminho completo do interpretador do Tcl

  • TCL_LIBDIR : caminho das bibliotecas do Tcl

  • TCL_INCLUDEDIR : caminho dos arquivos de cabeçalho C do Tcl

  • TK_VER : versão major.minor do Tk que foi escolhida

  • WISH : caminho completo do interpretador do Tk

  • TK_LIBDIR : caminho das bibliotecas do Tk

  • TK_INCLUDEDIR : caminho dos arquivos de cabeçalho C do Tk

17.86. terminfo

Argumentos possíveis: (none)

Adiciona @terminfo ao arquivo plist . Use quando o port instalar arquivos *.terminfo em ${PREFIX}/shared/misc .

17.87. tk

Os mesmos argumentos para tcl

Um pequeno wrapper ao usar os dois Tcl e Tk. As mesmas variáveis são retornadas assim como quando estiver usando Tcl.

17.88. uidfix

Argumentos possíveis: (none)

Altera algum comportamento padrão (principalmente de variáveis) do sistema de compilação para permitir instalar este port como um usuário normal. Tente isso no port antes de usar USES=fakeroot ou de aplicar algum patch.

17.89. uniquefiles

Argumentos possíveis: (none), dirs

Torna arquivos ou diretórios 'exclusivos', adicionando um prefixo ou sufixo. Se o argumento dirs é usado, o port precisa de um prefixo (e apenas um prefixo) baseado em UNIQUE_PREFIX para diretórios padrão DOCSDIR , EXEMPLESDIR , DATADIR , WWWDIR , ETCDIR . Estas variáveis estão disponíveis para os ports:

  • UNIQUE_PREFIX : O prefixo a ser usado para diretórios e arquivos. Padrão: ${PKGNAMEPREFIX} .

  • UNIQUE_PREFIX_FILES : Uma lista de arquivos que precisam ser prefixados. Padrão: vazio.

  • UNIQUE_SUFFIX : O sufixo para ser usado por arquivos. Padrão: ${PKGNAMESUFFIX} .

  • UNIQUE_SUFFIX_FILES : Uma lista de arquivos que precisam estar com um sufixo. Padrão: vazio.

17.90. varnish

Argumentos possíveis: 4 , 6

Manipula dependências do Varnish Cache. 4 irá adicionar uma dependência do www/varnish4 . 6 irá adicionar uma dependência do www/varnish6 .

17.91. webplugin

Argumentos possíveis: (none), ARGS

Cria e remove automaticamente links simbólicos para cada aplicação que suporta o framework do webplugin. ARGS pode ser um dos:

  • gecko : suporte a plug-ins baseados no Gecko

  • native : suporte a plug-ins para o Gecko, Opera e WebKit-GTK

  • linux : suporte a plug-ins do Linux

  • all (padrão, implícito): suporta todos os tipos de plug-ins

  • (entradas individuais): suporta apenas os navegadores listados

Essas variáveis podem ser ajustadas:

  • WEBPLUGIN_FILES : Sem padrão, deve ser definido manualmente. Os arquivos de plug-in para instalar.

  • WEBPLUGIN_DIR : O diretório para instalar os arquivos de plug-in, padrão PREFIX/lib/browser_plugins/WEBPLUGIN_NAME . Defina isso se o port instalar arquivos de plug-in fora do diretório padrão para previnir links simbólicos quebrados.

  • WEBPLUGIN_NAME : O diretório final para instalar os arquivos de plug-in, padrão PKGBASE .

17.92. xfce

Argumentos possíveis: (none), gtk2

Fornece suporte para ports relacionados ao Xfce. Veja Usando o Xfce para detalhes.

O argumento gtk2 especifica que o port requer suporte a GTK2. Ele adiciona recursos adicionais fornecidos por alguns componentes principais, por exemplo, x11/libxfce4menu e x11-wm/xfce4-panel .

17.93. xorg

Argumentos possíveis: (none)

Fornece uma maneira fácil para depender dos componentes X.org. Os componentes devem ser listados na variável USE_XORG . Os componentes disponíveis são:

Tabela 1. Componentes Disponíveis do X.Org
Nome Descrição

dmx

Biblioteca de extensão DMX

fontenc

Biblioteca fontenc

fontutil

Crie um índice de arquivos de fontes X em um diretório

ice

Biblioteca Inter Client Exchange para X11

libfs

Biblioteca FS

pciaccess

Biblioteca Genérica de acesso ao PCI

pixman

Biblioteca de manipulação de pixels de baixo nível

sm

Biblioteca de Gerenciamento de Sessão para X11

x11

Biblioteca X11

xau

Biblioteca do Protocolo de Autenticação para o X11

xaw

Biblioteca de Widgets do X Athena

xaw6

Biblioteca de Widgets do X Athena

xaw7

Biblioteca de Widgets do X Athena

xbitmaps

Arquivos bitmaps do X.Org

xcb

Biblioteca do protocolo X C-language Binding (XCB)

xcomposite

Biblioteca de extensão X Composite

xcursor

Biblioteca de carregamento do cursor X no lado do cliente

xdamage

Biblioteca de extensão X Damage

xdmcp

Biblioteca do Protocolo de Controle do X Display Manager

xext

Biblioteca de Extensão X11

xfixes

Biblioteca de extensão X Fixes

xfont

Biblioteca de fontes do X

xfont2

Biblioteca de fontes do X

xft

API de fontes do lado do cliente para aplicativos X

xi

Biblioteca de extensão X Input

xinerama

Biblioteca X11 Xinerama

xkbfile

Biblioteca XKB

xmu

Biblioteca de Utilitários Diversos do X

xmuu

Biblioteca de Utilitários Diversos do X

xorg-macros

Macros aclocal de desenvolvimento X.Org

xorg-server

Servidor X do X.Org e programas relacionados

xorgproto

xorg protocol headers

xpm

Biblioteca Pixmap do X

xpresent

Biblioteca de Extensão X Present

xrandr

Biblioteca de extensão X Resize e Rotate

xrender

Biblioteca de extensão X Render

xres

Biblioteca de uso X Resource

xscrnsaver

Biblioteca XScrnSaver

xshmfence

Memória compartilhada 'SyncFence' primitiva de sincronização

xt

Biblioteca X Toolkit

xtrans

Código de rede abstrato para X

xtst

Extensão X Test

xv

Biblioteca de Extensão X Video

xvmc

Biblioteca X Video Extension Motion Compensation

xxf86dga

X DGA Extension

xxf86vm

Extensão X Vidmode

17.94. xorg-cat

Argumentos possíveis: app , data , doc , driver , font , lib , proto , util , xserver e (none) ou um de autotools (default), meson

Forneça suporte para compilação de componentes Xorg. Ele cuida da definição de dependências comuns e de um ambiente de configuração apropriado necessário. Isso é destinado apenas aos componentes do Xorg.

A categoria deve corresponder às categorias upstream.

O segundo argumento é o sistema de compilação a ser usado. autotools é o padrão, mas meson também é suportado.

17.95. zip

Argumentos possíveis: (none), infozip

Indica que os arquivos de distribuição usam o algoritmo de compactação ZIP. Para arquivos que usam o algoritmo InfoZip, o argumento infozip deve ser passado para definir as dependências apropriadas.

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

Início