From mboxrd@z Thu Jan 1 00:00:00 1970 From: Caleb Ristvedt Subject: Re: Packaging Jami progress Date: Tue, 10 Dec 2019 09:59:40 +0000 Message-ID: References: <20191104214754.793ec2ff@interia.pl> <20191126203259.0f4141ea@kompiuter> <20191130192121.11e0c968@kompiuter> <87fti52or5.fsf@ambrevar.xyz> <20191201173411.042e68f2@kompiuter> <878snw2bpn.fsf@ambrevar.xyz> <20191203164402.77a8c728@interia.pl> <87tv6hieeg.fsf@ambrevar.xyz> <20191203190235.53765cba@kompiuter> <87fti1mf1u.fsf@ambrevar.xyz> <87d0d5mez0.fsf@ambrevar.xyz> <20191204153631.509b9afb@interia.pl> <87immwt8kh.fsf@ambrevar.xyz> <20191204165038.7a5403f2@interia.pl> <87fti0t6rr.fsf@ambrevar.xyz> <20191204175614.29f663cd@kompiuter> <87a788t47g.fsf@ambrevar.xyz> <20191204182249.38fd0700@interia.pl> <87wobac07c.fsf@ambrevar.xyz> <20191209231729.7a253e9d@interia.pl> <875zioy2vp.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000ca89b3059956928b" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:36870) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iecJA-0001z6-KC for guix-devel@gnu.org; Tue, 10 Dec 2019 04:59:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iecJ8-0001x0-Ur for guix-devel@gnu.org; Tue, 10 Dec 2019 04:59:56 -0500 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]:37406) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iecJ8-0001wi-IF for guix-devel@gnu.org; Tue, 10 Dec 2019 04:59:54 -0500 Received: by mail-pf1-x432.google.com with SMTP id s18so8806531pfm.4 for ; Tue, 10 Dec 2019 01:59:54 -0800 (PST) In-Reply-To: <875zioy2vp.fsf@ambrevar.xyz> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt Cc: Guix-devel --000000000000ca89b3059956928b Content-Type: text/plain; charset="UTF-8" #:modules and #:imported-modules are distinct arguments. #:modules is the modules that your builder is going to use (as in "they go in a (use-modules ...) form"), while #:imported-modules is the modules that need to be available in the build environment. It's complaining at build-time that it can't find that module to use, because you haven't told it to include that module in the build environment. #:imported-modules should give a superset of what #:modules gives, especially if a module in use is going to have indirect requirements. Thankfully, wrangling together those indirect requirements is already implemented in (guix modules) as source-module-closure. Thus, you could conceptually do (arguments `(#:imported-modules (,@(source-module-closure '((gnu packages jami) ,@%gnu-build-system-modules))) #:modules ((gnu packages jami) ,@(@@ (guix build-system gnu) %default-modules)))) And in theory it would work. Note, though, that this would pull in the entire module dependency graph of (gnu packages jami), and this may include things that source-module-closure would have a hard time detecting and aren't really needed. Ideally this procedure would be generalized and put in (guix build ), but I can understand if that's not possible. Note also that you could simply splice in the definition of your procedure into the builder manually, like so: (define my-procedure-code '(lambda (a b c) ...)) (arguments `(#:phases (let ((my-procedure ,my-procedure-code)) (modify-phases ...)))) Hope that helps, thanks for the work on Jami y'all! On Tue, Dec 10, 2019 at 8:57 AM Pierre Neidhardt wrote: > Sorry, I don't know how to import a procedure defined in the same file :( > Anyone? > > -- > Pierre Neidhardt > https://ambrevar.xyz/ > --000000000000ca89b3059956928b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
#:modules and #:imported-modules are distinct arguments. #= :modules is the
modules that your builder is going to use (as in "t= hey go in a (use-modules
...) form"), while #:imported-modules is t= he modules that need to be available
in the build environment. It's = complaining at build-time that it can't find that
module to use, bec= ause you haven't told it to include that module in the build
environ= ment. #:imported-modules should give a superset of what #:modules gives,especially if a module in use is going to have indirect
requirements. T= hankfully, wrangling together those indirect requirements is
already imp= lemented in (guix modules) as source-module-closure.

Thus, you could= conceptually do


(arguments
=C2=A0=C2=A0=C2=A0=C2=A0 `(#:impo= rted-modules (,@(source-module-closure
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 '((gnu package= s jami)
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 ,@%gnu-build-system-modules)))
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 #:modules ((gnu packages jami)
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 =C2=A0 ,@(@@ (guix build-system gnu) %default-modules))))

And= in theory it would work. Note, though, that this would pull in the entire<= br>module dependency graph of (gnu packages jami), and this may include thi= ngs that
source-module-closure would have a hard time detecting and aren= 't really
needed. Ideally this procedure would be generalized and pu= t in (guix build
<something>), but I can understand if that's = not possible. Note also that you
could simply splice in the definition o= f your procedure into the builder
manually, like so:

(define my-p= rocedure-code '(lambda (a b c) ...))

(arguments
=C2=A0`(= #:phases (let ((my-procedure ,my-procedure-code)) (modify-phases ...))))

Hope that helps, thanks for the work on Jami y'a= ll!

On Tue, Dec 10, 2019 at 8:57 AM Pierre Neidhardt <mail@ambrevar.xyz> wrote:
Sorry, I don't know how = to import a procedure defined in the same file=C2=A0:(
Anyone?

--
Pierre Neidhardt
http= s://ambrevar.xyz/
--000000000000ca89b3059956928b--