USES= bison perl
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 (,).
USES= tar:xz
USES= drupal:7,theme
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_NAMEO nome da biblioteca Berkeley DB. Por exemplo, ao usar databases/db5, contém
db-5.3.BDB_LIB_CXX_NAMEO nome da biblioteca Berkeley DBC++. Por exemplo, ao usar databases/db5, contém
db_cxx-5.3.BDB_INCLUDE_DIRA localização do diretório incluso Berkeley DB. Por exemplo, ao usar databases/db5, ele irá conter
${LOCALBASE}/include/db5.BDB_LIB_DIRA localização do diretório da biblioteca Berkeley DB. Por exemplo, ao usar databases/db5, contém
${LOCALBASE}/lib.BDB_VERA versão detectada de Berkeley DB. Por exemplo, se estiver usando
USES=bdb:48+e Berkeley DB 5 estiver instalado, irá conter5.
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_CABALSe 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 comcabal.CABAL_FLAGSLista de flags a serem passadas para o
cabal-installdurante o estágio de configuração e compilação. As flags são passadas sem alterações (verbatim).EXECUTABLESLista de arquivos executáveis instalados pelo port. Valor padrão:
${PORTNAME}. Os itens desta lista são adicionados automaticamente ao pkg-plist.SKIP_CABAL_PLISTSe definido, não adicione itens
${EXECUTABLES}ao pkg-plist.opt_USE_CABALAdiciona itens ao
${USE_CABAL}, dependendo da opçãoopt.opt_EXECUTABLESAdiciona itens ao
${EXECUTABLES}, dependendo da opçãoopt.opt_CABAL_FLAGSSe a opção
optestiver ativada, acrescente o valor a${CABAL_FLAGS}. Caso contrário, anexe-valuepara desativar a flag.FOO_DATADIR_VARSPara 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 clangALT_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 clangCOMPILER_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:
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.
Adicione
cpena variávelUSESe compare o resultado demake -V CPE_STRcom o registro no dicionário CPE. Continue com um passo de cada vez atémake -V CPE_STRficar correto.Se o nome do produto (segundo campo, com o valor padrão para
PORTNAME) estiver incorreto, definaCPE_PRODUCT.Se o nome do fornecedor (primeiro campo, com o valor padrão para
CPE_PRODUCT) estiver incorreto, definaCPE_VENDOR.Se o campo de versão (terceiro campo, com o valor padrão para
PORTVERSION) estiver incorreto, definaCPE_VERSION.Se o campo de atualização (quarto campo, valor padrão vazio) estiver incorreto, defina
CPE_UPDATE.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.
Derive o máximo possível do nome CPE a partir de variáveis existentes, tal como as variáveis
PORTNAMEePORTVERSION. Use modificadores de variáveis para extrair as partes relevantes delas, em vez de colocar o nome direto no código.Sempre execute
make -V CPE_STRe verifique a saída antes de fazer o commit de qualquer coisa que mude oPORTNAMEouPORTVERSIONou qualquer outra variável que é usada para derivar a variávelCPE_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.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:
egladiciona uma dependência de biblioteca libEGL.so de graphics/libglvnd
gbmAdiciona uma dependência de biblioteca libgbm.so de graphics/mesa-libs
glAdiciona uma dependência de biblioteca libGL.so de graphics/libglvnd
glesv2Adiciona uma dependência de biblioteca libGLESv2.so de graphics/libglvnd
glewAdiciona uma dependência de biblioteca libGLEW.so de graphics/glew
gluAdiciona uma dependência de biblioteca libGLU.so de graphics/libGLU
glutAdiciona uma dependência de biblioteca libglut.so de graphics/freeglut
openglAdiciona 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:
atkatkmmcairocairommdconfesoundevolutiondataserver3gconf2gconfmm26gdkpixbufgdkpixbuf2glib12glib20glibmmgnomecontrolcenter3gnomedesktop3gnomedocutilsgnomemenus3gnomemimedatagnomeprefixgnomesharp20gnomevfs2gsoundgtk-update-icon-cachegtk12gtk20gtk30gtkhtml3gtkhtml4gtkmm20gtkmm24gtkmm30gtksharp20gtksourceviewgtksourceview2gtksourceview3gtksourceviewmm3gvfsintlhackintltoolintrospectionlibartlgpl2libbonobolibbonobouilibgda5libgda5-uilibgdamm5libglade2libgnomelibgnomecanvaslibgnomekbdlibgnomeprintlibgnomeprintuilibgnomeuilibgsflibgtkhtmllibgtksourceviewmmlibidllibrsvg2libsigc++12libsigc++20libwncklibwnck3libxml++26libxml2libxsltmetacitynautilus3orbit2pangopangommpangox-compatpy3gobject3pygnome2pygobjectpygobject3pygtk2pygtksourceviewreferencehackvtevte3
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_PKGNAMEO 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 eGH_SUBDIRouGL_SUBDIRestiverem presente, o valorGO_PKGNAMEserá inferido deles. Isso não é necessário quando compilado no modo de reconhecimento de módulos.GO_TARGETOs pacotes a serem compilados. O valor padrão é
${GO_PKGNAME}.GO_TARGETtambém pode ser uma tupla na formapackage:pathonde path pode ser um nome de arquivo simples ou um caminho completo começando com${PREFIX}.GO_TESTTARGETOs pacotes para testar. O valor padrão é
./…(o pacote atual e todos os subpacotes).CGO_CFLAGSValores adicionais da variável
CFLAGSa serem passados para o compilador C peloGo.CGO_LDFLAGSValores adicionais da variável
LDFLAGSa serem passados para o compilador C peloGo.GO_BUILDFLAGSArgumentos de compilação adicionais para passar para o
go build.GO_TESTFLAGSArgumentos de compilação adicionais para passar para o
go test.GO_PORTO port do compilador Go a ser utilizado. Por padrão é lang/go mas pode ser definido para lang/go-devel no
make.confpara 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:
GSSAPIBASEDIRGSSAPICPPFLAGSGSSAPIINCDIRGSSAPILDFLAGSGSSAPILIBDIRGSSAPILIBSGSSAPI_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.
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-gssapi17.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
kldemCATEGORIES.Define
SSP_UNSAFE.Defina
IGNOREse as fontes do kernel não forem encontradas emSRC_BASE.Define
KMODDIRpara /boot/modules por padrão, adiciona isso para a variávelPLIST_SUBeMAKE_ENV, e o cria após a instalação. Se a variávelKMODDIRestá 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ávelKERN_DEBUGDIRé copiada daDEBUGDIRe definido para /usr/lib/debug. O framework irá cuidar da criação e remoção de quaisquer diretórios necessários.
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:
allegroalsa-plugins-ossalsa-plugins-pulseaudioalsalibatkavahi-libsbasecairocups-libscurlcyrus-sasl2dbusglibdbuslibsdevtoolsdriexpatflacfontconfiggdkpixbuf2gnutlsgraphite2gtk2harfbuzzjasperjbigkitjpeglibasyncnslibaudiofilelibelflibgcryptlibgfortranlibgpg-errorlibmnglibogglibpciaccesslibsndfilelibsouplibssh2libtasn1libthailibtheoralibv4llibvorbislibxml2mikmodnaslibsncurses-basensprnssopenalopenal-softopenldapopenmotifopensslpangopixmanpngpulseaudio-libsqtqt-x11qtwebkitscimlibssdl12sdlimagesdlmixersqlite3tcl85tcp_wrappers-libstifftk85uclxorglibs
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:
autogencajacommoncontrolcenterdesktopdialogsdocutilsiconthemeintlhackintltoollibmatekbdlibmateweathermarcomenusnotificationdaemonpanelplumapolkitsessionsettingsdaemon
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.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:
clientcontribdocspgtclplperlplpythonpltclserver
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.
phpizeUtilizado para compilar uma extensão do PHP. Habilita flavors.
extUsado para compilar, instalar e registrar uma extensão do PHP. Habilita flavors.
zendUsado para criar, instalar e registrar uma extensão do Zend. Habilita flavors.
buildDefine PHP também como uma dependência de build-time.
cliPrecisa da versão CLI do PHP.
cgiPrecisa da versão CGI do PHP.
modPrecisa do módulo Apache para o PHP.
webPrecisa do módulo Apache ou a versão CGI do PHP.
embedPrecisa da versão da biblioteca embarcada do PHP.
peclFornece padrões para baixar extensões PHP do repositório PECL. Habilita flavors.
flavorsHabilita 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.noflavorsDesativa 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_PHPA lista das extensões PHP requisitadas em run-time. Adicione
:buildao nome da extensão para adicionar uma dependência em build-time. Exemplo:pcre xml:build gettext
IGNORE_WITH_PHPO port não funciona com a versão do PHP fornecida. Para possíveis valores, observe o conteúdo da variável
_ALL_PHP_VERSIONSno 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_MODNAMEO nome da extensão do PHP ou Zend. O valor padrão é
${PORTNAME}.PHP_HEADER_DIRSUma 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_PRIOA prioridade na qual carregar a extensão. É um número entre
00e99.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 como30. 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 de30. Nesse caso, adicionePHP_MOD_PRIO=XXno 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_PKGNAMEPREFIXContém
phpXY-onde XY é a versão do PHP atual. Use com módulos e extensões PHP.PHP_PKGNAMESUFFIXContém
-phpXYonde XY é a versão do PHP atual do flavor. Use com aplicativos PHP.PECL_PKGNAMEPREFIXContém
phpXY-peclonde 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 |
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:
coredbusdbussupportdemodesignerdesignerplugindocguimultimedianetworkopenglqscintilla2sipsqlsvgtestwebkitxmlxmlpatterns
Estes componentes só estão disponíveis com PyQT4:
assistantdeclarativehelpphononscriptscripttools
Estes componentes só estão disponíveis com PyQT5:
multimediawidgetsprintsupportqmlserialportwebkitwidgetswidgets
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.
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:5Se PORTNAME não corresponder ao nome do componente, ele poderá ser passado como argumento em qt-dist.
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,base17.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:
SAMBAPORTA origem do port padrão Samba.
SAMBAINCLUDESA localização dos arquivos header do Samba.
SAMBALIBSO 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_REGEXContém uma expressão regular estendida e é usado com o argumento
-iregexdo find(1). VejaUSES=shebangfixcom a variávelSHEBANG_REGEX.SHEBANG_GLOBContém uma lista de padrões usados com o argumento
-namedo find(1). VejaUSES=shebangfixcom a variávelSHEBANG_GLOB.SHEBANG_FILESContém uma lista de arquivos ou globs sh(1). A macro shebangfix é executada a partir de
${WRKSRC}, assimSHEBANG_FILESpode conter caminhos relativos a${WRKSRC}. Ele também pode lidar com caminhos absolutos se arquivos fora de${WRKSRC}requisitarem uma correção. VejaUSES=shebangfixcom a variávelSHEBANG_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_LANGA lista de interpretadores suportados.
interp_CMDO caminho para o interpretador de comandos no FreeBSD. O valor padrão é
${LOCALBASE}/bin/interp.interp_OLD_CMDA 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_CMDcontém vários valores. Qualquer entrada com espaços deve estar entre aspas. Veja Especificando todos os Caminhos ao Adicionar um Interpretador paraUSES=shebangfix.
A correção de shebangs é feita durante a fase Os caminhos corretos para os interpretadores suportados estão disponíveis em |
Quando usado com |
USES=shebangfixPara adicionar outro interpretador, defina a variável SHEBANG_LANG. Por exemplo:
SHEBANG_LANG= lua
USES=shebangfixSe 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/kshAlguns 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
USES=shebangfix com a variável SHEBANG_REGEXPara corrigir todos os arquivos em ${WRKSRC}/scripts finalizados com .pl, .sh ou .cgi faça assim:
USES= shebangfix SHEBANG_REGEX= ./scripts/.*\.(sh|pl|cgi)
|
USES=shebangfix com a variável SHEBANG_GLOBPara corrigir todos os arquivos em ${WRKSRC} finalizados com .pl ou .sh, faça assim:
USES= shebangfix SHEBANG_GLOB= *.sh *.pl
USES=shebangfix com a variável SHEBANG_FILESPara 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:
OPENSSLBASECaminho para a base de instalação do OpenSSL.
OPENSSLDIRCaminho para arquivos de configuração do OpenSSL.
OPENSSLLIBCaminho para as bibliotecas do OpenSSL.
OPENSSLINCCaminho para os includes do OpenSSL.
OPENSSLRPATHSe 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= 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 TclTCLSH: caminho completo do interpretador do TclTCL_LIBDIR: caminho das bibliotecas do TclTCL_INCLUDEDIR: caminho dos arquivos de cabeçalho C do TclTK_VER: versão major.minor do Tk que foi escolhidaWISH: caminho completo do interpretador do TkTK_LIBDIR: caminho das bibliotecas do TkTK_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 Geckonative: suporte a plug-ins para o Gecko, Opera e WebKit-GTKlinux: suporte a plug-ins do Linuxall(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ãoPKGBASE.
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:
| Nome | Descrição |
|---|---|
| Biblioteca de extensão DMX |
| Biblioteca fontenc |
| Crie um índice de arquivos de fontes X em um diretório |
| Biblioteca Inter Client Exchange para X11 |
| Biblioteca FS |
| Biblioteca Genérica de acesso ao PCI |
| Biblioteca de manipulação de pixels de baixo nível |
| Biblioteca de Gerenciamento de Sessão para X11 |
| Biblioteca X11 |
| Biblioteca do Protocolo de Autenticação para o X11 |
| Biblioteca de Widgets do X Athena |
| Biblioteca de Widgets do X Athena |
| Biblioteca de Widgets do X Athena |
| Arquivos bitmaps do X.Org |
| Biblioteca do protocolo X C-language Binding (XCB) |
| Biblioteca de extensão X Composite |
| Biblioteca de carregamento do cursor X no lado do cliente |
| Biblioteca de extensão X Damage |
| Biblioteca do Protocolo de Controle do X Display Manager |
| Biblioteca de Extensão X11 |
| Biblioteca de extensão X Fixes |
| Biblioteca de fontes do X |
| Biblioteca de fontes do X |
| API de fontes do lado do cliente para aplicativos X |
| Biblioteca de extensão X Input |
| Biblioteca X11 Xinerama |
| Biblioteca XKB |
| Biblioteca de Utilitários Diversos do X |
| Biblioteca de Utilitários Diversos do X |
| Macros aclocal de desenvolvimento X.Org |
| Servidor X do X.Org e programas relacionados |
| xorg protocol headers |
| Biblioteca Pixmap do X |
| Biblioteca de Extensão X Present |
| Biblioteca de extensão X Resize e Rotate |
| Biblioteca de extensão X Render |
| Biblioteca de uso X Resource |
| Biblioteca XScrnSaver |
| Memória compartilhada 'SyncFence' primitiva de sincronização |
| Biblioteca X Toolkit |
| Código de rede abstrato para X |
| Extensão X Test |
| Biblioteca de Extensão X Video |
| Biblioteca X Video Extension Motion Compensation |
| X DGA Extension |
| 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.
Última alteração em: 18 de fevereiro de 2025 por Fernando Apesteguía