Re: Dependency cycle issues when using a Gexp-based snippet

["Ludovic Courtès" <ludo@gnu.org>]

Hello!

maxim.cournoyer@gmail.com skribis:

> While trying to move some of the patching done to qtbase into a snippet,
> with the goal of having at least the ./configure script runnable in a
> guix environment without having to manually run patching phases:

[...]

> I encountered the following issue, which seems similar to one
> encountered by Ricardo in 2016 [0]:
>
> ice-9/eval.scm:293:34: error: canonical-package: unbound variable
> hint: Did you forget a `use-modules' form?
>
>
> The origin can be correctly built at the REPL, so the problem indeed
> seems to be a dependency cycle.

Indeed: the problem is that when loading this module, we try to resolve
one of the variables referenced in the snippet, but that variable is not
defined yet because it comes from a module that’s in a dependency circle
with the one at hand.

> Attempting a suggested fix by Ludovic in that same conversation [0],
> namely, making the snippet field of the <origin> record a thunked one:
>
> modified   guix/packages.scm
> @@ -250,7 +250,8 @@ as base32.  Otherwise, it must be a bytevector."
>    (patches   origin-patches                       ; list of file names
>               (default '()) (delayed))
>
> -  (snippet   origin-snippet (default #f))         ; sexp or #f
> +  (snippet   origin-snippet
> +             (default #f) (thunked))              ; sexp or #f
>    (patch-flags  origin-patch-flags                ; list of strings
>                  (default '("-p1")))

We should check what this change costs in CPU and memory, but it’s
probably worth it.  As Marius noted before, the snippets for
ungoogled-chromium and linux-libre are contrived because of this
limitation.  (Perhaps we can use ‘delayed’ instead of ‘thunked’.)

> It now seems a new cycle is introduced because trying to build anything
> hangs using the CPU with slowly increasing memory usage:

Hmm not sure exactly why, but look:

+              (snippet
+               (with-imported-modules '((guix build utils))
+                 #~(begin
+                     (use-modules (guix build utils))
+                     ;; corelib uses bundled harfbuzz, md4, md5, sha3
+                     (with-directory-excursion "src/3rdparty"
+                       (for-each delete-file-recursively
+                                 (list "double-conversion" "freetype" "harfbuzz-ng"
+                                       "libpng" "libjpeg" "pcre2" "sqlite" "xcb"
+                                       "zlib")))
+
+                     (let ((coreutils #+(canonical-package coreutils)))
+                       (substitute* "configure"
+                         (("/bin/pwd")
+                          (string-append coreutils "/bin/pwd")))
+                       (substitute* "src/corelib/global/global.pri"
+                         (("/bin/ls")
+                          (string-append coreutils "/bin/ls"))))
+                     #t)))))

Such substitutions are system-dependent; thus, they should be made in a
phase, not in a snippet.  Perhaps we’ll sidestep the issue altogether?
:-)

Thanks,
Ludo’.