22.8.6 Zyklische Modulabhängigkeiten

Es darf zwar keine zyklischen Abhängigkeiten zwischen Paketen geben, aber weil Guile Module erst bei Bedarf lädt, können Sie durchaus zyklische Abhängigkeiten zwischen Guile-Modulen herstellen, ohne Probleme zu verursachen, solange Sie sich an die folgenden Bedingungen für zwei Module in einem Abhängigkeitszyklus halten:

1. Makros von anderen gegenseitig abhängigen Modulen werden nicht benutzt.
2. Variable auf oberster Ebene werden nur in verzögert ausgewerteten („delayed“, „thunked“) Paketfeldern eingesetzt, wie: arguments, native-inputs, inputs, propagated-inputs oder replacement.
3. Prozeduren, die auf Variable auf der obersten Ebene eines anderen Moduls verweisen, dürfen nicht selbst auf oberster Ebene eines Moduls aufgerufen werden.

Jegliches Abweichen von den obigen Regeln kann funktionieren, solange es keine Abhängigkeitszyklen gibt, aber weil solche Zyklen verwirrend sind und die Fehlersuche schwierig ist, befolgt man die Regeln besser grundsätzlich, um uns allen später keine Probleme einzuhandeln.

Hier sehen Sie eine solche Tücke:

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

Im Beispiel oben wurde das Paket avr-binutils im Modul (gnu packages avr) definiert und die Prozedur cross-binutils in (gnu packages cross-base). Weil das inherit-Feld nicht verzögert (delayed, thunked) ist, wird es auf oberster Ebene ausgewertet, sobald es geladen wird, und das ist problematisch, wenn die Module einen Abhängigkeitszyklus bilden. Stattdessen kann man das Paket als Prozedur definieren, etwa so:

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

Vorsicht wäre dann geboten, dass die obige Prozedur ebenfalls nur in verzögert ausgewerteten Feldern oder in Prozeduren benutzt werden darf, die auch nicht auf oberster Ebene aufgerufen werden.