Começando (Livro de receitas do GNU Guix)

7.1 Começando

Como fazemos para “Guixificar” um repositório? O primeiro passo, como vimos, será adicionar um guix.scm na raiz do repositório em questão. Usaremos Guile como exemplo neste capítulo: ele é escrito em Scheme (principalmente) e C, e tem várias dependências — uma cadeia de ferramentas de compilação C, bibliotecas C, Autoconf e seus amigos, LaTeX, e assim por diante. O guix.scm resultante se parece com a definição de pacote usual (veja Definindo pacotes em Manual de Referência GNU Guix), só que sem o bit define-public:

;; O arquivo ‘guix.scm’ para Guile, para uso pelo ‘guix shell’.

(use-modules (guix)
             (guix build-system gnu)
             ((guix licenses) #:prefix license:)
             (gnu packages autotools)
             (gnu packages base)
             (gnu packages bash)
             (gnu packages bdw-gc)
             (gnu packages compression)
             (gnu packages flex)
             (gnu packages gdb)
             (gnu packages gettext)
             (gnu packages gperf)
             (gnu packages libffi)
             (gnu packages libunistring)
             (gnu packages linux)
             (gnu packages pkg-config)
             (gnu packages readline)
             (gnu packages tex)
             (gnu packages texinfo)
             (gnu packages version-control))

(package
  (name "guile")
  (version "3.0.99-git")                          ;número da versão funky
  (source #f)                                     ;nenhuma fonte
  (build-system gnu-build-system)
  (native-inputs
   (append (list autoconf
                 automake
                 libtool
                 gnu-gettext
                 flex
                 texinfo
                 texlive-base                 ;para "make pdf"
                 texlive-epsf
                 gperf
                 git
                 gdb
                 strace
                 readline
                 lzip
                 pkg-config)

           ;; Ao compilar cruzadamente, uma versão nativa do próprio Guile é
           ;; needed.
           (if (%current-target-system)
               (list this-package)
               '())))
  (inputs
   (list libffi bash-minimal))
  (propagated-inputs
   (list libunistring libgc))

  (native-search-paths
   (list (search-path-specification
          (variable "GUILE_LOAD_PATH")
          (files '("share/guile/site/3.0")))
         (search-path-specification
          (variable "GUILE_LOAD_COMPILED_PATH")
          (files '("lib/guile/3.0/site-ccache")))))
  (synopsis "Scheme implementation intended especially for extensions")
  (description
   "Guile is the GNU Ubiquitous Intelligent Language for Extensions,
and it's actually a full-blown Scheme implementation!")
  (home-page "https://www.gnu.org/software/guile/")
  (license license:lgpl3+))

um pouco de clichê, mas agora alguém que queira hackear o Guile só precisa executar:

guix shell

Isso lhes dá um shell contendo todas as dependências do Guile: aquelas listadas acima, mas também dependências implícitas, como a cadeia de ferramentas GCC, GNU Make, sed, grep e assim por diante. Veja Invocando guix shell em Manual de Referência do GNU Guix, para mais informações sobre guix shell.

Recomendação do chef: Nossa sugestão é criar ambientes de desenvolvimento como este:
guix shell --container --link-profile
... ou, para abreviar:
guix shell -CP
Isso dá um shell em um contêiner isolado, e todas as dependências aparecem em $HOME/.guix-profile, que funciona bem com caches como config.cache (veja Cache Files em Autoconf) e nomes de arquivos absolutos registrados em Makefiles gerados e similares. O fato de o shell rodar em um contêiner traz paz de espírito: nada além do diretório atual e das dependências do Guile é visível dentro do contêiner; nada do sistema pode interferir no seu desenvolvimento.