---
title: Capítulo 17. Using USES Macros
prev: books/porters-handbook/keeping-up
next: books/porters-handbook/versions
---

[[uses]]
= Usando Macros `USES`
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:source-highlighter: rouge
:experimental:
:skip-front-matter:
:xrefstyle: basic
:relfileprefix: ../
:outfilesuffix:
:sectnumoffset: 17
:c-plus-plus: c++
:toc-title: Índice
:table-caption: Tabela
:figure-caption: Figura
:example-caption: Exemplo

include::shared/mirrors.adoc[]
include::shared/authors.adoc[]
include::shared/releases.adoc[]
include::shared/pt-br/mailing-lists.adoc[]
include::shared/pt-br/teams.adoc[]
include::shared/pt-br/urls.adoc[]

toc::[]

[[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 <<haskell-libs>> 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 <<using-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 <<using-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 <<using-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:ports-secteam@FreeBSD.org[ports-secteam@FreeBSD.org].
. 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 <<slow-patch-automatic-replacements>> 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/mesa-libs[]

`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/mesa-libs[]

`glesv2`::
Adiciona uma dependência de biblioteca [.filename]#libGLESv2.so# de package:graphics/mesa-libs[]

`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[]

[[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 <<using-gnome>> para maiores informações.

[[uses-go]]
== `go`

[IMPORTANT]
====
Não devem ser criados Ports de bibliotecas Go, veja <<go-libs>> 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 <<using-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 <<php-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 <<using-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 <<using-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 <<using-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 <<using-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 <<using-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 <<php-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 <<using-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 <<using-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 <<using-qmake>>.

[[uses-qt]]
== `qt`

Argumentos possíveis: `5`, `no_env`

Adiciona dependência de componentes Qt. `no_env` é passado diretamente para `USES= qmake`. Veja <<using-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 <<using-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 <<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`, `5`

Manipula dependências do Varnish Cache. `4` irá adicionar uma dependência do package:www/varnish4[]. `5` irá adicionar uma dependência do package:www/varnish5[].

[[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 <<using-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.
