From mboxrd@z Thu Jan 1 00:00:00 1970 From: Caleb Ristvedt Subject: Re: Packaging Jami progress Date: Tue, 10 Dec 2019 18:43:58 -0600 Message-ID: <87wob3lmi9.fsf@cune.org> References: <20191104214754.793ec2ff@interia.pl> <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> <20191210235601.3b48eeaf@interia.pl> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:38184) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieq6m-0003cx-MI for guix-devel@gnu.org; Tue, 10 Dec 2019 19:44:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ieq6k-0005GH-SS for guix-devel@gnu.org; Tue, 10 Dec 2019 19:44:03 -0500 Received: from mail-yw1-xc30.google.com ([2607:f8b0:4864:20::c30]:43119) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ieq6k-0005ES-9g for guix-devel@gnu.org; Tue, 10 Dec 2019 19:44:02 -0500 Received: by mail-yw1-xc30.google.com with SMTP id s187so8187733ywe.10 for ; Tue, 10 Dec 2019 16:44:02 -0800 (PST) In-Reply-To: <20191210235601.3b48eeaf@interia.pl> (Jan Wielkiewicz's message of "Tue, 10 Dec 2019 23:56:15 +0100") 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: Jan Wielkiewicz Cc: Guix-devel Jan Wielkiewicz writes: > I tried both ways - the second works, but the first doesn't. That would be the "in theory, it would work" part. On further investigation, source-module-closure has a #:select? keyword argument, which takes a module name and returns #f if it shouldn't be included in the closure. By default it's 'guix-module-name?', so it only includes the guix modules, and not, for example, (gcrypt hash). One might try passing #:select? (const #t), but this would likely reveal further issues - for example, guile-gcrypt doesn't work without libgcrypt, but source-module-closure isn't going to pull that in. The short answer is "yeah, for big closures that reach outside of guix (or especially that have non-scheme dependencies) source-module-closure isn't perfect", and build-side code should try to minimize the size of the closure it pulls in (which, for pretty much any (gnu packages ...) module, is going to be huge). The second solution is probably the better one here. There's this sort of awkward middle ground we don't see much where a build-side procedure has to be specific to some relatively small set of packages, but still to enough packages that repeating it in the builder for each of those packages duplicates a lot of code. Splicing the definition into the builder programmatically is a bit of a hack, as it's still duplicated between each builder interned in the store, but much better than copy+pasting manually. Hope that helps. - reepca