From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id OFN4C7EsRF9HZAAA0tVLHw (envelope-from ) for ; Mon, 24 Aug 2020 21:10:09 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id KAEvB7EsRF9pIwAAbx9fmQ (envelope-from ) for ; Mon, 24 Aug 2020 21:10:09 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D73889402CC for ; Mon, 24 Aug 2020 21:10:08 +0000 (UTC) Received: from localhost ([::1]:42798 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kAJjD-0000p4-Nd for larch@yhetil.org; Mon, 24 Aug 2020 17:10:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38822) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kAJiy-0000oe-TZ for guix-devel@gnu.org; Mon, 24 Aug 2020 17:09:52 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53517) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kAJiy-0002qq-Cw; Mon, 24 Aug 2020 17:09:52 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=52370 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kAJix-0004dV-Uh; Mon, 24 Aug 2020 17:09:52 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: maxim.cournoyer@gmail.com Subject: Re: Dependency cycle issues when using a Gexp-based snippet References: <87h7ssx07p.fsf@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 8 Fructidor an 228 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Mon, 24 Aug 2020 23:09:50 +0200 In-Reply-To: <87h7ssx07p.fsf@gmail.com> (maxim cournoyer's message of "Sun, 23 Aug 2020 22:10:50 -0400") Message-ID: <87wo1nzr6p.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: C4GpLsB+fFhA 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=E2=80=99s in a dependency c= ircle with the one at hand. > Attempting a suggested fix by Ludovic in that same conversation [0], > namely, making the snippet field of the 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=E2=80=99s 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 =E2=80=98delayed=E2=80=99 instead of =E2= =80=98thunked=E2=80=99.) > 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" "har= fbuzz-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=E2=80=99ll sidestep the issue altogeth= er? :-) Thanks, Ludo=E2=80=99.