Hi Ludovic, Maxim Cournoyer <maxim.courno...@gmail.com> writes:
> Hi Ludovic, > > Ludovic Courtès <l...@gnu.org> writes: > >> Hello, >> >> Maxim Cournoyer <maxim.courno...@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
