[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Packaging Jami progress

From: Jan
Subject: Re: Packaging Jami progress
Date: Wed, 11 Dec 2019 17:33:15 +0100

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 <address@hidden> wrote:

> Jan Wielkiewicz <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]