[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65716: bug#65718: Importing a toolchain packages causes top-level de
From: |
Maxim Cournoyer |
Subject: |
bug#65716: bug#65718: Importing a toolchain packages causes top-level dependency cycles |
Date: |
Sun, 03 Sep 2023 22:16:47 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi Ludovic,
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> Hi Ludovic,
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello,
>>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>
>>> Adding the Guile undocumented "(set! %load-verbosely #t)" to my local
>>> near the top of my (guix config) module, I see, when running 'make':
>>>
>>> make[2] : on entre dans le répertoire « /home/maxim/src/guix »
>>> [...]
>>> Compiling Scheme modules...
>>> [ 0%] LOAD guix.scm
>>> ;;; loading ./guix/build/syscalls.scm
>>> ;;; loading ./guix/build/syscalls.scm
>>
>> [...]
>>
>> Looks like this is independent from your change no? There’s no
>> ergodox.scm in the list of loaded files AFAICS.
>>
>> Do you experience the problem without your patch?
>
> I am not! As soon as I go back to a commit before my change, everything
> starts working again. I'm thoroughly puzzled :-)
(gnu packages avr) has definitions referencing gcc from the top level
(e.g. avr-gcc), which probably plays a role in this. (gnu packages
cross-base) has the note at the bottom:
--8<---------------cut here---------------start------------->8---
;;; Concrete cross tool chains are instantiated like this:
;;
;; (define-public xgcc-armhf
;; (let ((triplet "arm-linux-gnueabihf"))
;; (cross-gcc triplet
;; #:xbinutils (cross-binutils triplet)
;; #:libc (cross-libc triplet))))
;;
;;; We don't do that here because we'd be referring to bindings from (gnu
;;; packages gcc) from the top level, which doesn't play well with circular
;;; dependencies among modules.
--8<---------------cut here---------------end--------------->8---
But it seems hard to "visualize" the problem. Perhaps we need to write
a tool that analyzes and output the modules dependency graph to get more
insights.
It's unfortunate that we cannot define cross toolchain from the top
level -- is there no way in Scheme to make a procedure arguments lazily
evaluated as done by default in Haskell? It seems lazy evaluation could
help here.
Or failing that, could we combine the (gnu packages gcc) / (gnu packages
cross-base) / ? into a (gnu packages toolchain) monolith? Because exact
nature of the problem is still fuzzy to me, I'm not even sure if this
proposition makes sense / could work, but if the problem is gcc being
referenced at the top level from another module, it should, right?
--
Thanks,
Maxim