Re: Packaging Jami progress

[Caleb Ristvedt <caleb.ristvedt@cune.org>]

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