From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Subject: Re: Packaging Jami progress Date: Wed, 11 Dec 2019 17:33:15 +0100 Message-ID: <20191211173315.31ad313b@kompiuter> 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> <87wob3lmi9.fsf@cune.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:58928) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1if4vZ-0007YJ-48 for guix-devel@gnu.org; Wed, 11 Dec 2019 11:33:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1if4vX-0005Io-Sm for guix-devel@gnu.org; Wed, 11 Dec 2019 11:33:28 -0500 Received: from smtpo.poczta.interia.pl ([217.74.65.235]:45771) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1if4vX-0005FH-4W for guix-devel@gnu.org; Wed, 11 Dec 2019 11:33:27 -0500 In-Reply-To: <87wob3lmi9.fsf@cune.org> 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: Caleb Ristvedt Cc: Guix-devel Okay, thanks. I'll use the second way then. I could also create a new file - jami-utils.scm and use it as a module, but a file containing only one procedure isn't good either. On Tue, 10 Dec 2019 18:43:58 -0600 Caleb Ristvedt wrote: > 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 Jan Wielkiewicz