Re: Packaging Jami progress

[Jan <tona_kosmicznego_smiecia@interia.pl>]

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 <caleb.ristvedt@cune.org> wrote:

> Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl> 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