Path: blob/main/documentation/content/pt-br/books/porters-handbook/uses/_index.adoc
18099 views
---
title: Capítulo 17. Using USES Macros
prev: books/porters-handbook/keeping-up
next: books/porters-handbook/versions
showBookMenu: true
weight: 17
params:
path: "/books/porters-handbook/uses/"
---
[[uses]]
= Usando Macros `USES`
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:sectnumoffset: 17
:partnums:
:source-highlighter: rouge
:experimental:
:c-plus-plus: c++
:images-path: books/porters-handbook/
ifdef::env-beastie[]
ifdef::backend-html5[]
:imagesdir: ../../../../images/{images-path}
endif::[]
ifndef::book[]
include::shared/authors.adoc[]
include::shared/mirrors.adoc[]
include::shared/releases.adoc[]
include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
toc::[]
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]
ifndef::env-beastie[]
toc::[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
[[uses-intro]]
== 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-intro-ex1]]
.Usando Vários Valores
[example]
====
[.programlisting]
....
USES= bison perl
....
====
[[uses-intro-ex2]]
.Adicionando um Argumento
[example]
====
[.programlisting]
....
USES= tar:xz
....
====
[[uses-intro-ex3]]
.Adicionando Vários Argumentos
[example]
====
[.programlisting]
....
USES= drupal:7,theme
....
====
[[uses-intro-ex4]]
.Entrelaçando Tudo Isso Junto
[example]
====
[.programlisting]
....
USES= pgsql:9.3+ cpe python:2.7,build
....
====
[[uses-7z]]
== `7z`
Argumentos possíveis: (none), `p7zip`, `partial`
Extrair usando man:7z[1] ao invés de man:bsdtar[1] e definir `EXTRACT_SUFX=.7z`. A opção `p7zip` força uma dependência do `7z` a partir de package: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 [.filename]#.7z#.
[[uses-ada]]
== `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.
[[uses-autoreconf]]
== `autoreconf`
Argumentos possíveis: (none), `build`
Execute `autoreconf`. Ele encapsula os comandos `aclocal`, `autoconf`, `autoheader`, `automake`, `autopoint` e `libtoolize`. Cada comando aplica-se a [.filename]#${AUTORECONF_WRKSRC} /configure.ac# ou seu nome antigo [.filename]#${AUTORECONF_WRKSRC}/configure.in#. E se [.filename]#configure.ac# define subdiretórios com seus próprios [.filename]#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 [.filename]#configure.ac#.
[[uses-blaslapack]]
== `blaslapack`
Argumentos possíveis: (none), `atlas`, `netlib`(padrão), `gotoblas`, `openblas`
Adiciona dependências das bibliotecas Blas / Lapack.
[[uses-bdb]]
== `bdb`
Argumentos possíveis: (none), `48`, `5`(padrão), `6`
Adiciona uma dependência à biblioteca Berkeley DB. O padrão utiliza package:databases/db5[]. Também pode depender de package:databases/db48[] ao usar o argumento `:48` ou package: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 package:databases/db5[], contém `db-5.3`.
`BDB_LIB_CXX_NAME`::
O nome da biblioteca Berkeley DBC++. Por exemplo, ao usar package:databases/db5[], contém `db_cxx-5.3`.
`BDB_INCLUDE_DIR`::
A localização do diretório incluso Berkeley DB. Por exemplo, ao usar package: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 package: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`.
[IMPORTANT]
====
package:databases/db48[] está obsoleto e não é suportado. Não deve ser usado por nenhum port.
====
[[uses-bison]]
== `bison`
Argumentos possíveis: (none), `build`, `run`, `both`
Utiliza package: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.
[[uses-cabal]]
== `cabal`
[IMPORTANT]
====
Não devem ser criados Ports de bibliotecas Haskell, veja crossref:special[haskell-libs,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 package: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 crossref:special[using-cabal,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.
[[uses-cargo]]
== `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 crossref:special[using-cargo,Compilando Aplicações Rust com `cargo`]..
[[uses-charsetfix]]
== `charsetfix`
Argumentos possíveis: (none)
Previne que o port instale arquivos [.filename]#charset.alias#. Estes arquivos devem ser instalados apenas pelo package:converters/libiconv[]. `CHARSETFIX_MAKEFILEIN` pode ser definido para um caminho relativo ao `WRKSRC` se [.filename]#charset.alias# não for instalado pelo [.filename]#${WRKSRC}/Makefile.in#.
[[uses-cmake]]
== `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 crossref:special[using-cmake,Usando o `cmake`].
[[uses-compiler]]
== `compiler`
Argumentos possíveis: (none), `env` (padrão, implícito) {c-plus-plus}17-lang, {c-plus-plus}14-lang, {c-plus-plus}11-lang, gcc-{c-plus-plus}11-lib, {c-plus-plus}11-lib, {c-plus-plus}0x, c11, openmp, nestedfct, features
Determina qual compilador usar com base em qualquer um desejo. Use {c-plus-plus}17-lang se o port precisar de um compilador compatível com {c-plus-plus}17, {c-plus-plus}14-lang se o port precisar de um compilador compatível com {c-plus-plus}14, {c-plus-plus}11-lang se o port precisar de um compilador compatível com {c-plus-plus}11, gcc-{c-plus-plus}11-lib se o port precisar do compilador {gcc-plus-plus} com uma biblioteca {c-plus-plus}11, ou {c-plus-plus}11-lib se o port precisar de uma biblioteca padrão {c-plus-plus}11-ready. Se o port precisar de um compilador que compreenda as funções {c-plus-plus}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 [.filename]#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++.
[[uses-cpe]]
== `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 http://scap.nist.gov/specifications/cpe/[especificações CPE] para mais detalhes. Para adicionar informações de CPE a um port, siga estas etapas:
[.procedure]
====
. Procure pelo registro oficial CPE para o produto de software, usando o http://web.nvd.nist.gov/view/cpe/search[mecanismo de pesquisa CPE] do NVD ou no http://static.nvd.nist.gov/feeds/xml/cpe/dictionary/official-cpe-dictionary_v2.3.xml[dicionário oficial CPE] (aviso, o arquivo XML é muito grande). _Nunca crie os dados da CPE._
. 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.
. Se o nome do produto (segundo campo, com o valor padrão para `PORTNAME`) estiver incorreto, defina `CPE_PRODUCT`.
. Se o nome do fornecedor (primeiro campo, com o valor padrão para `CPE_PRODUCT`) estiver incorreto, defina `CPE_VENDOR`.
. Se o campo de versão (terceiro campo, com o valor padrão para `PORTVERSION`) estiver incorreto, defina `CPE_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 [.filename]#Mk/Uses/cpe.mk# para detalhes adicionais, ou entre em contato com o Ports Security Team mailto:[email protected][[email protected]].
. 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.
. _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`.
====
[[uses-cran]]
== `cran`
Argumentos possíveis: (none), `auto-plist`, `compiles`
Utiliza a Comprehensive R Archive Network. Especifique `auto-plist` para gerar automaticamente o arquivo [.filename]#pkg-plist#. Especifique `compiles` se o port tiver código que precise ser compilado.
[[uses-desktop-file-utils]]
== `desktop-file-utils`
Argumentos possíveis: (none)
Utiliza update-desktop-database a partir de package:devel/desktop-file-utils[]. Uma etapa extra de post-install será executada sem interferir em nenhuma etapa de post-install que já esteja no [.filename]#Makefile# do port. Uma linha com <<plist-keywords-desktop-file-utils,`@desktop-file-utils`>> será adicionada ao plist.
[[uses-desthack]]
== `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.
[[uses-display]]
== `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.
[[uses-dos2unix]]
== `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 crossref:slow-porting[slow-patch-automatic-replacements,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}`.
[[uses-drupal]]
== `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`.
[[uses-fakeroot]]
== `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`.
[[uses-fam]]
== `fam`
Argumentos possíveis: (none), `fam`, `gamin`
Usa um File Alteration Monitor como uma dependência de biblioteca, package:devel/fam[] ou package:devel/gamin[]. Usuários finais podem definir WITH_FAM_SYSTEM para especificar sua preferência.
[[uses-firebird]]
== `firebird`
Argumentos possíveis: (none), `25`
Adiciona uma dependência da biblioteca client do banco de dados do Firebird.
[[uses-fonts]]
== `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 `<<plist-keywords-fc,@fc>> ${FONTSDIR}`, `<<plist-keywords-fcfontsdir,@fcfontsdir>> ${FONTSDIR}`, `<<plist-keywords-fontsdir,@fontsdir>> ${FONTSDIR}`, ou nenhuma entrada se o argumento for `none`. Valor padrão de `FONTSDIR` é [.filename]#${PREFIX}/shared/fonts/${FONTNAME}# e `FONTNAME` é `${PORTNAME}`. Adiciona `FONTSDIR` para `PLIST_SUB` e `SUB_LIST`
[[uses-fortran]]
== `fortran`
Argumentos possíveis: `gcc` (padrão)
Usa o compilador GNU Fortran.
[[uses-fuse]]
== `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.
[[uses-gem]]
== `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.
[[uses-gettext]]
== `gettext`
Argumentos possíveis: (none)
Descontinuado. Incluirá ambos <<uses-gettext-runtime,`gettext-runtime`>> e <<uses-gettext-tools,`gettext-tools`>>.
[[uses-gettext-runtime]]
== `gettext-runtime`
Argumentos possíveis: (none), `lib` (padrão),`build`, `run`
Utiliza package:devel/gettext-runtime[]. Por padrão, sem argumentos ou com o argumento `lib`, implica uma dependência da biblioteca [.filename]#libintl.so#. `build` e `run` implicam, respectivamente, uma dependência de [.filename]#gettext# em build-time e run-time.
[[uses-gettext-tools]]
== `gettext-tools`
Argumentos possíveis: (none), `build` (padrão),`run`
Utiliza package:devel/gettext-tools[]. Por padrão, sem argumento ou com o argumento `build`, uma dependência de [.filename]#msgfmt# em build-time é registrada. Com o argumento `run`, uma dependência em run-time é registrada.
[[uses-ghostscript]]
== `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.
[[uses-gl]]
== `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 [.filename]#libEGL.so# de package:graphics/libglvnd[]
`gbm`::
Adiciona uma dependência de biblioteca [.filename]#libgbm.so# de package:graphics/mesa-libs[]
`gl`::
Adiciona uma dependência de biblioteca [.filename]#libGL.so# de package:graphics/libglvnd[]
`glesv2`::
Adiciona uma dependência de biblioteca [.filename]#libGLESv2.so# de package:graphics/libglvnd[]
`glew`::
Adiciona uma dependência de biblioteca [.filename]#libGLEW.so# de package:graphics/glew[]
`glu`::
Adiciona uma dependência de biblioteca [.filename]#libGLU.so# de package:graphics/libGLU[]
`glut`::
Adiciona uma dependência de biblioteca [.filename]#libglut.so# de package:graphics/freeglut[]
`opengl`::
Adiciona uma dependência de biblioteca [.filename]#libOpenGL.so# de package:graphics/libglvnd[]
[[uses-gmake]]
== `gmake`
Argumentos possíveis: (none)
Utiliza package:devel/gmake[] como uma dependência em run-time e configura o ambiente para usar `gmake` como `make` padrão para a compilação.
[[uses-gnome]]
== `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:
[.programlisting]
....
USES= gnome
USE_GNOME= gnomemenus3:build intlhack
....
Veja crossref:special[using-gnome,Usando o GNOME] para maiores informações.
[[uses-go]]
== `go`
[IMPORTANT]
====
Não devem ser criados Ports de bibliotecas Go, veja crossref:special[go-libs,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 é package:lang/go[] mas pode ser definido para package:lang/go-devel[] no `make.conf` para testes de futuras versões Go.
+
[WARNING]
====
Esta variável não deve ser definida por ports individuais!
====
Ver crossref:special[using-go,Compilando Aplicações Go] para exemplos de uso.
[[uses-gperf]]
== `gperf`
Argumentos possíveis: (none)
Adiciona uma dependência package:devel/gperf[] em buildtime se `gperf` não estiver presente no sistema base.
[[uses-grantlee]]
== `grantlee`
Argumentos possíveis: `5`, `selfbuild`
Manipula a dependência em Grantlee. Especifique `5` para depender da versão baseada no Qt5, package:devel/grantlee5[]. `selfbuild` é usado internamente pelo package:devel/grantlee5[] para obter os números de suas versões.
[[uses-groff]]
== `groff`
Argumentos possíveis: `build`, `run`, `both`
Registra uma dependência de package:textproc/groff[] se não estiver presente no sistema base.
[[uses-gssapi]]
== `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 package:security/heimdal[] ou `mit` para usar package: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 package:security/krb5[] e package:security/heimdal[]. Por exemplo, use `bootstrap,mit`.
[[uses-gssapi-ex1]]
.Uso Típico
[example]
====
[.programlisting]
....
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
....
====
[[uses-horde]]
== `horde`
Argumentos possíveis: (none)
Adicionar dependências de builtime e runtime em package:devel/pear-channel-horde[]. Outras dependências Horde podem ser adicionadas com `USE_HORDE_BUILD` e `USE_HORDE_RUN`. Veja crossref:special[php-horde,Módulos Horde] para maiores informações.
[[uses-iconv]]
== `iconv`
Argumentos possíveis: (none), `lib`, `build`, `patch`, `translit`, `wchar_t`
Utilização de funções `iconv`, seja do port package: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 link:https://svnweb.freebsd.org/changeset/base/254273[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 crossref:special[using-iconv,Usando `iconv`].
[[uses-imake]]
== `imake`
Argumentos possíveis: (none), `env`, `notall`, `noman`
Adiciona package: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`.
[[uses-kde]]
== `kde`
Argumentos possíveis: `5`
Adiciona dependência de componentes KDE. Veja crossref:special[using-kde,Usando o KDE] para maiores informações.
[[uses-kmod]]
== `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 [.filename]#/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 [.filename]#/boot/kernel#, ela será reescrita para [.filename]#/boot/modules#. Isso evita quebrar pacotes ao atualizar o kernel devido ao [.filename]#/boot/kernel# ser renomeado para [.filename]#/boot/kernel.old# no processo.
* Manipula módulos cross-referencing do kernel acerca da instalação e desinstalação, usando <<plist-keywords-kld,`@kld`>>.
* Se o argumento `debug` é passado, o port pode instalar uma versão de debug do módulo no arquivo [.filename]#KERN_DEBUGDIR#/[.filename]#KMODDIR#. Por padrão, a variável `KERN_DEBUGDIR` é copiada da `DEBUGDIR` e definido para [.filename]#/usr/lib/debug#. O framework irá cuidar da criação e remoção de quaisquer diretórios necessários.
[[uses-lha]]
== `lha`
Argumentos possíveis: (none)
Define `EXTRACT_SUFX` para `.lzh`
[[uses-libarchive]]
== `libarchive`
Argumentos possíveis: (none)
Registra uma dependência de package:archivers/libarchive[]. Quaisquer ports dependendo de libarchive deve incluir `USES=libarchive`.
[[uses-libedit]]
== `libedit`
Argumentos possíveis: (none)
Registra uma dependência de package:devel/libedit[]. Quaisquer ports dependendo de libedit devem incluir `USES=libedit`.
[[uses-libtool]]
== `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 [.filename]#.la#. Alguns ports não vêm com sua própria cópia da libtool e precisam de uma dependência de package:devel/libtool[] em build time, use o argumento `:build` para adicionar essa dependência.
[[uses-linux]]
== `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`
[[uses-localbase]]
== `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`.
[[uses-lua]]
== `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 crossref:special[using-lua,Usando Lua].
[[uses-lxqt]]
== `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 crossref:special[using-lxqt,Usando o LXQt] para maiores informações.
[[uses-makeinfo]]
== `makeinfo`
Argumentos possíveis: (none)
Adiciona uma dependência de build-time em `makeinfo` se o mesmo não estiver presente no sistema base.
[[uses-makeself]]
== `makeself`
Argumentos possíveis: (none)
Indica que os arquivos de distribuição são archives makeself e define as dependências apropriadas.
[[uses-mate]]
== `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:
[.programlisting]
....
USES= mate
USE_MATE= menus:build intlhack
....
[[uses-meson]]
== `meson`
Argumentos possíveis: (none)
Fornece suporte para projetos baseados no Meson. Para maiores informações, consulte crossref:special[using-meson,Usando `meson`].
[[uses-metaport]]
== `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`.
[[uses-mysql]]
== `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 [.filename]#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.
[[uses-mono]]
== `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 [.filename]#packages.config# fornecido.
[[uses-motif]]
== `motif`
Argumentos possíveis: (none)
Utiliza package:x11-toolkits/open-motif[] como uma dependência de biblioteca. Os usuários finais podem definir `WANT_LESSTIF` para a dependência estar em package:x11-toolkits/lesstif[] ao invés de package:x11-toolkits/open-motif[].
[[uses-ncurses]]
== `ncurses`
Argumentos possíveis: (none), `base`, `port`
Utiliza ncurses, e faz com que algumas variáveis úteis sejam definidas.
[[uses-ninja]]
== `ninja`
Argumentos possíveis: (none)
Utiliza ninja para compilar o port.
[[uses-objc]]
== `objc`
Argumentos possíveis: (none)
Adiciona dependências de objetive C (compilador, biblioteca de runtime) se o sistema base não suportar isto.
[[uses-openal]]
== `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`.
[[uses-pathfix]]
== `pathfix`
Argumentos possíveis: (none)
Procura pelos arquivos [.filename]#Makefile.in# e [.filename]#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 [.filename]#.pc# do `pkgconfig` para [.filename]#${PREFIX}/libdata/pkgconfig#. Se o port usa `USES=autoreconf`, [.filename]#Makefile.am# será adicionado automaticamente a `PATHFIX_MAKEFILEIN`.
Se o port tem definido <<uses-cmake,`USES=cmake`>> ele vai procurar pelo arquivo [.filename]#CMakeLists.txt# dentro da variável `PATHFIX_WRKSRC`. Se necessário, esse nome de arquivo padrão pode ser alterado com `PATHFIX_CMAKELISTSTXT`.
[[uses-pear]]
== `pear`
Argumentos possíveis: `env`
Adiciona uma dependência do package: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 crossref:special[php-pear,Módulos PEAR] para maiores informações.
[[uses-perl5]]
== `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 [.filename]#Makefile.PL#, [.filename]#Build.PL# ou Módulo::Build::Tiny's, flavor de [.filename]#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 crossref:special[using-perl,Usando Perl] para maiores informações.
[[uses-pgsql]]
== `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`
[[uses-php]]
== `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, package: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 <<flavors-auto-php,PHP flavors>> automático. Flavors serão gerados para todas as versões do PHP, exceto as presentes na variável <<uses-php-ignore,`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`
[[uses-php-ignore]]
`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 [.filename]#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 package: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:
+
[.programlisting]
....
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.
[IMPORTANT]
====
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`.
====
[[uses-pkgconfig]]
== `pkgconfig`
Argumentos possíveis: (none), `build` (padrão), `run`, `both`
Utiliza package: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.
[[uses-pure]]
== `pure`
Argumentos possíveis: (none), `ffi`
Utiliza package:lang/pure[]. Usado largamente para build relacionado com ports pure. Com o argumento `ffi`, isso implica em package:devel/pure-ffi[] como uma dependência em run-time.
[[uses-pyqt]]
== `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:
[.programlisting]
....
USES= pyqt
USE_PYQT= core doc_build designer_run
....
[[uses-python]]
== `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 crossref:special[using-python, 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,`USES=shebangfix`>>, e o objetivo é apenas consertar os shebangs, mas não adicionar uma dependência do Python.
[[uses-qmail]]
== `qmail`
Argumentos possíveis: (none), `build`, `run`, `both`, `vars`
Utiliza package: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.
[[uses-qmake]]
== `qmake`
Argumentos possíveis: (none), `norecursive`, `outsource`, `no_env`, `no_configure`
Utiliza QMake para configuração. Para mais informações, veja crossref:special[using-qmake,Usando `qmake`].
[[uses-qt]]
== `qt`
Argumentos possíveis: `5`, `no_env`
Adiciona dependência de componentes Qt. `no_env` é passado diretamente para `USES= qmake`. Veja crossref:special[using-qt,Usando o Qt] para maiores informações.
[[uses-qt-dist]]
== `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.
[[qt5-dist-example]]
.Compilando Componentes do Qt 5
[example]
====
O port é o componente `networkauth` do Qt 5, que faz parte do arquivo de distribuição `networkauth`.
[.programlisting]
....
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`.
[[qt5-dist-example-explicit]]
.Compilando Componentes do Qt 5 com Nomes Diferentes
[example]
====
O port é o componente `gui` do Qt 5, que faz parte do arquivo de distribuição `base`.
[.programlisting]
....
PORTNAME= gui
DISTVERSION= ${QT5_VERSION}
USES= qt-dist:5,base
....
====
[[uses-readline]]
== `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 package:devel/readline[]
[[uses-samba]]
== `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 [.filename]#smbd#. `lib` irá adicionar uma dependência em [.filename]#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.
[[uses-scons]]
== `scons`
Argumentos possíveis: (none)
Fornece suporte para o uso do package:devel/scons[]. Veja crossref:special[using-scons,Usando `scons`] para maiores informações.
[[uses-shared-mime-info]]
== `shared-mime-info`
Argumentos possíveis: (none)
Utiliza update-mime-database a partir de package: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 crossref:plist[plist-keywords-shared-mime-info,`@shared-mime-info`] para o plist.
[[uses-shebangfix]]
== `shebangfix`
Argumentos possíveis: (none)
Muitos softwares usam locais incorretos para interpretadores de scripts, principalmente [.filename]#/usr/bin/perl# e [.filename]#/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 man:find[1]. Veja <<uses-shebangfix-ex-regex>>.
`SHEBANG_GLOB`::
Contém uma lista de padrões usados com o argumento `-name` do man:find[1]. Veja <<uses-shebangfix-ex-glob>>.
`SHEBANG_FILES`::
Contém uma lista de arquivos ou globs man: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-ex-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`.
+
[NOTE]
====
Estes vão _sempre_ ser parte da variável `interp_OLD_CMD:"/usr/bin/envinterp" /bin/interp /usr/bin/interp /usr/local/bin/interp`.
====
+
[TIP]
====
A variável `interp_OLD_CMD` contém vários valores. Qualquer entrada com espaços deve estar entre aspas. Veja <<uses-shebangfix-ex-ksh>>.
====
[IMPORTANT]
====
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 [.filename]#configure#, ou o [.filename]#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`.
====
[TIP]
====
Quando usado com <<uses-python,`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`.
====
[[uses-shebangfix-ex-lua]]
.Adicionando outro interpretadoror para `USES=shebangfix`
[example]
====
Para adicionar outro interpretador, defina a variável `SHEBANG_LANG`. Por exemplo:
[.programlisting]
....
SHEBANG_LANG= lua
....
====
[[uses-shebangfix-ex-ksh]]
.Especificando todos os Caminhos ao Adicionar um Interpretador para `USES=shebangfix`
[example]
====
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:
[.programlisting]
....
SHEBANG_LANG= ksh
ksh_OLD_CMD= "/usr/bin/env ksh" /bin/ksh /usr/bin/ksh
ksh_CMD= ${LOCALBASE}/bin/ksh
....
====
[[uses-shebangfix-ex-strange]]
.Adicionando uma Localização Estranha para um Interpretador
[example]
====
Alguns softwares usam localizações estranhas para um interpretador. Por exemplo, um aplicativo pode esperar que Python esteja localizado em [.filename]#/opt/bin/python2.7#. O caminho estranho a ser substituído pode ser declarado no [.filename]#Makefile# do port:
[.programlisting]
....
python_OLD_CMD= /opt/bin/python2.7
....
====
[[uses-shebangfix-ex-regex]]
.`USES=shebangfix` com a variável `SHEBANG_REGEX`
[example]
====
Para corrigir todos os arquivos em `${WRKSRC}/scripts` finalizados com [.filename]#.pl#, [.filename]#.sh# ou [.filename]#.cgi# faça assim:
[.programlisting]
....
USES= shebangfix
SHEBANG_REGEX= ./scripts/.*\.(sh|pl|cgi)
....
[NOTE]
======
`SHEBANG_REGEX` é usada executando `find -E`, que usa expressões regulares modernas, também conhecidas como expressões regulares estendidas. Veja man:re_format[7] para maiores informações.
======
====
[[uses-shebangfix-ex-glob]]
.`USES=shebangfix` com a variável `SHEBANG_GLOB`
[example]
====
Para corrigir todos os arquivos em `${WRKSRC}` finalizados com [.filename]#.pl# ou [.filename]#.sh#, faça assim:
[.programlisting]
....
USES= shebangfix
SHEBANG_GLOB= *.sh *.pl
....
====
[[uses-shebangfix-ex-files]]
.`USES=shebangfix` com a variável `SHEBANG_FILES`
[example]
====
Para corrigir os arquivos [.filename]#script/foobar.pl# e [.filename]#script/*.sh# dentro de `${WRKSRC}`, faça assim:
[.programlisting]
....
USES= shebangfix
SHEBANG_FILES= scripts/foobar.pl scripts/*.sh
....
====
[[uses-sqlite]]
== `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`.
[[uses-ssl]]
== `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.
[TIP]
====
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`:
[.programlisting]
....
BROKEN_SSL= libressl
BROKEN_SSL_REASON_libressl= needs features only available in OpenSSL
....
====
[[uses-tar]]
== `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.
[[uses-tcl]]
== `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 [.filename]#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
[[uses-terminfo]]
== `terminfo`
Argumentos possíveis: (none)
Adiciona <<plist-keywords-terminfo,`@terminfo`>> ao arquivo [.filename]#plist#. Use quando o port instalar arquivos [.filename]#*.terminfo# em [.filename]#${PREFIX}/shared/misc#.
[[uses-tk]]
== `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.
[[uses-uidfix]]
== `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,USES=fakeroot>> ou de aplicar algum patch.
[[uses-uniquefiles]]
== `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.
[[uses-varnish]]
== `varnish`
Argumentos possíveis: `4`, `6`
Manipula dependências do Varnish Cache.
`4` irá adicionar uma dependência do package:www/varnish4[].
`6` irá adicionar uma dependência do package:www/varnish6[].
[[uses-webplugin]]
== `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 [.filename]#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`.
[[uses-xfce]]
== `xfce`
Argumentos possíveis: (none), `gtk2`
Fornece suporte para ports relacionados ao Xfce. Veja crossref:special[using-xfce,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, package:x11/libxfce4menu[] e package:x11-wm/xfce4-panel[].
[[uses-xorg]]
== `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:
[[using-x11-components]]
.Componentes Disponíveis do X.Org
[cols="1,1", frame="none", options="header"]
|===
| 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
|===
[[uses-xorg-cat]]
== `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.
[[uses-zip]]
== `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.