---

8.2.1 Referência do package

Esta seção resume todas as opções disponíveis nas declarações package (veja Definindo pacotes).

Tipo de dados: package

Este é o tipo de dado que representa uma receita de pacote.

name

The name of the package, as a string.

version

The version of the package, as a string. Veja Números de versão, for guidelines.

source

Um objeto que diz como o código-fonte do pacote deve ser adquirido. Na maioria das vezes, este é um objeto origin, que denota um arquivo obtido da Internet (veja Referência do origin). Também pode ser qualquer outro objeto “tipo arquivo”, como um local-file, que denota um arquivo do sistema de arquivos local (veja local-file).

build-system

O sistema de compilação que deve ser usado para compilar o pacote (veja Sistemas de compilação).

arguments (padrão: '())

Os argumentos que devem ser passados para o sistema de compilação (veja Sistemas de compilação). Esta é uma lista, normalmente contendo pares sequenciais de palavra-chave-valor, como neste exemplo:

(package
  (name "example")
  ;; several fields omitted
  (arguments
    (list #:tests? #f                     ;skip tests
          #:make-flags #~'("VERBOSE=1")   ;pass flags to 'make'
          #:configure-flags #~'("--enable-frobbing"))))

O conjunto exato de palavras-chave suportadas depende do sistema de compilação (veja Sistemas de compilação), mas você verá que quase todas elas honram #:configure-flags, #:make-flags, #:tests? e #:phases. A palavra-chave #:phases em particular permite que você modifique o conjunto de fases de compilação para seu pacote (veja Fases de construção).

O REPL tem comandos dedicados para inspecionar interativamente os valores de alguns desses argumentos, como um auxílio de depuração conveniente (veja Usando Guix interativamente).

Nota de compatibilidade: Até a versão 1.3.0, o campo arguments normalmente usaria quote (') ou quasiquote (`) e nenhuma expressão G, assim:

(package
  ;; several fields omitted
  (arguments   ;old-style quoted arguments
   '(#:tests? #f
     #:configure-flags '("--enable-frobbing"))))

Para converter esse estilo para o mostrado acima, você pode executar guix style -S arguments pacote (veja Invoking guix style).

inputs (padrão: '()) ¶

native-inputs (padrão: '())

propagated-inputs (padrão: '())

Esses campos listam dependências do pacote. Cada elemento dessas listas é um pacote, origem ou outro “objeto tipo arquivo” (veja Expressões-G); para especificar a saída desse objeto tipo arquivo que deve ser usado, passe uma lista de dois elementos onde o segundo elemento é a saída (veja Pacotes com múltiplas saídas, para mais informações sobre saídas de pacotes). Por exemplo, a lista abaixo especifica três entradas:

(list libffi libunistring
      `(,glib "bin"))      ;a saída "bin" de GLib

No exemplo acima, a saída "out" de libffi e libunistring é usada.

Nota de compatibilidade: Até a versão 1.3.0, as listas de entrada eram uma lista de tuplas, onde cada tupla tem um rótulo para a entrada (uma string) como seu primeiro elemento, um pacote, origem ou derivação como seu segundo elemento e, opcionalmente, o nome da saída que deve ser usada, cujo padrão é "out". Por exemplo, a lista abaixo é equivalente à acima, mas usando o antigo estilo de entrada:

;; Estilo de entrada antigo (obsoleto).
`(("libffi" ,libffi)
  ("libunistring" ,libunistring)
  ("glib:bin" ,glib "bin"))  ;a saída "bin" do GLib

Este estilo agora está obsoleto; ele ainda é suportado, mas o suporte será removido em uma versão futura. Ele não deve ser usado para novas definições de pacote. Veja Invoking guix style, sobre como migrar para o novo estilo.

A distinção entre native-inputs e inputs é necessária ao considerar a compilação cruzada. Ao compilar cruzadamente, as dependências listadas em inputs são construídas para a arquitetura target (alvo); inversamente, as dependências listadas em native-inputs são construídas para a arquitetura da máquina build.

native-inputs é normalmente usado para listar ferramentas necessárias no momento da compilação, mas não no momento da execução, como Autoconf, Automake, pkg-config, Gettext ou Bison. guix lint pode relatar prováveis erros nesta área (veja Invocando guix lint).

Por fim, propagated-inputs é semelhante a inputs, mas os pacotes especificados serão instalados automaticamente nos perfis (veja a função dos perfis no Guix) junto com o pacote ao qual pertencem (veja guix package, para obter informações sobre como guix package lida com entradas propagadas).

Por exemplo, isso é necessário ao empacotar uma biblioteca C/C++ que precisa de cabeçalhos de outra biblioteca para compilar, ou quando um arquivo pkg-config faz referência a outro por meio de seu campo Requires.

Outro exemplo em que propagated-inputs é útil é para linguagens que não têm um recurso para registrar o caminho de pesquisa em tempo de execução semelhante ao RUNPATH de arquivos ELF; isso inclui Guile, Python, Perl e mais. Ao empacotar bibliotecas escritas nessas linguagens, garanta que elas possam encontrar o código da biblioteca do qual dependem em tempo de execução listando as dependências em tempo de execução em propagated-inputs em vez de inputs.

outputs (padrão: '("out"))

A lista de nomes de saída do pacote. Veja Pacotes com múltiplas saídas, para usos típicos de saídas adicionais.

native-search-paths (padrão: '())

search-paths (padrão: '())

Uma lista de objetos search-path-specification descrevendo variáveis de ambiente do caminho de pesquisa respeitadas pelo pacote. Veja Caminhos de pesquisa, para mais informações sobre especificações do caminho de pesquisa.

Quanto às entradas, a distinção entre native-search-paths e search-paths só importa quando há compilação cruzada. Em um contexto de compilação cruzada, native-search-paths se aplica exclusivamente a entradas nativas, enquanto search-paths se aplica somente a entradas de host.

Pacotes como compiladores cruzados se importam com entradas de destino — por exemplo, nosso compilador cruzado GCC (modificado) tem CROSS_C_INCLUDE_PATH em search-paths, o que permite que ele escolha arquivos .h para o sistema de destino e não aqueles de entradas nativas. Para a maioria dos pacotes, porém, apenas native-search-paths faz sentido.

replacement (padrão: #f)

Deve ser #f ou um objeto de pacote que será usado como um substituição para este pacote. Veja enxertos, para detalhes.

synopsis

Uma descrição de uma linha do pacote.

description

Uma descrição mais elaborada do pacote, como uma string na sintaxe Texinfo.

license ¶

A licença do pacote; um valor de (guix licenses), ou uma lista de tais valores.

home-page

A URL para a página inicial do pacote, como uma string.

supported-systems (padrão: %supported-systems)

A lista de sistemas suportados pelo pacote, como strings do formato arquitetura-kernel, por exemplo "x86_64-linux".

location (padrão: localização de origem do formulário package)

O local de origem do pacote. É útil sobrescrever isso ao herdar de outro pacote, em cujo caso esse campo não é corrigido automaticamente.

Macro: this-package

Quando usado no escopo lexical de uma definição de campo de pacote, esse identificador é resolvido para o pacote que está sendo definido.

O exemplo abaixo mostra como adicionar um pacote como uma entrada nativa de si mesmo durante a compilação cruzada:

(package
  (name "guile")
  ;; ...

  ;; Quando compilado de forma cruzada, Guile, por exemplo, depende de
  ;; uma versão nativa de si mesmo. Adicione aqui.
  (native-inputs (if (%current-target-system)
                     (list this-package)
                     '())))

É um erro fazer referência a this-package fora de uma definição de pacote.

Os seguintes procedimentos auxiliares são fornecidos para ajudar a lidar com entradas de pacotes.

Procedimento: lookup-package-input pacote nome

Procedimento: lookup-package-native-input pacote nome

Procedimento: lookup-package-propagated-input pacote nome

Procedimento: lookup-package-direct-input pacote nome

Procure nome entre as entradas de pacote (ou entradas nativas, propagadas ou diretas). Retorne-o se encontrado, #f caso contrário.

name is the name of a package or the file name of an origin depended on. Here’s how you might use it:

(use-modules (guix packages) (gnu packages base))

(lookup-package-direct-input coreutils "gmp")
⇒ #<package gmp@6.2.1 …>

Neste exemplo, obtemos o pacote gmp que está entre as entradas diretas de coreutils.

When looking up an origin, use the name that appears in the origin’s file-name field or its default file name—e.g., "foo-1.2.tar.gz".

Às vezes, você vai querer obter a lista de entradas necessárias para desenvolver um pacote—todas as entradas que são visíveis quando o pacote é compilado. É isso que o procedimento package-development-inputs retorna.

Procedimento: package-development-inputs pacote [sistema] [#:target #f]

Retorna a lista de entradas necessárias para pacote para fins de desenvolvimento em sistema. Quando target é verdadeiro, retorna as entradas necessárias para compilar cruzadamente pacote de sistema para o alvo target, onde target é um tripleto como "aarch64-linux-gnu".

Note que o resultado inclui entradas explícitas e entradas implícitas—entradas adicionadas automaticamente pelo sistema de construção (veja Sistemas de compilação). Vamos pegar o pacote hello para ilustrar isso:

(use-modules (gnu packages base) (guix packages))

hello
⇒ #<package hello@2.10 gnu/packages/base.scm:79 7f585d4f6790>

(package-direct-inputs hello)
⇒ ()

(package-development-inputs hello)
⇒ (("source" …) ("tar" #<package tar@1.32 …>) …)

Neste exemplo, package-direct-inputs retorna a lista vazia, porque hello tem zero dependências explícitas. Por outro lado, package-development-inputs inclui entradas adicionadas implicitamente por gnu-build-system que são necessárias para construir hello: tar, gzip, GCC, libc, Bash e mais. Para visualizá-lo, guix graph hello mostraria entradas explícitas, enquanto guix graph -t bag hello incluiria entradas implícitas (veja Invocando guix graph).

Como os pacotes são objetos Scheme regulares que capturam um grafo de dependência completo e procedimentos de construção associados, geralmente é útil escrever procedimentos que pegam um pacote e retornam uma versão modificada dele de acordo com alguns parâmetros. Abaixo estão alguns exemplos.

Procedimento: package-with-c-toolchain pacote cadeia

Retorna uma variante de pacote que usa cadeia de ferramentas em vez da cadeia de ferramentas padrão GNU C/C++. cadeia deve ser uma lista de entradas (tuplas de rótulo/pacote) que fornecem funcionalidade equivalente, como o pacote gcc-toolchain.

O exemplo abaixo retorna uma variante do pacote hello criado com GCC 10.x e o restante da cadeia de ferramentas GNU (Binutils e a Biblioteca C GNU) em vez da cadeia de ferramentas padrão:

(let ((toolchain (specification->package "gcc-toolchain@10")))
  (package-with-c-toolchain hello `(("toolchain" ,toolchain))))

A cadeia de ferramentas de construção é parte das entradas implícitas dos pacotes—geralmente não é listada como parte dos vários campos “entradas” e, em vez disso, é puxada pelo sistema de construção. Consequentemente, esse procedimento funciona alterando o sistema de construção de pacote para que ele puxe cadeia de ferramentas em vez dos padrões. Veja Sistemas de compilação, para mais informações sobre sistemas de construção.