On 18-10-2022 09:56, Lars-Dominik Braun wrote:
> [...]
> the problem is that `make` fails with an error in that case. For me it’s
> 
>      ice-9/eval.scm:293:34: error: gash: unbound variable
>      hint: Did you forget a `use-modules' form?
> 
> but YMMV. With #:autoload `make` succeeds, but throws similar
> errors/warnings(?) in the process:
> 
>      ;;; Failed to autoload fpc in (gnu packages pascal):
>      ;;; Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (fpc (gnu packages pascal)) #f)'

Don't know what's up with that, maybe when compiling (gnu packages 
pascal) is imported anyway because 'fpc' might be a macro?

But if I try that in a REPL:

(define-module (foo) #:autoload (bar) ( baz))
;;; Failed to determine exported bindings from module (bar):
;;; no code for module (bar)
;;; Failed to determine exported bindings from module (bar):
;;; no code for module (bar)
$1 = #<directory (foo) 7f31caf71820>

I get other messages (warnings, in this case), so maybe an incorrect 
hypothesis.

> 
> That’s why I went for the route implemented in the initial patch. What
> do we do now?

I think the issue is that (gnu packages pascal) imports (gnu packages 
commencement), even though according to the comment in (gnu packages 
commencement), you aren't supposed to do that (because of cycles).

You could give doing the resolve-module trick in (gnu packages pascal) a 
try.

Greetings,
Maxime