bug#65716: bug#65718: Importing a toolchain packages causes top-level dependency cycles

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

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