From: maxim.cournoyer@gmail.com
To: guix-devel <guix-devel@gnu.org>
Subject: Dependency cycle issues when using a Gexp-based snippet
Date: Sun, 23 Aug 2020 22:10:50 -0400 [thread overview]
Message-ID: <87h7ssx07p.fsf@gmail.com> (raw)
Hello,
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:
--8<---------------cut here---------------start------------->8---
modified gnu/packages/qt.scm
@@ -45,6 +45,7 @@
#:use-module (guix build-system gnu)
#:use-module (guix build-system trivial)
#:use-module (guix build-system python)
+ #:use-module (guix gexp)
#:use-module (guix packages)
#:use-module (guix deprecation)
#:use-module (guix utils)
@@ -349,27 +350,36 @@ developers using C++ or QML, a CSS & JavaScript like language.")
;; TODO Remove ((gnu packages kde) qtbase-for-krita) when upgrading qtbase.
(version "5.14.2")
(source (origin
- (method url-fetch)
- (uri (string-append "https://download.qt.io/official_releases/qt/"
- (version-major+minor version) "/" version
- "/submodules/" name "-everywhere-src-"
- version ".tar.xz"))
- (sha256
- (base32
- "12mjsahlma9rw3vz9a6b5h2s6ylg8b34hxc2vnlna5ll429fgfa8"))
- ;; Use TZDIR to avoid depending on package "tzdata".
- (patches (search-patches "qtbase-use-TZDIR.patch"
- "qtbase-moc-ignore-gcc-macro.patch"))
- (modules '((guix build utils)))
- (snippet
- ;; corelib uses bundled harfbuzz, md4, md5, sha3
- '(begin
- (with-directory-excursion "src/3rdparty"
- (for-each delete-file-recursively
- (list "double-conversion" "freetype" "harfbuzz-ng"
- "libpng" "libjpeg" "pcre2" "sqlite" "xcb"
- "zlib"))
- #t)))))
+ (method url-fetch)
+ (uri (string-append "https://download.qt.io/official_releases/qt/"
+ (version-major+minor version) "/" version
+ "/submodules/" name "-everywhere-src-"
+ version ".tar.xz"))
+ (sha256
+ (base32
+ "12mjsahlma9rw3vz9a6b5h2s6ylg8b34hxc2vnlna5ll429fgfa8"))
+ ;; Use TZDIR to avoid depending on package "tzdata".
+ (patches (search-patches "qtbase-use-TZDIR.patch"
+ "qtbase-moc-ignore-gcc-macro.patch"))
+ (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)))))
(build-system gnu-build-system)
(propagated-inputs
`(("mesa" ,mesa)
--8<---------------cut here---------------end--------------->8---
I encountered the following issue, which seems similar to one
encountered by Ricardo in 2016 [0]:
--8<---------------cut here---------------start------------->8---
ice-9/eval.scm:293:34: error: canonical-package: unbound variable
hint: Did you forget a `use-modules' form?
--8<---------------cut here---------------end--------------->8---
The origin can be correctly built at the REPL, so the problem indeed
seems to be a dependency cycle.
Attempting a suggested fix by Ludovic in that same conversation [0],
namely, making the snippet field of the <origin> record a thunked one:
--8<---------------cut here---------------start------------->8---
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")))
--8<---------------cut here---------------end--------------->8---
It now seems a new cycle is introduced because trying to build anything
hangs using the CPU with slowly increasing memory usage:
./pre-inst-env guix build hello
How can we make Gexp-based snippets such as the one shown above work
without introducing problematic cycles?
Thanks,
Maxim
[0] http://logs.guix.gnu.org/guix/2016-09-30.log#163047
next reply other threads:[~2020-08-24 2:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-24 2:10 maxim.cournoyer [this message]
2020-08-24 21:09 ` Dependency cycle issues when using a Gexp-based snippet Ludovic Courtès
2020-09-02 15:08 ` Maxim Cournoyer
2020-09-07 9:30 ` Ludovic Courtès
2020-09-14 16:55 ` Maxim Cournoyer
2020-09-16 10:08 ` Ludovic Courtès
2020-09-07 18:30 ` Mark H Weaver
2020-09-16 10:00 ` Ludovic Courtès
2020-09-08 4:07 ` What should "guix build --source" produce? (was Re: Dependency cycle issues when using a Gexp-based snippet) Mark H Weaver
2020-09-08 7:22 ` Andreas Enge
2020-09-11 18:22 ` Maxim Cournoyer
2020-09-11 18:42 ` zimoun
2020-09-11 20:40 ` Andreas Enge
2020-09-11 18:26 ` Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h7ssx07p.fsf@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).