22.8.6 Cyclic Module Dependencies

Embora não possa haver dependências circulares entre pacotes, o mecanismo frouxo de carregamento de módulos do Guile permite dependências circulares entre módulos do Guile, o que não causa problemas, desde que as seguintes condições sejam seguidas para dois módulos que fazem parte de um ciclo de dependência:

1. As macros não devem ser compartilhadas entre os módulos co-dependentes
2. Top-level variables are only referenced in delayed (thunked) package fields: arguments, native-inputs, inputs, propagated-inputs or replacement
3. Procedures referencing top-level variables from another module are not called at the top level of a module themselves.

Afastar-se das regras acima pode funcionar enquanto não houver ciclos de dependência entre os módulos, mas como tais ciclos são confusos e difíceis de solucionar, é melhor seguir as regras para evitar a introdução de problemas no futuro.

Aqui está uma armadilha comum a ser evitada:

(define-public avr-binutils
  (package
    (inherit (cross-binutils "avr"))
    (name "avr-binutils")))

In the above example, the avr-binutils package was defined in the module (gnu packages avr), and the cross-binutils procedure in (gnu packages cross-base). Because the inherit field is not delayed (thunked), it is evaluated at the top level at load time, which is problematic in the presence of module dependency cycles. This could be resolved by turning the package into a procedure instead, like:

(define (make-avr-binutils)
  (package
    (inherit (cross-binutils "avr"))
    (name "avr-binutils")))

Seria necessário tomar cuidado para garantir que o procedimento acima só seja usado em campos atrasados de pacote ou dentro de outro procedimento também não chamado no nível superior.