# Capítulo 17. Using USES Macros

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

## 17.1. Uma introdução ao `USES`

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

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

Exemplo 1. Usando Vários Valores

    USES=	bison perl

Exemplo 2. Adicionando um Argumento

    USES=	tar:xz

Exemplo 3. Adicionando Vários Argumentos

    USES=	drupal:7,theme

Exemplo 4. Entrelaçando Tudo Isso Junto

    USES=	pgsql:9.3+ cpe python:2.7,build

## 17.2. `7z`

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

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

## 17.3. `ada`

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

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

## 17.4. `autoreconf`

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

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

## 17.5. `blaslapack`

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

Adiciona dependências das bibliotecas Blas / Lapack.

## 17.6. `bdb`

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

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

`BDB_LIB_NAME`

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

`BDB_LIB_CXX_NAME`

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

`BDB_INCLUDE_DIR`

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

`BDB_LIB_DIR`

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

`BDB_VER`

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

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

## 17.7. `bison`

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

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

## 17.8. `cabal`

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

Argumentos possíveis: (none), `hpack`

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

O framework fornece as seguintes variáveis:

`USE_CABAL`

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

`CABAL_FLAGS`

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

`EXECUTABLES`

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

`SKIP_CABAL_PLIST`

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

`opt_USE_CABAL`

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

`opt_EXECUTABLES`

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

`opt_CABAL_FLAGS`

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

`FOO_DATADIR_VARS`

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

## 17.9. `cargo`

Argumentos possíveis: (none)

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

## 17.10. `charsetfix`

Argumentos possíveis: (none)

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

## 17.11. `cmake`

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

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

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

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

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

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

## 17.12. `compiler`

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

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

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

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

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

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

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

- `CHOSEN_COMPILER_TYPE`: o compilador escolhido, gcc ou clang

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

## 17.13. `cpe`

Argumentos possíveis: (none)

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

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

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

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

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

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

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

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

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

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

## 17.14. `cran`

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

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

## 17.15. `desktop-file-utils`

Argumentos possíveis: (none)

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

## 17.16. `desthack`

Argumentos possíveis: (none)

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

## 17.17. `display`

Argumentos possíveis: (none), ARGS

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

## 17.18. `dos2unix`

Argumentos possíveis: (none)

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

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

- `DOS2UNIX_FILES`: casa com nomes de arquivos literais.

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

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

## 17.19. `drupal`

Argumentos possíveis: `7`, `module`, `theme`

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

## 17.20. `fakeroot`

Argumentos possíveis: (none)

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

## 17.21. `fam`

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

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

## 17.22. `firebird`

Argumentos possíveis: (none), `25`

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

## 17.23. `fonts`

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

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

## 17.24. `fortran`

Argumentos possíveis: `gcc` (padrão)

Usa o compilador GNU Fortran.

## 17.25. `fuse`

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

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

## 17.26. `gem`

Argumentos possíveis: (none), `noautoplist`

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

## 17.27. `gettext`

Argumentos possíveis: (none)

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

## 17.28. `gettext-runtime`

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

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

## 17.29. `gettext-tools`

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

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

## 17.30. `ghostscript`

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

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

## 17.31. `gl`

Argumentos possíveis: (none)

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

`egl`

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

`gbm`

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

`gl`

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

`glesv2`

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

`glew`

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

`glu`

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

`glut`

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

`opengl`

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

## 17.32. `gmake`

Argumentos possíveis: (none)

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

## 17.33. `gnome`

Argumentos possíveis: (none)

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

- `atk`

- `atkmm`

- `cairo`

- `cairomm`

- `dconf`

- `esound`

- `evolutiondataserver3`

- `gconf2`

- `gconfmm26`

- `gdkpixbuf`

- `gdkpixbuf2`

- `glib12`

- `glib20`

- `glibmm`

- `gnomecontrolcenter3`

- `gnomedesktop3`

- `gnomedocutils`

- `gnomemenus3`

- `gnomemimedata`

- `gnomeprefix`

- `gnomesharp20`

- `gnomevfs2`

- `gsound`

- `gtk-update-icon-cache`

- `gtk12`

- `gtk20`

- `gtk30`

- `gtkhtml3`

- `gtkhtml4`

- `gtkmm20`

- `gtkmm24`

- `gtkmm30`

- `gtksharp20`

- `gtksourceview`

- `gtksourceview2`

- `gtksourceview3`

- `gtksourceviewmm3`

- `gvfs`

- `intlhack`

- `intltool`

- `introspection`

- `libartlgpl2`

- `libbonobo`

- `libbonoboui`

- `libgda5`

- `libgda5-ui`

- `libgdamm5`

- `libglade2`

- `libgnome`

- `libgnomecanvas`

- `libgnomekbd`

- `libgnomeprint`

- `libgnomeprintui`

- `libgnomeui`

- `libgsf`

- `libgtkhtml`

- `libgtksourceviewmm`

- `libidl`

- `librsvg2`

- `libsigc++12`

- `libsigc++20`

- `libwnck`

- `libwnck3`

- `libxml++26`

- `libxml2`

- `libxslt`

- `metacity`

- `nautilus3`

- `orbit2`

- `pango`

- `pangomm`

- `pangox-compat`

- `py3gobject3`

- `pygnome2`

- `pygobject`

- `pygobject3`

- `pygtk2`

- `pygtksourceview`

- `referencehack`

- `vte`

- `vte3`

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

    USES=		gnome
    USE_GNOME=	gnomemenus3:build intlhack

Veja Usando o GNOME para maiores informações.

## 17.34. `go`

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

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

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

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

`GO_PKGNAME`

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

`GO_TARGET`

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

`GO_TESTTARGET`

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

`CGO_CFLAGS`

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

`CGO_LDFLAGS`

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

`GO_BUILDFLAGS`

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

`GO_TESTFLAGS`

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

`GO_PORT`

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

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

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

## 17.35. `gperf`

Argumentos possíveis: (none)

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

## 17.36. `grantlee`

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

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

## 17.37. `groff`

Argumentos possíveis: `build`, `run`, `both`

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

## 17.38. `gssapi`

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

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

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

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

- `GSSAPIBASEDIR`

- `GSSAPICPPFLAGS`

- `GSSAPIINCDIR`

- `GSSAPILDFLAGS`

- `GSSAPILIBDIR`

- `GSSAPILIBS`

- `GSSAPI_CONFIGURE_ARGS`

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

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

Exemplo 5. Uso Típico

    OPTIONS_SINGLE=	GSSAPI
    OPTIONS_SINGLE_GSSAPI=	GSSAPI_BASE GSSAPI_HEIMDAL GSSAPI_MIT GSSAPI_NONE

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

## 17.39. `horde`

Argumentos possíveis: (none)

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

## 17.40. `iconv`

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

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

## 17.41. `imake`

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

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

## 17.42. `kde`

Argumentos possíveis: `5`

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

## 17.43. `kmod`

Argumentos possíveis: (none), `debug`

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

- Adiciona `kld` em `CATEGORIES`.

- Define `SSP_UNSAFE`.

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

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

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

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

## 17.44. `lha`

Argumentos possíveis: (none)

Define `EXTRACT_SUFX` para `.lzh`

## 17.45. `libarchive`

Argumentos possíveis: (none)

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

## 17.46. `libedit`

Argumentos possíveis: (none)

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

## 17.47. `libtool`

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

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

## 17.48. `linux`

Argumentos possíveis: `c6`, `c7`

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

- `allegro`

- `alsa-plugins-oss`

- `alsa-plugins-pulseaudio`

- `alsalib`

- `atk`

- `avahi-libs`

- `base`

- `cairo`

- `cups-libs`

- `curl`

- `cyrus-sasl2`

- `dbusglib`

- `dbuslibs`

- `devtools`

- `dri`

- `expat`

- `flac`

- `fontconfig`

- `gdkpixbuf2`

- `gnutls`

- `graphite2`

- `gtk2`

- `harfbuzz`

- `jasper`

- `jbigkit`

- `jpeg`

- `libasyncns`

- `libaudiofile`

- `libelf`

- `libgcrypt`

- `libgfortran`

- `libgpg-error`

- `libmng`

- `libogg`

- `libpciaccess`

- `libsndfile`

- `libsoup`

- `libssh2`

- `libtasn1`

- `libthai`

- `libtheora`

- `libv4l`

- `libvorbis`

- `libxml2`

- `mikmod`

- `naslibs`

- `ncurses-base`

- `nspr`

- `nss`

- `openal`

- `openal-soft`

- `openldap`

- `openmotif`

- `openssl`

- `pango`

- `pixman`

- `png`

- `pulseaudio-libs`

- `qt`

- `qt-x11`

- `qtwebkit`

- `scimlibs`

- `sdl12`

- `sdlimage`

- `sdlmixer`

- `sqlite3`

- `tcl85`

- `tcp_wrappers-libs`

- `tiff`

- `tk85`

- `ucl`

- `xorglibs`

## 17.49. `localbase`

Argumentos possíveis: (none), `ldflags`

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

## 17.50. `lua`

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

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

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

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

Para maiores informações, veja Usando Lua.

## 17.51. `lxqt`

Argumentos possíveis: (none)

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

## 17.52. `makeinfo`

Argumentos possíveis: (none)

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

## 17.53. `makeself`

Argumentos possíveis: (none)

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

## 17.54. `mate`

Argumentos possíveis: (none)

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

- `autogen`

- `caja`

- `common`

- `controlcenter`

- `desktop`

- `dialogs`

- `docutils`

- `icontheme`

- `intlhack`

- `intltool`

- `libmatekbd`

- `libmateweather`

- `marco`

- `menus`

- `notificationdaemon`

- `panel`

- `pluma`

- `polkit`

- `session`

- `settingsdaemon`

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

    USES=		mate
    USE_MATE=	menus:build intlhack

## 17.55. `meson`

Argumentos possíveis: (none)

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

## 17.56. `metaport`

Argumentos possíveis: (none)

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

## 17.57. `mysql`

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

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

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

## 17.58. `mono`

Argumentos possíveis: (none), `nuget`

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

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

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

## 17.59. `motif`

Argumentos possíveis: (none)

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

## 17.60. `ncurses`

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

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

## 17.61. `ninja`

Argumentos possíveis: (none)

Utiliza ninja para compilar o port.

## 17.62. `objc`

Argumentos possíveis: (none)

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

## 17.63. `openal`

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

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

## 17.64. `pathfix`

Argumentos possíveis: (none)

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

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

## 17.65. `pear`

Argumentos possíveis: `env`

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

## 17.66. `perl5`

Argumentos possíveis: (none)

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

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

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

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

Veja Usando Perl para maiores informações.

## 17.67. `pgsql`

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

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

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

- `client`

- `contrib`

- `docs`

- `pgtcl`

- `plperl`

- `plpython`

- `pltcl`

- `server`

## 17.68. `php`

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

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

`phpize`

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

`ext`

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

`zend`

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

`build`

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

`cli`

  Precisa da versão CLI do PHP.

`cgi`

  Precisa da versão CGI do PHP.

`mod`

  Precisa do módulo Apache para o PHP.

`web`

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

`embed`

  Precisa da versão da biblioteca embarcada do PHP.

`pecl`

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

`flavors`

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

`noflavors`

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

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

`USE_PHP`

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

`IGNORE_WITH_PHP`

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

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

`PHP_MODNAME`

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

`PHP_HEADER_DIRS`

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

`PHP_MOD_PRIO`

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

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

      USES=		php:ext
      USE_PHP=	wddx
      PHP_MOD_PRIO=	40

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

`PHP_PKGNAMEPREFIX`

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

`PHP_PKGNAMESUFFIX`

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

`PECL_PKGNAMEPREFIX`

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

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

## 17.69. `pkgconfig`

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

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

## 17.70. `pure`

Argumentos possíveis: (none), `ffi`

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

## 17.71. `pyqt`

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

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

- `core`

- `dbus`

- `dbussupport`

- `demo`

- `designer`

- `designerplugin`

- `doc`

- `gui`

- `multimedia`

- `network`

- `opengl`

- `qscintilla2`

- `sip`

- `sql`

- `svg`

- `test`

- `webkit`

- `xml`

- `xmlpatterns`

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

- `assistant`

- `declarative`

- `help`

- `phonon`

- `script`

- `scripttools`

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

- `multimediawidgets`

- `printsupport`

- `qml`

- `serialport`

- `webkitwidgets`

- `widgets`

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

    USES=		pyqt
    USE_PYQT=	core doc_build designer_run

## 17.72. `python`

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

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

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

## 17.73. `qmail`

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

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

## 17.74. `qmake`

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

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

## 17.75. `qt`

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

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

## 17.76. `qt-dist`

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

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

Exemplo 6. Compilando Componentes do Qt 5

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

    PORTNAME=	networkauth
    DISTVERSION=	${QT5_VERSION}

    USES=		qt-dist:5

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

Exemplo 7. Compilando Componentes do Qt 5 com Nomes Diferentes

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

    PORTNAME=	gui
    DISTVERSION=	${QT5_VERSION}

    USES=		qt-dist:5,base

## 17.77. `readline`

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

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

## 17.78. `samba`

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

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

`SAMBAPORT`

  A origem do port padrão Samba.

`SAMBAINCLUDES`

  A localização dos arquivos header do Samba.

`SAMBALIBS`

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

## 17.79. `scons`

Argumentos possíveis: (none)

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

## 17.80. `shared-mime-info`

Argumentos possíveis: (none)

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

## 17.81. `shebangfix`

Argumentos possíveis: (none)

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

`SHEBANG_REGEX`

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

`SHEBANG_GLOB`

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

`SHEBANG_FILES`

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

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

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

`SHEBANG_LANG`

  A lista de interpretadores suportados.

`interp_CMD`

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

`interp_OLD_CMD`

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

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

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

| A correção de shebangs é feita durante a fase `patch`. Se os scripts forem criados com shebangs incorretos durante a fase `build`, o processo de build (por exemplo, o script configure, ou o Makefiles) deve ser corrigido ou ter o caminho certo (por exemplo, com `CONFIGURE_ENV`, `CONFIGURE_ARGS`, `MAKE_ENV` ou `MAKE_ARGS`) para gerar as shebangs certas. Os caminhos corretos para os interpretadores suportados estão disponíveis em `interp_CMD`.

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

Exemplo 8. Adicionando outro interpretadoror para `USES=shebangfix`

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

    SHEBANG_LANG=	lua

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

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

    SHEBANG_LANG=	ksh
    ksh_OLD_CMD=	"/usr/bin/env ksh" /bin/ksh /usr/bin/ksh
    ksh_CMD=	${LOCALBASE}/bin/ksh

Exemplo 10. Adicionando uma Localização Estranha para um Interpretador

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

    python_OLD_CMD=	/opt/bin/python2.7

Exemplo 11. `USES=shebangfix` com a variável `SHEBANG_REGEX`

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

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

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

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

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

    USES=	shebangfix
    SHEBANG_GLOB=	*.sh *.pl

Exemplo 13. `USES=shebangfix` com a variável `SHEBANG_FILES`

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

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

## 17.82. `sqlite`

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

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

## 17.83. `ssl`

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

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

`OPENSSLBASE`

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

`OPENSSLDIR`

  Caminho para arquivos de configuração do OpenSSL.

`OPENSSLLIB`

  Caminho para as bibliotecas do OpenSSL.

`OPENSSLINC`

  Caminho para os includes do OpenSSL.

`OPENSSLRPATH`

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

| Se um port não for compilado com um flavor OpenSSL, defina a variável `BROKEN_SSL`, e possivelmente a variável `BROKEN_SSL_REASON_flavor`:
    BROKEN_SSL=	libressl
    BROKEN_SSL_REASON_libressl=	needs features only available in OpenSSL

## 17.84. `tar`

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

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

## 17.85. `tcl`

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

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

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

- `TCLSH`: caminho completo do interpretador do Tcl

- `TCL_LIBDIR`: caminho das bibliotecas do Tcl

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

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

- `WISH`: caminho completo do interpretador do Tk

- `TK_LIBDIR`: caminho das bibliotecas do Tk

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

## 17.86. `terminfo`

Argumentos possíveis: (none)

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

## 17.87. `tk`

Os mesmos argumentos para `tcl`

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

## 17.88. `uidfix`

Argumentos possíveis: (none)

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

## 17.89. `uniquefiles`

Argumentos possíveis: (none), `dirs`

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

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

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

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

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

## 17.90. `varnish`

Argumentos possíveis: `4`, `6`

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

## 17.91. `webplugin`

Argumentos possíveis: (none), `ARGS`

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

- `gecko`: suporte a plug-ins baseados no Gecko

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

- `linux`: suporte a plug-ins do Linux

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

- (entradas individuais): suporta apenas os navegadores listados

Essas variáveis podem ser ajustadas:

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

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

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

## 17.92. `xfce`

Argumentos possíveis: (none), `gtk2`

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

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

## 17.93. `xorg`

Argumentos possíveis: (none)

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

Tabela 1. Componentes Disponíveis do X.Org
Nome | Descrição
--- | ---
`dmx` | Biblioteca de extensão DMX
`fontenc` | Biblioteca fontenc
`fontutil` | Crie um índice de arquivos de fontes X em um diretório
`ice` | Biblioteca Inter Client Exchange para X11
`libfs` | Biblioteca FS
`pciaccess` | Biblioteca Genérica de acesso ao PCI
`pixman` | Biblioteca de manipulação de pixels de baixo nível
`sm` | Biblioteca de Gerenciamento de Sessão para X11
`x11` | Biblioteca X11
`xau` | Biblioteca do Protocolo de Autenticação para o X11
`xaw` | Biblioteca de Widgets do X Athena
`xaw6` | Biblioteca de Widgets do X Athena
`xaw7` | Biblioteca de Widgets do X Athena
`xbitmaps` | Arquivos bitmaps do X.Org
`xcb` | Biblioteca do protocolo X C-language Binding (XCB)
`xcomposite` | Biblioteca de extensão X Composite
`xcursor` | Biblioteca de carregamento do cursor X no lado do cliente
`xdamage` | Biblioteca de extensão X Damage
`xdmcp` | Biblioteca do Protocolo de Controle do X Display Manager
`xext` | Biblioteca de Extensão X11
`xfixes` | Biblioteca de extensão X Fixes
`xfont` | Biblioteca de fontes do X
`xfont2` | Biblioteca de fontes do X
`xft` | API de fontes do lado do cliente para aplicativos X
`xi` | Biblioteca de extensão X Input
`xinerama` | Biblioteca X11 Xinerama
`xkbfile` | Biblioteca XKB
`xmu` | Biblioteca de Utilitários Diversos do X
`xmuu` | Biblioteca de Utilitários Diversos do X
`xorg-macros` | Macros aclocal de desenvolvimento X.Org
`xorg-server` | Servidor X do X.Org e programas relacionados
`xorgproto` | xorg protocol headers
`xpm` | Biblioteca Pixmap do X
`xpresent` | Biblioteca de Extensão X Present
`xrandr` | Biblioteca de extensão X Resize e Rotate
`xrender` | Biblioteca de extensão X Render
`xres` | Biblioteca de uso X Resource
`xscrnsaver` | Biblioteca XScrnSaver
`xshmfence` | Memória compartilhada 'SyncFence' primitiva de sincronização
`xt` | Biblioteca X Toolkit
`xtrans` | Código de rede abstrato para X
`xtst` | Extensão X Test
`xv` | Biblioteca de Extensão X Video
`xvmc` | Biblioteca X Video Extension Motion Compensation
`xxf86dga` | X DGA Extension
`xxf86vm` | Extensão X Vidmode

## 17.94. `xorg-cat`

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

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

A categoria deve corresponder às categorias upstream.

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

## 17.95. `zip`

Argumentos possíveis: (none), `infozip`

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

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

Anterior
Início
Próximo