Federico Beffa <be...@ieee.org> writes:
> From e853d10b595ece0003d838cbfffa65e29a6c2e68 Mon Sep 17 00:00:00 2001
> From: Federico Beffa <be...@fbengineering.ch>
> Date: Wed, 10 Dec 2014 21:05:59 +0100
> Subject: [PATCH 3/4] gnu: Add cairocffi.
>
> * gnu/packages/gtk.scm (python-cairocffi, python2-cairocffi): New variables.
[...]
> +(define-public python2-cairocffi
> + (package-with-python2 python-cairocffi))
> +
This commit breaks the Guix build for me.
Due to complications arising from circular module dependencies, we can't
use 'package-with-python2' from gtk.scm. For now, I suggest moving it
to python.scm, where all other uses of 'package-with-python2' are
currently located.
If you'd like to understand the reasons, read on (optional).
The reason is that gtk.scm and python.scm are part of the same strongly
connected component (SCC) in the graph of "use-module" dependencies. In
other words, there exists a cycle containing both of them (in this case
they use each other directly). This prevents Guile from loading the
modules in "bottom-up" order, and there's no guarantee which one will be
loaded first.
In this case, if gtk.scm is loaded first, it works, but if python.scm is
loaded first, you're out of luck.
If python.scm is loaded first, it starts by loading the modules it uses,
including gtk.scm. Then gtk.scm loads the modules it uses including
python.scm. This would lead to infinite recursion, but Guile breaks the
cycle by ignoring the attempt load python.scm when it's currently being
loaded. gtk.scm then continues to load, and gets to your definition of
'python2-cairocffi', which tries to call 'package-with-python2' before
python.scm has been fully loaded (in fact it's hardly loaded at all).
In Guix package modules this is usually not a problem, because most of
the inter-module variable references are in "thunked" fields such as
'inputs', and thunked fields are not evaluated until later. However,
the definition of 'python2-cairocffi' needs to call
'package-with-python2' at module-load time, and python.scm may not be
loaded yet at that point.
So 'python2-cairocffi' must either be moved out of the SCC containing
python.scm, or moved into python.scm at a point late enough in the file
such that everything needed by 'package-with-python2' has already been
loaded.
We currently have two non-trivial SCCs in our "use-module" graph of
package modules. One is ((gnu packages bison) (gnu packages flex)),
and the other one is rather large:
((gnu packages boost)
(gnu packages python)
(gnu packages image)
(gnu packages fontutils)
(gnu packages ghostscript)
(gnu packages tcl)
(gnu packages xorg)
(gnu packages gettext)
(gnu packages xml)
(gnu packages gnupg)
(gnu packages curl)
(gnu packages gnutls)
(gnu packages guile)
(gnu packages gtk)
(gnu packages glib)
(gnu packages base)
(gnu packages acl)
(gnu packages attr)
(gnu packages linux)
(gnu packages databases)
(gnu packages emacs)
(gnu packages lesstif)
(gnu packages version-control)
(gnu packages cook)
(gnu packages groff)
(gnu packages netpbm)
(gnu packages nano)
(gnu packages admin)
(gnu packages swig)
(gnu packages imagemagick)
(gnu packages algebra)
(gnu packages mpi)
(gnu packages valgrind)
(gnu packages gdb)
(gnu packages dejagnu)
(gnu packages graphviz)
(gnu packages gd)
(gnu packages w3m)
(gnu packages wget)
(gnu packages web)
(gnu packages asciidoc)
(gnu packages docbook)
(gnu packages inkscape)
(gnu packages maths)
(gnu packages cmake)
(gnu packages backup)
(gnu packages rsync)
(gnu packages ssh)
(gnu packages fltk)
(gnu packages gl)
(gnu packages xdisorg)
(gnu packages lisp)
(gnu packages texlive)
(gnu packages pdf)
(gnu packages tcsh)
(gnu packages zip)
(gnu packages gnome)
(gnu packages gstreamer)
(gnu packages pulseaudio)
(gnu packages avahi)
(gnu packages libcanberra)
(gnu packages xiph)
(gnu packages doxygen)
(gnu packages iso-codes)
(gnu packages mp3)
(gnu packages cdrom)
(gnu packages man)
(gnu packages lynx)
(gnu packages rrdtool)
(gnu packages gsasl)
(gnu packages shishi)
(gnu packages openldap))
Mark
