guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/4] gnu: Add cairocffi.


From: Mark H Weaver
Subject: Re: [PATCH 3/4] gnu: Add cairocffi.
Date: Thu, 18 Dec 2014 17:20:38 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Federico Beffa <address@hidden> writes:

> On Thu, Dec 18, 2014 at 8:53 PM, Mark H Weaver <address@hidden> wrote:
>> Federico Beffa <address@hidden> writes:
>>
>>> From e853d10b595ece0003d838cbfffa65e29a6c2e68 Mon Sep 17 00:00:00 2001
>>> From: Federico Beffa <address@hidden>
>>> 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.
>
> I just moved cairocffi to the python module and committed.  Sorry about that!

Thanks, and no worries!  I don't think any of us could have anticipated
this problem.

> I worked on it and with packages depending on it for several days
> without problems. How is it that the import is not deterministic?

It depends on which module in that large SCC is loaded first into a
given Guile session.

It should be deterministic for any given Guile session, e.g. for any
given *.scm file that is being compiled by 'guild compile', or for any
given set of commands typed into a freshly loaded Guile.

I saw the problem when compiling inkscape.scm.  Other files might have
failed as well, but 'make' stopped when inkscape.scm failed.  I guess
you didn't recompile any of the files that exhibited the problem since
adding 'python2-cairocffi', which is reasonable :)

I hope to eventually add some mechanism to detect and/or avoid these
problems in the future.  In the meantime, we'll just have to accept that
this problem will occasionally bite us.  I don't think it's reasonable
to expect people to do a "make clean-go && make" every time they add a
package.  IMO, that cure would be worse than the disease.

     Regards,
       Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]